Техническое интервью по коду: ревью и рефакторинг

Техническое интервью по ревью кода часто превращается в конкурс на поиск мелких опечаток. Такой формат плохо предсказывает работу: сильный инженер сначала уточняет требования, отделяет критический дефект от косметики и только потом предлагает рефакторинг. Ниже — сценарий на 40–50 минут, критерии оценки и пример на Python 3.12, который можно дать кандидату без скрытых ловушек.

Что именно проверяет такое интервью

Задача не в том, чтобы кандидат угадал эталонный патч. Вы проверяете, как он работает с незнакомым кодом, где требования неполны, а цена ошибки различается.

• Понимание поведения. Кандидат выясняет, какие входные данные допустимы и что функция должна вернуть.
• Поиск рисков. Он замечает ошибки корректности, проблемы производительности, безопасности и тестируемости.
• Приоритизацию. Баг, из-за которого теряются данные, важнее неудачного имени переменной.
• Коммуникацию. Замечание должно объяснять проблему и предлагать проверяемый следующий шаг.
• Безопасный рефакторинг. Изменения должны сохранять контракт, а не просто делать код короче.

Для интервью заранее зафиксируйте язык и версию. Пример ниже рассчитан на Python 3.12 и стандартную библиотеку. Для Java, Go или TypeScript нужны другие детали, но принцип останется тем же: кандидат работает с конкретным фрагментом, а не с абстрактным вопросом о «хорошем коде».

Сильный кандидат не обязан найти все проблемы. Он должен понять, какие из них опасны, доказать это примером и выбрать разумный порядок исправлений.

Сценарий интервью на 45 минут

1. Пять минут — контекст. Расскажите назначение функции, ожидаемый формат входа и ограничения. Не прячьте критичные требования в подсказках.
2. Десять минут — самостоятельное чтение. Не перебивайте кандидата. Смотрите, начинает ли он с вопроса о контракте или сразу предлагает переписать весь фрагмент.
3. Пятнадцать минут — ревью. Просите комментировать конкретные строки: что не так, при каком входе проявится, насколько это срочно.
4. Десять минут — рефакторинг. Кандидат выбирает одну-две проблемы, пишет изменение и объясняет, что должно остаться неизменным.
5. Пять минут — проверка границ. Дайте один новый сценарий: пустую строку, большой текст или отрицательный лимит. Смотрите, меняет ли кандидат решение после появления факта.

До начала упражнения сообщите, можно ли запускать код, пользоваться документацией и писать тесты. Запрет на документацию превращает задачу в проверку памяти, а не в рабочее ревью.

Фрагмент для разбора: сначала контракт, потом стиль

Кандидату можно показать такую функцию. Она считает самые частые слова в тексте.

def top_words(text, limit=10):
    words = text.lower().split(" ")
    counts = {}
    for word in words:
        if word in counts:
            counts[word] += 1
        else:
            counts[word] = 1
    return sorted(
        counts.items(),
        key=lambda item: item[1],
        reverse=True
    )[:limit]

Не просите сразу «найти пять ошибок». Сначала задайте вопрос: «Какой контракт вы предполагаете для этой функции?» Хороший разбор быстро приводит к уточнениям:

• Нужно ли считать знаки препинания частью слова.
• Должны ли «Дом» и «дом» считаться одним словом.
• Что делать с несколькими пробелами и переводами строк.
• Что возвращать при пустом тексте и при limit=0.
• Есть ли ограничение на размер текста и допустимо ли хранить все уникальные слова в памяти.

Здесь важна граница между багом и неподтверждённым предположением. Разбиение только по обычному пробелу — дефект, если функция должна обрабатывать переносы строк и повторяющиеся пробелы. Но требование убрать пунктуацию нельзя объявлять обязательным без контракта.

Как выглядит содержательное замечание

Слабая формулировка: «Код не очень питоничный». Сильная: «При строке с двумя пробелами функция добавит пустую строку как слово. Например, "red blue" даст отдельный ключ "". Если пробелы не должны влиять на результат, нужно изменить разбор и добавить тест».

Ещё один полезный вопрос: «Как изменится время работы, если в тексте миллион слов?» Текущая версия отдельно сортирует все уникальные слова. Это нормально, если нужно вернуть полный упорядоченный список, но может быть избыточно при маленьком limit. Кандидат не обязан сразу предлагать сложную структуру данных; он должен связать оптимизацию с измеримым ограничением.

Рефакторинг без подмены задачи

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

import re
from collections import Counter

WORD_PATTERN = re.compile(r"[^\W\d_]+", re.UNICODE)


def top_words(text, limit=10):
    if limit < 0:
        raise ValueError("limit must be non-negative")

    words = WORD_PATTERN.findall(text.casefold())
    return Counter(words).most_common(limit)

Это не единственно правильное решение. Регулярное выражение выбирает последовательности Unicode-букв и игнорирует цифры. Если продукт считает «v2» словом или должен сохранять дефисы, контракт и шаблон нужно изменить. В интервью оценивайте не сам шаблон, а то, заметил ли кандидат это решение и проговорил ли его последствия.

Следующий шаг — тесты на границы. Даже если вы не требуете полноценный файл тестов, кандидат должен назвать или написать проверки для пустого текста, нескольких пробелов, регистра, пунктуации и отрицательного лимита.

Как сравнивать варианты упражнения

У формата есть несколько рабочих вариантов. Выбор зависит от того, какую часть инженерной работы вы хотите увидеть.

Не смешивайте все варианты в один час. Если кандидат одновременно отлаживает, проектирует новую архитектуру и пишет тестовый фреймворк, вы измеряете стрессоустойчивость и скорость печати, а не качество инженерных решений.

Рубрика оценки вместо личного впечатления

После интервью запишите наблюдаемые факты. Например, кандидат нашёл проблему с пустыми токенами, воспроизвёл её входной строкой, предложил тест и только затем перешёл к регулярному выражению. Это полезнее, чем запись «понравился».

• 0 баллов: не может описать поведение кода или говорит только о стиле.
• 1 балл: находит очевидный дефект, но не может показать вход, на котором он проявляется.
• 2 балла: находит несколько проблем, расставляет приоритеты и предлагает проверку.
• 3 балла: учитывает контракт, границы, стоимость изменений и ясно объясняет компромиссы.

Такую шкалу нельзя превращать в арифметику ради арифметики. Она нужна, чтобы два интервьюера обсуждали одни и те же признаки, а не впечатление от уверенного голоса кандидата.

Что ломается в самом формате

Ловушки, о которых кандидат не предупреждён

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

Поиск косметических проблем

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

Рефакторинг ради сокращения строк

Короткий код не всегда лучше. В примере с подсчётом слов регулярное выражение делает логику компактнее, но одновременно добавляет правило токенизации. Если команда не договорилась о таком поведении, рефакторинг может скрыть изменение продукта.

Сноска. Рефакторинг — изменение внутренней структуры кода без намеренного изменения его внешнего поведения. Если меняется контракт функции, это уже не только рефакторинг: изменение нужно отдельно описать и проверить.

Что делать дальше

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