Ну если про исключения это throw и throw new/ throw ex, то в принципе не такой плохой вопрос. А вот по поводу интерфейсов и структур - вопрос чисто теоретический. Тоже мне задавали его, знал, что интерфейсы реализуются, и типа там свои проблемы есть, но подмывало спросить как часто у вас на проекте используются структуры.
Понимаю, что это неплохой способ оптимизации, но нужна ли эта оптимизация и тем более используется ли она на проекте, если вы такие вопросы задаете.

Ну может американцы няшки, у них немного другой подход скорее всего. По рассказу некоторых знакомых, они даже если кто-то сильно косячит -  стараются это не говорить грубо.
У меня просто была череда собесов как-то раз и были собесы 1 на 1 или там ну двое, но один почти все время молчал, а бывали собесы когда 3-4 человека, плюс аналитики плюс hr и просто бесперебойно тебя заваливают вопросами. На контрасте эти собесы прям чувствуются.

Лол нет

Что за вздор

Нихера нельзя технические задачи, которые конкретно разработчикам будут переданы эстимейтить с помощью архитекторов

Иначе эстимирование теряет вообще всякий смысл, можно вообще тогда на канбане сидеть и не выебываться

Нормальные разработчики нормально эстимируют, иногда могут заложить риски на всякую коммуникацию или на мутность таски, даже после всех рефайнментов

И лучше так чем как выше сказали иметь постоянные срывы сроков и перекидывание половины тасков из спринта в спринт

Архитектор сразу год на 2-3 юнит теста заэстимейтит?

Каждая таска будет минимум полгода

И да, как правило разрабы эстимейтят всегда меньше, чем архитектор

Чсв уровня московского жадного русского 15 летней выдержки
Каждый эстимейтит свой уровень абстрагирования от задачи, вот и все

Вот именно

Иначе выйдет микроменеджмент имени Юрия

Вот тут согласен полностью

Элементарно, сначала нормально разбить глобальную задачу на под задачи переезда, насколько это возможно, там будет очевиднее все гораздо

В целом, подход тот же, что и при обычном эстимировании сложной задачи

Так делает, например, Майкрософт. 4 собеса подряд по 45-60 минут каждый, с разными людьми, не всегда разработчики, но и не всегда одни менеджеры, одновременно максимум 2 интервьювера

Всем привет! Спасибо большое за активность и Ваши отзывы. Небольшой апдейт по этапам интервью:
1) Тех пре-скрининг - 45 минут. Проводит 1 интервьюер. Теоретические вопросы по .Net (core) и distributed systems.  
2) Тех интервью - до 1.5 часа. Проводит 2 интервьюера. Глубинное тех интервью, с модуляцией кейсов исходя из Вашего предыдущего опыта.
Буду рада рассказать больше :)

Я не оцениваю каждую тасочку в 2 часа. Я пишу верхнеуровневую оценку  на основании описанной архитектуры и качества команды которая есть на проекте. Моя цель оценить объем задач который влезет в 2 недели спринта. Очевидно что что-то быстрее пойдет, что-то медленнее. И вот именно для того, чтобы не заниматься херотой типа планинг покера я сразу ставлю объем задач на спринт и идем работать.
Если есть прямо какие-то возражения, что я вот не учел 100 факторов, мы идем обсуждать. Но обычно т.к. именно архитектор фидит картину сверху, то такое очень редко бывает.