Приходилось ли погружаться в предметную область проекта и участвовать глубоко
Что проверяют
Вы исполнитель задач или инженер, который понимает, зачем система существует. В командах на Go это часто платежи, биллинг, логистика, телеком, где ошибка в понимании домена дороже ошибки в коде и всплывает намного позже.
Как отвечать
Возьмите одну историю, где без разбирательства реализация вышла бы неверной, и проведите её по шагам: что за область, какой вопрос вы задали, что выяснилось, что поменялось в решении.
Примеры, которые звучат достоверно:
- собрали глоссарий и обнаружили, что одно слово в двух отделах означает разное, из-за чего схема статусов получилась бы неправильной;
- выяснили правило округления денег и перешли на целые единицы вместо чисел с плавающей точкой;
- разобрались, что отмена заказа имеет несколько разных состояний в учёте, и это изменило модель;
- сходили к поддержке и посмотрели, как люди реально пользуются системой.
Покажите, что знание дошло до кода: пакеты и типы названы словами предметной области, а не utils и manager, инварианты проверяются в доменном слое, вместо голых строк и чисел заведены свои типы. Завершите проверяемым эффектом: вопросы к аналитику стали возникать до разработки, а не на демонстрации.
Где спотыкаются
Отвечают про технологии: очереди, сервисы, база данных. Спрашивали про смысл системы, и такой ответ вопрос не закрывает, а иногда и подтверждает опасение.
Второе: вставляют выдуманные проценты ускорения и роста точности прогноза. Первый же уточняющий вопрос про методику подсчёта эту историю разваливает.
Третье: не могут вспомнить ни одного вопроса, заданного бизнесу. Погружение как раз и видно по вопросам: что считается исключением, как поступать при частичной оплате, чем заканчивается рабочий день пользователя. Без них рассказ звучит как пересказ чужого шаблона.