Пробное Middle C# собеседование (мок-интервью)
HTML-код
- Опубликовано: 30 июн 2024
- 0:00 Приветствие
0:07 Расскажи про свой опыт
1:39 Что такое атрибуты?
2:57 Какие паттерны проектирования ты знаешь?
7:59 Как работает async/await?
10:52 Что такое Reflection?
11:43 Разница между процессами и потоками
12:53 Практическое задание: паттерн Наблюдатель
25:50 Обратная связь: Атрибуты
26:45 Обратная связь: Паттерны
21:14 Обратная связь: Async/await
29:00 Обратная связь: Reflection
30:37 Обратная связь: Процессы и потоки
30:49 Обратная связь: Практика
36:47 Впечатления
#dotnet #csharp #interview #mockinterview
отдельное спасибо за разбор, в первый раз встречаю такого рода разбор ответов
Спасибо за видос с собесом! Изображение есть, звук норм, за тайм-коды респект(хоть я не использовал - посмотрел полностью). Лайк поставил! Подписался! Жду новых видео
Привет! Спасибо за новый видос, я ждал) На собесах на позицию мидл тоже часто встречаю вопросы про асинхронность и многопоточность, паттерны спрашивают пореже, а впорос про reflection давно не спрашивали, где-то года 3 назад. Ну и в реальной работе у меня это тоже буквально на одном проекте только использовалось, в принципе про reflection знать это круто, но полезность этих знаний очень специфична.
Спасибо большое за обратную связь. Согласен про специфичность Reflection, хотя в последнем проекте она использовалась. Ну и в целом там ничего сложного же и нет - пара методов, показывающих какие переменные и методы есть у типа, да пара методов на создание этого типа и установку значений. Вот и вся рефлексия :-)
Атрибуты тоже через рефлексию работают)
Да, ещё один метод для получения атрибутов надо. Ок, три (основных) метода и вот и вся рефлексия :-)
@@U7CraftНе только) Их в 99% кейсах используют в кодогенераторах, но разве что на уровне синтаксического дерева (мы не лезем в заголовочный файл за метаданными)
А интересно, @Hadouken247, откуда у вас такая статистика про 99%? 😉
Хорошее видео, в котором мы узнаем как
важно подготовиться к собеседованию, изучив основы языка C#, различные алгоритмы и структуры данных, а также подготовиться к решению реальных задач. Также важно практиковать свои коммуникативные навыки и уметь объяснять свои решения. Спасибо!
Спасибо большое за комментарий, хотя он немного и похож на автосгенерированный 😇
@@DotNetInterviewPreparation если только совсем немного ))
Спасибо за мок-собес
Первое что бросилось на слух, что у собеседуемого опыта выше крыши, но он акцентирует внимание на том, что ему пришлось заниматься базами и фронтом. Но, ведь без этого никак и ни в коем случае это нельзя выносить в отдельную когорту знаний. Всегда бекендеры занимаются базами данных, портому что это их регалия, а так же фронтом, потому что, кто кроме нас в эту секунду не покроет задачу, чтобы она не ушла в беклог?
Касаясь вопросов:
Преамбула для собеседующего. Будь пожёсче и допрашивай по каждому вопросу чуть глубже, не будь настолько удовлетворен или неудовлетворен вопросом. Покопай, так интереснее :)
1. По асинкам: немножко неуверенно. Будто где-то читал, но не дотянул. Советовал бы еще спросить, что происходит с программой, когда она натыкатеся на await. Достаточно хорошо позволяет понять, насколько глубоко собеседуемый копал в реализацию.
2. Вообще атрибут это все-таки класс, а не метаданные) А вот то, что он добавляет дополнительную информацию в метаданные PE-файла - да.
3. По рефлексии - можно было вспомнить хотя бы те же самые атрибуты. Часто используется в продакшене для пометки и активейта, как минимум :)
Согласен, разбираться желательно и в связанных областях тоже. Однако, лучше при этом все же на чем-то специализироваться, иначе тебя быстро заменят на ИИ, который уже умеет делать ооочень многое и порой выгоднее разработчика - намного дешевле, в отпуск не ходит, не болеет, конфликтов никаких не устраивает - красота да и только))
Не хочу устраивать жестких допросов, мне больше нравится западная манера общения, когда говорят: "Да, да, вы отличный кандидат и всё отлично ответили! Что? Наняты вы или нет? Не переживайте, мы вам сообщим." и романтично уходят в закат. Прекрасно понимаю, что такой подход может прямо бесить некоторых и меня тоже раздражало сильно в первое время, но, видимо, уже привык. Порой по-другому никак. Ну и плюс, если я буду жестить, то ко мне на пробные собеседования никто приходить не будет)))
1. Блин, я помню, как мы боялись использовать async/await, называя его зомби-вирусом, потому, что исхода было два: либо ты где-то ставишь .Result() и вся твоя асинхронность превращается в тыкву, либо меняешь 1000 и 1 метод, делая асинхронными сначала их, затем все методы, которые используют эти методы, потом все методы, которые используют предыдущие методы, и т.д. А уж сколько мерж конфликтов ты с этим огребешь - мама не горюй. А сейчас приходят ребята, для которых асинхронщина - данность, которая "просто работает". Ух, вот это я поворчать)))
2. Если вас спросить "Что такое EntityFramework?" вы ответите, что это ORM или что это nuget-пакет?))
3. Это да, а ещё иногда чтобы в тестах (на самом деле не только) установить значение приватному полю О:-)
фраза ушёл на front звучит уже не так однозначно.)
Это да, поэтому давайте радоваться тому, что это именно программистский front 😉
Очень воодушевляет такой формат, не выглядит что собеседования это что-то страшное и ужасное) Насколько критично отписываться от ивентов? Или это больше про правило хорошего тона?
Насколько критично?
Вот представьте, что в одном из методов вы создали экземпляр класса, который подписали на событие, он сделал всю необходимую логику и по завершению метода в теории должен быть обработан сборщиком мусора. Но так как на него есть ссылка в ивенте, то память от него не освободится. Более того, он продолжит реагировать на ивенты и обрабатывать их. Таким образом, с каждым новым экземпляром класса у нас появляется код, который не удаляется из памяти и её становится меньше, а также этот код реагирует на события, то есть занимает ещё и процессорное время. Рано или поздно, в таком случае, у нас накопится столько этих неубиваемых экземпляров класса, что они будут отжирать всю оперативную памяти и всё процессорное время.
Насколько по-вашему такое критично? ;-)
Ссылка для участия в тренировочных собеседованиях: dotnet-interview-preparation.com/mock-interview-youtube
Музыка топ)
Спасибо, Николай, я старался)
@@DotNetInterviewPreparation можно тише сделать, буду благодарен
@@user-ty4re1cz7d, чтобы музыку было лучше слышно? Или у нас громкости микрофонов разные?
Спасибо за видео, но на middle очень слабые ответы. То, что прошелся по названиям и стилю прям респект. Я реально устал на проектах, когда по названию и сигнатуре метода невозможно понять совершенно, что этот метод делает.
Согласен про стили и названия, если их нет, то что это может показывать недостаток опыта, потому что рано или поздно их во всех компаниях внедряют.
Вопрос по ConfigureAwait, вы сказали в видео, что если мы пишем await task, то продолжит работу любой первый попавшейся поток но на самом деле это работает так:
await task; - в таком случае работу продолжит тот же поток;
await task.ConfigureAwait(false); то такой записью мы явно указываем, что нам не важно какой поток продолжит выполнение;
await task.ConfigureAwait(true) или await task; эти записи идентичны
Да, точно, спасибо большое за уточнение 👍
Кстати, осознал тут вдруг, что не так понял ваш комментарий. Поток любой может быть, а вот контекст - тот же, он восстанавливается, если не указано ConfigureAwait(false).
Даже ещё точнее, в случае с тасками это будет не любой поток, а поток из Thread Pool'a.
@@DotNetInterviewPreparation я похоже не понимаю разницы между контекстом и потоком. Как я читал, то у асинхронных методов под капотом есть класс SynchronizationContext, который запомнит текущий контекст, и соответственно в каком потоке из пула потоков запустилось выполнение асинхронного метода, если не указываем ConfigureAwait или пишем ConfigureAwait(true). Далее, когда начинается выполнение асинхронной операции она захватывается текущим потоком, в котором началось выполнение метода, поток возвращается в пул потоков, для выполнения других задач в "Процессе", и после того как появились данные, например, из БД, то этот же поток возвращается из пула потоков и продолжает выполнение этой асинхронной операции. А если бы мы указали ConfigureAwait(false), то из пула потоков вернулся бы любой свободный поток и продолжил бы асинхронную операцию.
Вот, прикладываю цитату из статьи. По ней же можно в гугле найти ее: "If we set ‘ConfigureAwait(true)’ then the continuation task runs on the same thread used before the ‘await’ statement. If we set ‘ConfigureAwait(false)’ then the continuation task runs on the available thread pool thread."
Плюс ChatGpt тоже дал тот же ответ:
мой вопрос: await c# какой поток продолжает работать
Ответ: В языке программирования C#, с помощью ключевого слова "await", можно приостановить выполнение метода до тех пор, пока не будет завершено выполнение асинхронной операции, и затем продолжить работу в том же потоке, в котором был вызван метод. Это позволяет избежать блокирования основного потока выполнения и обеспечить более отзывчивый интерфейс пользователя.
Ух ты, вот это у нас беседа пошла, спасибо вам большое за такое, очень ценю. Немного удивлён, что ЧатГПТ уже приводится в качестве какого-то источника знаний с его-то 20% галлюцинаций, которые в основной документации указаны. Но это так, к слову.
А что касается потоков, то, как всегда, могу быть неправ, давайте поразмышляем вместе. Например над следующей ситуацией: у нас выполнялся в потоке какой-то метод, в котором мы ушли в ожидание базы данных и сохранили контекст. Затем к нам пришёл результат запроса от базы данных и возможны два варианта:
1) Мы берём тот же поток, что у нас и был раньше. Здесь возникает сразу вопрос "Что делал наш поток, пока мы ждали ответ?" Если он просто ждал нас и ничего не делал, то это не очень похоже на асинхронность и непонятно зачем сохранять контекст выполнения.
Если же он ушёл выполнять другой код, то неясно зачем ждать именно его, ведь у нас уже есть сохранённый контекст, который мы можем восстановить на любом, готовом к работе уже сейчас, потоке и продолжить выполнение. А иначе мы просто зря тормозим программу.
2) Мы берём любой свободный поток из пула потоков, восстанавливаем контекст в него и продолжаем выполнение нашего метода.
Мне кажется, что второй вариант предпочтительнее. А вы как считаете?
Очень слабо для мидла, даже джунов больше гоняют
Сильно зависит от компании и обстоятельств. Знаю историю, где джуна за 4 месяца сделали тимлидом, когда вся команда разом уволилась, кроме него. Плюс, даже на один и тот же уровень, требования, скажем в Яндекс, скорее всего будут выше, чем в "Рога и Компы" в небольшом городке в регионе.