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