Приходилось ли получать задачи, с которыми не был согласен по реализации или требованиям

Что проверяют

Умеете ли вы спорить по делу и работать с решением, которое приняли без вас. Заодно смотрят, где проходит ваша граница: возражение про стиль кода и возражение про потерю данных должны вести себя по-разному.

Как отвечать

Одна история плюс внятный порядок действий:

• отделить требование от реализации. Спор о том, что делать, идёт к владельцу продукта, спор о том, как делать, решается внутри команды;
• выяснить задачу за формулировкой. Часто требование это уже чьё-то решение, а настоящая проблема допускает вариант проще;
• принести аргумент в измеримой форме: сколько дней стоит, что сломается на реальном объёме данных, какой остаётся риск. Прототип и замер убеждают лучше мнения;
• если решение осталось прежним, зафиксировать риск письменно в задаче и сделать как договорились, без саботажа;
• вернуться к теме, когда появятся факты.

Хорошо звучат типичные для Python споры: тянуть тяжёлую зависимость ради одной функции, писать своё вместо готового, менять схему большой таблицы одним запросом вместо постепенного заполнения. Отдельный плюс, если назовёте случай, где неправы оказались вы и это выяснил замер.

Где спотыкаются

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

Второе: тратят силы на мелочи. Формат строк, длина строки, порядок импортов закрываются линтером и форматтером один раз, а не обсуждением на каждом ревью.

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