Надо оценивать не умение кандидата вести себя на собеседовании, а его навыки и главное потенциал как разработчика. А при таком подходе будет у вас работать отличный актёр, рандомный как разработчик. Навыки собеседования нужны интервьюеру, чтобы в процессе непринуждённой беседы извлечь реально полезную, достаточную для принятия решения информацию за ограниченное время. Потенциал вообще мало кто способен увидеть, а это гораздо важнее знания какой-нибудь технологии, которую можно за вечер изучить.
Полностью с вами согласен, посмотрите момент с 48:30, где я об этом же говорю. Добавлю к тому, что говорил в видео, что это формат для тренировки кандидатов, а не их отбора для работы в компании.
Привет, по поводу задания, мне кажется все зависит от задачи бизнесов, если позволяют ресурсы, то почему бы не выполнять в синхроне, подняли нужное количество тачек и поставить выше балансировщик?) в примере с товарами как будто между синхроном и асинхронном лучше синхрон)) ИМХО Но все зависти от анализа бизнесов и ресурсов Отличный выпуск!👍
Именно так, в этом и была моя идея - использовать подходящие для задачи инструменты, а не те, к которым привык. К сожалению, это частая проблема, которую я и за собой тоже иногда замечаю.
Грейды в разных компаниях разные. Думаю, что даже Синьор C# разработчика не взяли бы и джуном на Machine Learning роль. Всё зависит от потребностей фирмы ;-)
Согласен. И на что еще стоит обратить внимание - что кандидат может даже не особо хорошо отвечать, но располагать к себе и тогда пройдет собеседование и будет нанят. Софт скилы играют очень важную, а порой и решающую роль на собеседованиях.
Про дедлоки явно какую то ерунду сказал. Простейший пример: Поток1: захватил объект A и хочет захватить B, поэтому ждёт. Поток2: захватил B, хочет А, ждёт освобождения А
Спасибо за комментарий и простите, если задел вас "штукой". Основная мысль здесь была в том, что на собеседовании лучше попросить минуту на подумать и ответить нормально, чем использовать слова, которые вроде бы как-то отвечают на вопрос, а по факту не отвечают.
@@DotNetInterviewPreparation Что Вы, "штука" задела именно Вас! Меня же задела придирка к "штуке" - ведь вопрос тоже задан неидеально: "ПОДСКАЖИТЕ ..."
@@MsAlexandr76, а я и не претендую на идеальность задаваемых вопросов, хотя в слове "подскажите" до сих пор не вижу ничего плохого. Однако, как вы считаете, для кого создан этот канал: для тех, кто будет проходить собеседования или для тех, кто будет собеседовать? На чем лучше фокусировать внимание: на том, как правильно отвечать на вопросы или на том, как их правильно задавать?
@@MsAlexandr76, ценю ваше мнение и считаю, что придираться - в целом плохая затея. И, чтобы мы друг друга понимали лучше, можете написать как вы определяете где придирка, а где указание на то, что собеседующий может посчитать за минус?
По DDD, Event Sourcing и CQRS очень спорно. Описанная как ивент сорсинг архитектура скорее была похожа на ивент дривен, что несколько разное. В ивент сорсинге события не простооповещение системы, но и источник построения данных (цепочка событий + снапшоты являются источником построения текущего состояния). А все, в конце при разборе оказывается указали на это) Архитектура из практического примера - ну тоже токое, уж если идти к нормальному уровню абстракции, то можно рассматривать что то типа Clean Architecture, там уровней абстракции куда больше и все универсальнее. При обсуждении асинхронности хорошо было бы упомянуть CAP теорему, если мы асинхронно по шине или сагой пытаемся ввести изменения в данные несколько сервисов. Про дедлоки ниже уже отписались) Вообще показалось как будто слишком лайтово для синьора
Очень интересное видео, особенно практическое задание. Кандидат довольно приятный парень, из советов - иногда бывают слова-паразиты, которыми заполняется время на обдумывание ответа. Ну и про RPC в практическом задании да, очень странно. Зато про опыт с профилировкой круто рассказал. Благодарю обоих участников!
ахах, вспомнилсебя, проходил собесы на сеньор разраба, в нескольких получил фидбек миддл, в нескольких сеньор, в одной приглашали на должность архиотектора, и в две другие фирмы на лид разраба с менторством команды так как есть опыт.
Не очень понял пример с Shopify и вообще всю эту полемику вокруг создания товара. Если товары создаются поштучно кликами пользователя, то у вас там будет gRPC. Если вы импортируете товары тысячами из экселевских файлов или внешних систем, то там вполне очевидно вырисовывается асинхронная очередь. Иными словами, я вообще не понял эту сферическую ситуацию в вакууме, где создание товара почему-то дорогое и может занимать минуты.
Бизнес-правила могут быть очень разными. Отличный пример такого долгого создания товара - Авито. Может несколько часов пройти с момента как вы опубликовали объявление на свой товар до момента, как он будет реально опубликован для всего интернета. А если не повезёт и нужна будет проверка модератором и будут какие-нибудь праздники, то время ожидания может и в днях исчисляться. Хочется верить, что сейчас уже быстрее всё проходит, но раньше было так.
@@DotNetInterviewPreparation спасибо за ответ! Тем не менее, разговор был не про долгое создание, а дорогое. Такое дорогое, что мы зачем-то хотим его в очередь засунуть и не можем быстро вернуть результат для отображения на клиенте. Что касается примера с авито, то сам товар же моментально создаётся и отображается в интерфейсе в списке ожидающих модерации-публикации. Очевидно, нет там очереди на C из CRUD -- просто сразу создаётся товар и дальше по статусам двигается. В общем, в моменте Вас куда-то не туда как будто повело, и никто особо не понял, что произошло.
@@DotNetInterviewPreparation на всякий случай, я пробежался снова по моментам, которые меня смутили, а то три недели прошло и я уже всё забыл. Часть разговора на 39-42 минутах, потом самая важная часть с 1:01:40. На мой взгляд, справедливо будет сказать, что речь шла в обоих моментах не про массовый импорт, а про клики пользователей, публикующих товары. По крайней мере, обратного озвучено не было. Также справедливо будет отметить, что в инфраструктуре, где в сутки миллион товаров новых регистрируется, можно будет ожидать десятки и сотни миллионов покупок в сутки. Эти покупки всегда обрабатываются в реалтайме (не может же сервис просто списать деньги и не показать пользователю, что товар из корзины исчез, а в списке заказов появилась новая запись), и бизнес-процесс покупки уж точно дороже бизнес-процесса создания товара.
Давайте уточню то, что я хотел подсветить в тот момент - если ты умеешь использовать какой-то инструмент, это не говорит о том, что его нужно использовать везде. Соответственно, я хотел подтолкнуть собеседника в эту сторону, придумывая различные варианты, где его инструмент будет не очень применим. Да, возможно, был приведен не на 100% очевидный пример, однако, суть была как раз в том, что в зависимости от бизнес потребностей инструменты могут и должны меняться.
![Tee Grizzley - Blow for Blow (feat. J. Cole) [Official Video]](http://i.ytimg.com/vi/wNLN5xsx5dc/mqdefault.jpg)
Пришел к такому выводу для себя, любой хороший сеньор может впринципе завалить любого хорошего сеньора
Если цель именно завалить, то это может сделать и джун)))
@@DotNetInterviewPreparation Нет, не может. Это не Сеньор. Он не живет кодом. Он просто хочет получать больше
Надо оценивать не умение кандидата вести себя на собеседовании, а его навыки и главное потенциал как разработчика. А при таком подходе будет у вас работать отличный актёр, рандомный как разработчик. Навыки собеседования нужны интервьюеру, чтобы в процессе непринуждённой беседы извлечь реально полезную, достаточную для принятия решения информацию за ограниченное время. Потенциал вообще мало кто способен увидеть, а это гораздо важнее знания какой-нибудь технологии, которую можно за вечер изучить.
Полностью с вами согласен, посмотрите момент с 48:30, где я об этом же говорю. Добавлю к тому, что говорил в видео, что это формат для тренировки кандидатов, а не их отбора для работы в компании.
я тоже использую gRPC)
Привет, по поводу задания, мне кажется все зависит от задачи бизнесов, если позволяют ресурсы, то почему бы не выполнять в синхроне, подняли нужное количество тачек и поставить выше балансировщик?) в примере с товарами как будто между синхроном и асинхронном лучше синхрон)) ИМХО
Но все зависти от анализа бизнесов и ресурсов
Отличный выпуск!👍
Именно так, в этом и была моя идея - использовать подходящие для задачи инструменты, а не те, к которым привык. К сожалению, это частая проблема, которую я и за собой тоже иногда замечаю.
вопросы хорошие, но кандидат уровня мидл и явно больше работал с монолитом
Грейды в разных компаниях разные. Думаю, что даже Синьор C# разработчика не взяли бы и джуном на Machine Learning роль. Всё зависит от потребностей фирмы ;-)
Задний фон сгенерировал с помощью нейронки )
Ага)
С каждым видосом всё лучше и лучше! Прогресс сильно заметен, продолжайте!
Спасибо большое, стараюсь)
Спасибо за полезное видео! Кандидат к себе располагает и отвечает норм.
Согласен. И на что еще стоит обратить внимание - что кандидат может даже не особо хорошо отвечать, но располагать к себе и тогда пройдет собеседование и будет нанят. Софт скилы играют очень важную, а порой и решающую роль на собеседованиях.
Про дедлоки явно какую то ерунду сказал.
Простейший пример:
Поток1: захватил объект A и хочет захватить B, поэтому ждёт.
Поток2: захватил B, хочет А, ждёт освобождения А
Даже если что-то сказал, то это скорее всего переволновался. В целом я понял что он хотел сказать и это главное ;-)
@@DotNetInterviewPreparation спасибо!
Рамка (фон) вокруг собеседников, занимает 75% экрана. Зачем это?
Эксперимент ☺️
9:14 Слово "штука" Вас задело, а слово "подсказать" в тексте вопроса - нет?! Да уж!!!!
Спасибо за комментарий и простите, если задел вас "штукой". Основная мысль здесь была в том, что на собеседовании лучше попросить минуту на подумать и ответить нормально, чем использовать слова, которые вроде бы как-то отвечают на вопрос, а по факту не отвечают.
@@DotNetInterviewPreparation Что Вы, "штука" задела именно Вас! Меня же задела придирка к "штуке" - ведь вопрос тоже задан неидеально: "ПОДСКАЖИТЕ ..."
@@MsAlexandr76, а я и не претендую на идеальность задаваемых вопросов, хотя в слове "подскажите" до сих пор не вижу ничего плохого.
Однако, как вы считаете, для кого создан этот канал: для тех, кто будет проходить собеседования или для тех, кто будет собеседовать?
На чем лучше фокусировать внимание: на том, как правильно отвечать на вопросы или на том, как их правильно задавать?
@@DotNetInterviewPreparation Я считаю: придираться (а "штука" - придирка чистой воды) к другому имеет право тот, кто сам точен!
А канал - хороший!
@@MsAlexandr76, ценю ваше мнение и считаю, что придираться - в целом плохая затея. И, чтобы мы друг друга понимали лучше, можете написать как вы определяете где придирка, а где указание на то, что собеседующий может посчитать за минус?
По DDD, Event Sourcing и CQRS очень спорно.
Описанная как ивент сорсинг архитектура скорее была похожа на ивент дривен, что несколько разное.
В ивент сорсинге события не простооповещение системы, но и источник построения данных (цепочка событий + снапшоты являются источником построения текущего состояния).
А все, в конце при разборе оказывается указали на это)
Архитектура из практического примера - ну тоже токое, уж если идти к нормальному уровню абстракции, то можно рассматривать что то типа Clean Architecture, там уровней абстракции куда больше и все универсальнее.
При обсуждении асинхронности хорошо было бы упомянуть CAP теорему, если мы асинхронно по шине или сагой пытаемся ввести изменения в данные несколько сервисов.
Про дедлоки ниже уже отписались)
Вообще показалось как будто слишком лайтово для синьора
Спасибо большое за такой подробный комментарий. Что касается сложности и глубины собеседования, это ещё будет дорабатываться 😉
Очень интересный формат, спасибо! подписался
Спасибо, буду продолжать вас радовать интересными видео.
Очень интересное видео, особенно практическое задание.
Кандидат довольно приятный парень, из советов - иногда бывают слова-паразиты, которыми заполняется время на обдумывание ответа. Ну и про RPC в практическом задании да, очень странно. Зато про опыт с профилировкой круто рассказал.
Благодарю обоих участников!
Очень здорово, когда можно с помощью таких людей, как Константин, заглянуть в собеседования со стороны собеседующего. Благодарю за обратную связь.
когда научился пользоваться молотком тебе начинает казаться что вокруг одни только гвозди
Думаю, что со всеми бывает ;-)
ахах, вспомнилсебя, проходил собесы на сеньор разраба, в нескольких получил фидбек миддл, в нескольких сеньор, в одной приглашали на должность архиотектора, и в две другие фирмы на лид разраба с менторством команды так как есть опыт.
Ого, вот это разброс! Не хватает только джуна 😉
Про распределенные транзакции достаточно было назвать паттерн Saga.
Так как это синьор уровень, то вполне можно ещё и в глубину про реализацию порассуждать на самом деле ;-)
Необычно что без приветствия. Но не сказать что это плохо. Лайк
Пока экспериментирую с форматом. С приветствием для вас было лучше?
@@DotNetInterviewPreparation не, так лучше, сразу к делу
спасибо, понравилось!
Спасибо за видео!
Спасибо за комментарий!
Можно убрать музыку? Мешает слушать
Да, где-то было слишком громко, в других видео должно быть лучше.
Не очень понял пример с Shopify и вообще всю эту полемику вокруг создания товара. Если товары создаются поштучно кликами пользователя, то у вас там будет gRPC. Если вы импортируете товары тысячами из экселевских файлов или внешних систем, то там вполне очевидно вырисовывается асинхронная очередь.
Иными словами, я вообще не понял эту сферическую ситуацию в вакууме, где создание товара почему-то дорогое и может занимать минуты.
Бизнес-правила могут быть очень разными. Отличный пример такого долгого создания товара - Авито. Может несколько часов пройти с момента как вы опубликовали объявление на свой товар до момента, как он будет реально опубликован для всего интернета. А если не повезёт и нужна будет проверка модератором и будут какие-нибудь праздники, то время ожидания может и в днях исчисляться. Хочется верить, что сейчас уже быстрее всё проходит, но раньше было так.
@@DotNetInterviewPreparation спасибо за ответ! Тем не менее, разговор был не про долгое создание, а дорогое. Такое дорогое, что мы зачем-то хотим его в очередь засунуть и не можем быстро вернуть результат для отображения на клиенте.
Что касается примера с авито, то сам товар же моментально создаётся и отображается в интерфейсе в списке ожидающих модерации-публикации. Очевидно, нет там очереди на C из CRUD -- просто сразу создаётся товар и дальше по статусам двигается.
В общем, в моменте Вас куда-то не туда как будто повело, и никто особо не понял, что произошло.
@@DotNetInterviewPreparation на всякий случай, я пробежался снова по моментам, которые меня смутили, а то три недели прошло и я уже всё забыл. Часть разговора на 39-42 минутах, потом самая важная часть с 1:01:40.
На мой взгляд, справедливо будет сказать, что речь шла в обоих моментах не про массовый импорт, а про клики пользователей, публикующих товары. По крайней мере, обратного озвучено не было. Также справедливо будет отметить, что в инфраструктуре, где в сутки миллион товаров новых регистрируется, можно будет ожидать десятки и сотни миллионов покупок в сутки. Эти покупки всегда обрабатываются в реалтайме (не может же сервис просто списать деньги и не показать пользователю, что товар из корзины исчез, а в списке заказов появилась новая запись), и бизнес-процесс покупки уж точно дороже бизнес-процесса создания товара.
Давайте уточню то, что я хотел подсветить в тот момент - если ты умеешь использовать какой-то инструмент, это не говорит о том, что его нужно использовать везде. Соответственно, я хотел подтолкнуть собеседника в эту сторону, придумывая различные варианты, где его инструмент будет не очень применим. Да, возможно, был приведен не на 100% очевидный пример, однако, суть была как раз в том, что в зависимости от бизнес потребностей инструменты могут и должны меняться.