Кто выявлял логические дефекты в реализации

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

Кто в вашей команде отвечал за правильность логики и как устроена цепочка, на которой ловятся ошибки. Интервьюеру важно услышать, что первой линией разработчик считает себя, а не QA. Следом почти всегда просят вспомнить конкретный логический дефект: как его нашли и что сделали, чтобы он не вернулся.

Как отвечать

Опишите слои, на которых дефекты ловились у вас, и свою роль в каждом:

• автор кода: юнит-тесты на pytest с граничными случаями, параметризация через @pytest.mark.parametrize, тесты на свойства через Hypothesis, который сам подбирает неудобные входные данные;
• ревью: второй разработчик смотрит на условия, границы циклов, обработку None и пустых коллекций;
• статический анализ: mypy или pyright и ruff ловят ошибки типов и подозрительные конструкции. Честно скажите, что логику они проверяют слабо;
• QA и приёмка: тестировщик или аналитик сверяет поведение с требованиями, и именно там часто всплывает «работает, но не так»;
• прод: алерты, Sentry, сверка отчётов. Дефект, найденный пользователем, стоит разобрать отдельно.

Затем одна своя история. Типичные логические ошибки в Python, которые интервьюеры сразу узнают: float для денег вместо Decimal, путаница наивных и aware datetime и часовых поясов, изменяемое значение по умолчанию в аргументе функции, ошибка на единицу в пагинации, проверка if value:, которая отбрасывает законный ноль. Расскажите, кто нашёл, на каком этапе и какой тест вы добавили после исправления.

Если дефекты находил в основном QA, не прячьте это, а скажите, что вы изменили у себя после: больше граничных тестов, чек-лист для ревью.

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

Отвечают «баги ищет тестировщик». Это сразу снижает оценку: ответственность за логику начинается с автора кода.

Говорят, что статический анализ находит логические ошибки. Линтер не знает, что скидка должна считаться от суммы без доставки.

Исправляют дефект без регрессионного теста. Через полгода та же ошибка возвращается при рефакторинге.