Пробное Middle C# собеседование (мок-интервью)

Поделиться
HTML-код
  • Опубликовано: 30 сен 2024

Комментарии • 60

  • @duming3076
    @duming3076 10 месяцев назад +11

    фраза ушёл на front звучит уже не так однозначно.)

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад

      Это да, поэтому давайте радоваться тому, что это именно программистский front 😉

  • @mv.mmaksm
    @mv.mmaksm 4 месяца назад +4

    Очень слабо для мидла, даже джунов больше гоняют

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  3 месяца назад

      Сильно зависит от компании и обстоятельств. Знаю историю, где джуна за 4 месяца сделали тимлидом, когда вся команда разом уволилась, кроме него. Плюс, даже на один и тот же уровень, требования, скажем в Яндекс, скорее всего будут выше, чем в "Рога и Компы" в небольшом городке в регионе.

  • @АИСКНД-видеосправка
    @АИСКНД-видеосправка 2 месяца назад +1

    В чем смысл таких интервью ? Слишком большой объем данных и слишком много технологий. Вам нужен программист или человек, который вызубрил ответы на ютьюбе ?

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  2 месяца назад

      Да, мне порой так же хочется сказать про реальные собеседования. Однако, как вы по-другому предложите протестировать действительно ли у человека есть нужные знания и опыт?

    • @yaroslavvitalievich5495
      @yaroslavvitalievich5495 2 месяца назад +1

      Честно говоря мне тоже собеседования показалось максимально скучным. Я б после такого собеседования не выбрал бы компанию. Просто рандомный скрининг и вопросы скорее на джуна. Если собеседуют человека middle/senior level, больше хотелось бы видеть собес в ввиде диалога, с обсуждением реального опыта, какие были челенжи или задачи, можно углубиться в несколько тем, но желательно в те, что релевантны для конкретной вакансии.
      Events вообще архаизм сейчас, я уже много лет даже близко их не видел.

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  Месяц назад

      @@yaroslavvitalievich5495 рандомные вопросы, так как это собеседование не в конкретную компанию и нет запроса выявить знания в конкретной области.

  • @DotNetInterviewPreparation
    @DotNetInterviewPreparation  10 месяцев назад +1

    Ссылка для участия в тренировочных собеседованиях: dotnet-interview-preparation.com/mock-interview-youtube

  • @anastascat2770
    @anastascat2770 10 месяцев назад +2

    Спасибо за мок-собес
    Первое что бросилось на слух, что у собеседуемого опыта выше крыши, но он акцентирует внимание на том, что ему пришлось заниматься базами и фронтом. Но, ведь без этого никак и ни в коем случае это нельзя выносить в отдельную когорту знаний. Всегда бекендеры занимаются базами данных, портому что это их регалия, а так же фронтом, потому что, кто кроме нас в эту секунду не покроет задачу, чтобы она не ушла в беклог?
    Касаясь вопросов:
    Преамбула для собеседующего. Будь пожёсче и допрашивай по каждому вопросу чуть глубже, не будь настолько удовлетворен или неудовлетворен вопросом. Покопай, так интереснее :)
    1. По асинкам: немножко неуверенно. Будто где-то читал, но не дотянул. Советовал бы еще спросить, что происходит с программой, когда она натыкатеся на await. Достаточно хорошо позволяет понять, насколько глубоко собеседуемый копал в реализацию.
    2. Вообще атрибут это все-таки класс, а не метаданные) А вот то, что он добавляет дополнительную информацию в метаданные PE-файла - да.
    3. По рефлексии - можно было вспомнить хотя бы те же самые атрибуты. Часто используется в продакшене для пометки и активейта, как минимум :)

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад +3

      Согласен, разбираться желательно и в связанных областях тоже. Однако, лучше при этом все же на чем-то специализироваться, иначе тебя быстро заменят на ИИ, который уже умеет делать ооочень многое и порой выгоднее разработчика - намного дешевле, в отпуск не ходит, не болеет, конфликтов никаких не устраивает - красота да и только))
      Не хочу устраивать жестких допросов, мне больше нравится западная манера общения, когда говорят: "Да, да, вы отличный кандидат и всё отлично ответили! Что? Наняты вы или нет? Не переживайте, мы вам сообщим." и романтично уходят в закат. Прекрасно понимаю, что такой подход может прямо бесить некоторых и меня тоже раздражало сильно в первое время, но, видимо, уже привык. Порой по-другому никак. Ну и плюс, если я буду жестить, то ко мне на пробные собеседования никто приходить не будет)))
      1. Блин, я помню, как мы боялись использовать async/await, называя его зомби-вирусом, потому, что исхода было два: либо ты где-то ставишь .Result() и вся твоя асинхронность превращается в тыкву, либо меняешь 1000 и 1 метод, делая асинхронными сначала их, затем все методы, которые используют эти методы, потом все методы, которые используют предыдущие методы, и т.д. А уж сколько мерж конфликтов ты с этим огребешь - мама не горюй. А сейчас приходят ребята, для которых асинхронщина - данность, которая "просто работает". Ух, вот это я поворчать)))
      2. Если вас спросить "Что такое EntityFramework?" вы ответите, что это ORM или что это nuget-пакет?))
      3. Это да, а ещё иногда чтобы в тестах (на самом деле не только) установить значение приватному полю О:-)

  • @techbuterbrod
    @techbuterbrod 5 месяцев назад +2

    Спасибо за видео, но на middle очень слабые ответы. То, что прошелся по названиям и стилю прям респект. Я реально устал на проектах, когда по названию и сигнатуре метода невозможно понять совершенно, что этот метод делает.

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  3 месяца назад

      Согласен про стили и названия, если их нет, то что это может показывать недостаток опыта, потому что рано или поздно их во всех компаниях внедряют.

    • @yaroslavvitalievich5495
      @yaroslavvitalievich5495 2 месяца назад +1

      Если человек делает тестовое в каком-то левом IDE, та еще и под жестким временным ограничением, докапываться до стилей это последнее что нужно делать. У любого нормального разработчика есть IDE, которая по одному клику все отформатирует.
      Хочешь посмтреть на чистоту кода - нужно давать либо больше времени, либо дать кусок грязного кода и попросить его отрефакторить или оставить коменты как на ПР

    • @techbuterbrod
      @techbuterbrod 2 месяца назад

      @@yaroslavvitalievich5495 у опытного человека такие вещи, как названия переменных и соблюдение общепринятого стиля уже на автомате.
      Это просто показатель того, что человек не работал на серьезных крупных проектах или предпочитает тратить время коллег на свои PR, где надо каждый раз оставлять кучу замечаний. Можно, конечно, и не придираться, просто тогда предложить позицию Junior, а не Middle, кем и является данный кандидат.

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  Месяц назад

      @@yaroslavvitalievich5495 кстати, попросить проревьюить ПР - отличная идея, но туда, боюсь, ещё больше времени нужно. А стили очень влияют на восприятие кандидата и если человек "грязно" пишет код, это автоматические проецируется на то, что он так же "грязно" и будет работать.

  • @cyril1010
    @cyril1010 10 месяцев назад +3

    Привет! Спасибо за новый видос, я ждал) На собесах на позицию мидл тоже часто встречаю вопросы про асинхронность и многопоточность, паттерны спрашивают пореже, а впорос про reflection давно не спрашивали, где-то года 3 назад. Ну и в реальной работе у меня это тоже буквально на одном проекте только использовалось, в принципе про reflection знать это круто, но полезность этих знаний очень специфична.

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад +4

      Спасибо большое за обратную связь. Согласен про специфичность Reflection, хотя в последнем проекте она использовалась. Ну и в целом там ничего сложного же и нет - пара методов, показывающих какие переменные и методы есть у типа, да пара методов на создание этого типа и установку значений. Вот и вся рефлексия :-)

    • @U7Craft
      @U7Craft 10 месяцев назад +1

      Атрибуты тоже через рефлексию работают)

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад +1

      Да, ещё один метод для получения атрибутов надо. Ок, три (основных) метода и вот и вся рефлексия :-)

    • @Hadouken247
      @Hadouken247 10 месяцев назад +1

      @@U7CraftНе только) Их в 99% кейсах используют в кодогенераторах, но разве что на уровне синтаксического дерева (мы не лезем в заголовочный файл за метаданными)

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  9 месяцев назад

      А интересно, @Hadouken247, откуда у вас такая статистика про 99%? 😉

  • @DuRacu
    @DuRacu 2 месяца назад +1

    Олег ЛЕГЕНДА

  • @Alokin-USA
    @Alokin-USA 9 месяцев назад +1

    Хорошее видео, в котором мы узнаем как
    важно подготовиться к собеседованию, изучив основы языка C#, различные алгоритмы и структуры данных, а также подготовиться к решению реальных задач. Также важно практиковать свои коммуникативные навыки и уметь объяснять свои решения. Спасибо!

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  9 месяцев назад

      Спасибо большое за комментарий, хотя он немного и похож на автосгенерированный 😇

    • @Alokin-USA
      @Alokin-USA 9 месяцев назад +1

      @@DotNetInterviewPreparation если только совсем немного ))

  • @RaitedPlayer
    @RaitedPlayer 10 месяцев назад +1

    Очень воодушевляет такой формат, не выглядит что собеседования это что-то страшное и ужасное) Насколько критично отписываться от ивентов? Или это больше про правило хорошего тона?

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад

      Насколько критично?
      Вот представьте, что в одном из методов вы создали экземпляр класса, который подписали на событие, он сделал всю необходимую логику и по завершению метода в теории должен быть обработан сборщиком мусора. Но так как на него есть ссылка в ивенте, то память от него не освободится. Более того, он продолжит реагировать на ивенты и обрабатывать их. Таким образом, с каждым новым экземпляром класса у нас появляется код, который не удаляется из памяти и её становится меньше, а также этот код реагирует на события, то есть занимает ещё и процессорное время. Рано или поздно, в таком случае, у нас накопится столько этих неубиваемых экземпляров класса, что они будут отжирать всю оперативную памяти и всё процессорное время.
      Насколько по-вашему такое критично? ;-)

    • @Igor-y7f
      @Igor-y7f 18 дней назад +1

      прямой путь к утечке памяти

  • @mrlait5732
    @mrlait5732 9 месяцев назад +1

    Вопрос по ConfigureAwait, вы сказали в видео, что если мы пишем await task, то продолжит работу любой первый попавшейся поток но на самом деле это работает так:
    await task; - в таком случае работу продолжит тот же поток;
    await task.ConfigureAwait(false); то такой записью мы явно указываем, что нам не важно какой поток продолжит выполнение;
    await task.ConfigureAwait(true) или await task; эти записи идентичны

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  9 месяцев назад +1

      Да, точно, спасибо большое за уточнение 👍

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  9 месяцев назад +1

      Кстати, осознал тут вдруг, что не так понял ваш комментарий. Поток любой может быть, а вот контекст - тот же, он восстанавливается, если не указано ConfigureAwait(false).

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  9 месяцев назад

      Даже ещё точнее, в случае с тасками это будет не любой поток, а поток из Thread Pool'a.

    • @mrlait5732
      @mrlait5732 9 месяцев назад +1

      ​@@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", можно приостановить выполнение метода до тех пор, пока не будет завершено выполнение асинхронной операции, и затем продолжить работу в том же потоке, в котором был вызван метод. Это позволяет избежать блокирования основного потока выполнения и обеспечить более отзывчивый интерфейс пользователя.

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  9 месяцев назад

      Ух ты, вот это у нас беседа пошла, спасибо вам большое за такое, очень ценю. Немного удивлён, что ЧатГПТ уже приводится в качестве какого-то источника знаний с его-то 20% галлюцинаций, которые в основной документации указаны. Но это так, к слову.
      А что касается потоков, то, как всегда, могу быть неправ, давайте поразмышляем вместе. Например над следующей ситуацией: у нас выполнялся в потоке какой-то метод, в котором мы ушли в ожидание базы данных и сохранили контекст. Затем к нам пришёл результат запроса от базы данных и возможны два варианта:
      1) Мы берём тот же поток, что у нас и был раньше. Здесь возникает сразу вопрос "Что делал наш поток, пока мы ждали ответ?" Если он просто ждал нас и ничего не делал, то это не очень похоже на асинхронность и непонятно зачем сохранять контекст выполнения.
      Если же он ушёл выполнять другой код, то неясно зачем ждать именно его, ведь у нас уже есть сохранённый контекст, который мы можем восстановить на любом, готовом к работе уже сейчас, потоке и продолжить выполнение. А иначе мы просто зря тормозим программу.
      2) Мы берём любой свободный поток из пула потоков, восстанавливаем контекст в него и продолжаем выполнение нашего метода.
      Мне кажется, что второй вариант предпочтительнее. А вы как считаете?

  • @ntwdconst
    @ntwdconst 10 месяцев назад +1

    Музыка топ)

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад

      Спасибо, Николай, я старался)

    • @ИльфатЗиганшин-л8ъ
      @ИльфатЗиганшин-л8ъ 10 месяцев назад

      @@DotNetInterviewPreparation можно тише сделать, буду благодарен

    • @DotNetInterviewPreparation
      @DotNetInterviewPreparation  10 месяцев назад

      @@ИльфатЗиганшин-л8ъ, чтобы музыку было лучше слышно? Или у нас громкости микрофонов разные?

  • @lonelypaul69
    @lonelypaul69 9 месяцев назад +2

    Спасибо за видос с собесом! Изображение есть, звук норм, за тайм-коды респект(хоть я не использовал - посмотрел полностью). Лайк поставил! Подписался! Жду новых видео

  • @lonelypaul69
    @lonelypaul69 9 месяцев назад +2

    отдельное спасибо за разбор, в первый раз встречаю такого рода разбор ответов