Упражнения при найме для оценки инженерного суждения, демонстрирующие компромиссы

Почему чистые тесты по программированию упускают суть

Хорошие упражнения для проверки инженерного суждения должны выглядеть как реальная работа, а не набор головоломок.

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

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

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

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

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

Вы узнаёте больше из того, как они рассуждают при выборе, чем из того, помнят ли они учебный паттерн. Называют ли они свои предположения? Замечают ли возможные отказы? Выбирают ли они минимальное безопасное изменение, когда времени мало, или объясняют, почему глубокое исправление стоит задержки?

Тривия мало что скажет о том, как человек будет работать в вашей команде. Рассуждение — да. Чистые тесты делают кандидатов аккуратными. Неряшливые сценарии показывают, умеют ли они принимать здравое решение, когда всё далеко от аккуратного.

Что должно включать неряшливое задание

Хорошее упражнение начинается посреди реальной ситуации. Это ближе к работе.

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

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

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

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

Держите объём ограниченным. Одно интервью должно охватывать одну систему, одну проблему и небольшой набор решений. Например, попросите кандидата улучшить API, который таймаутит во время ежедневного запуска биллинга, при том что у команды две недели на исправление и нет бюджета на новую инфраструктуру. Этого достаточно, чтобы выявить суждение. Вы увидите, как они сортируют факты, называют риски, защищают надёжность и решают, что пока не трогать.

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

Выбирайте компромиссы в зависимости от роли

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

Если всем кандидатам давать один и тот же вид компромиссов, вы упустите то, что реально требуется по роли. Лучшие сценарии соответствуют решениям, с которыми человек столкнётся на работе.

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

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

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

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

Когда настройка совпадает с работой, кандидаты перестают гадать, чего вы хотите. Они показывают, как думают, когда ответ неясен, время ограничено, и каждая опция чего-то стоит.

Постройте упражнение шаг за шагом

Хорошее упражнение мало бумаги и много суждения. Часто одной страницы достаточно, если там есть реальная проблема, бизнес-цель, несколько жестких ограничений и место для вопросов.

Начинайте с результата, а не с задачи. «Улучшите эту систему» слишком расплывчато. «Сократить облачные расходы на 30% без простоев до следующего запуска» даёт кандидату реальную цель для оптимизации. Такие формулировки особенно подходят стартапам и небольшим командам, где стоимость, риск и скорость обычно тянут в разные стороны.

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

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

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

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

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

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

Когда подготовка сделана хорошо, интервью проходит спокойно. Кандидату остаётся думать, спрашивать и выбирать. Там и проявляется суждение.

Пример сценария, который можно адаптировать

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

Реальная проблема в текущем сервисе заказов. В час пик он начинает выбрасывать ошибки, таймаутить или возвращать устаревшие данные. Поэтому простая задача «построить фичу возврата» вовсе не проста. Любой план, который слишком сильно опирается на этот сервис, может провалиться в самый нужный момент.

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

Попросите план первого релиза, а не идеальный финальный дизайн. Вот где проявляется суждение. Кандидат должен решить, что исправить сейчас, а что отложить.

Попросите покрыть четыре практических пункта: что выпустить первым, как уменьшить ручную работу поддержки, как защитить систему в часы пик и как выкатить, измерять и откатывать изменение.

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

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

Один хороший вопрос хорошо работает: «Что вы сделаете на первой неделе?» Ответ покажет, умеет ли кандидат отличать срочное от приятного. Если он назовёт первое изменение, главный риск и метрику, за которой будет наблюдать после релиза, вы увидите суждение, а не сценическую полировку.

Вопросы, которые выявляют суждение в упражнении

Неряшливое упражнение работает только если ваши уточняющие вопросы заставляют выбирать.

Хорошие кандидаты не пытаются всё починить сразу. Они выбирают порядок, объясняют компромиссы и признают, что останется недоделанным.

Начните просто: «Вы можете выпустить одну часть на этой неделе. Что идёт в первую очередь?» Слушайте обоснование, связанное с пользовательской ценностью, риском или доходом. Слабые ответы звучат как список задач. Сильные — как план: запустить узкий путь, доказать спрос, оставить остальное ручным и не строить много кода до появления реальных пользователей.

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

Технический долг — вот где суждение становится реальным. Спросите: «Что вы сделаете по-простому сейчас, а какую черту категорически не переступите?» Хорошие кандидаты сознательно принимают долг. Они могут отложить рефакторинг, написать ручной инструмент поддержки или пропустить красивую абстракцию. Но они также должны назвать долг, который быстро дорожает: спутанные модели данных, отсутствие тестов вокруг биллинга или ад-хок-права доступа.

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

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

Оценивайте не только ответ. Оценивайте порог, при котором кандидат готов изменить курс. Часто именно там проявляется зрелое суждение.

Ошибки, которые губят сигнал

Плохое упражнение может сделать сильного кандидата средним, а среднего — выглядеть аккуратно.

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

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

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

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

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

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

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

Простая рубрика оценок

Хорошая шкала должна вознаграждать ясное суждение, а не отрепетированную речь.

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

Держите рубрику короткой. Если нужен длинный чеклист, упражнение, вероятно, слишком расплывчатое.

• Заметили ли они главный лимит быстро?
• Отделили ли они исправление на сегодня от чистки на следующий месяц?
• Попросили ли они факты прежде, чем выбирать путь?
• Объяснили ли они компромиссы простыми словами?
• Предложили ли они план, который обычная команда действительно сможет выполнить?

Небольшой пример делает разницу понятной. Система падает в пике, логи шумные, схема базы данных беспорядочная. Один кандидат предлагает переписать систему на новом стеке. Другой говорит: «Я бы уменьшил нагрузку, добавил мониторинг вокруг проблемного пути, остановил повреждение данных и запланировал очистку схемы после стабилизации.» Второй ответ обычно показывает лучшее суждение.

Оценивайте практичность, а не уверенность. Некоторые говорят с полной уверенностью и всё равно упускают реальный риск. Другие делают паузу, задают пару умных вопросов и строят лучший план.

Последний фильтр: доверила бы команда этому человеку в тяжёлую неделю? Если да — оценка должна это отражать.

Что делать после интервью

Упражнение не заканчивается, когда кандидат уходит. Если команда ждёт до следующего дня, она потеряет много сигнала.

Заблокируйте 10–15 минут сразу после сессии. Попросите каждого интервьюера сначала написать заметки в одиночку, а затем сравнить их. Так самый уверенный не перепишет память остальных.

Записывайте, что кандидат реально сказал. Избегайте ярлыков типа «умный», «сеньор» или «хороший коммуникатор». Запись вроде «сохранил старую очередь на пока, потому что переписка могла вызвать простои в биллинговую неделю» скажет гораздо больше, чем общее чувство.

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

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

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

Храните упражнение, заметки и шкалу в общей «коробке» для найма. Сохраните сценарий, уточняющие вопросы и несколько анонимизированных примеров сильных и слабых ответов. После нескольких интервью пересмотрите комплект. Если интервьюеры оценивают один и тот же ответ радикально по-разному, проблема в дизайне интервью, а не в кандидатах.

Малые стартап-команды быстро почувствуют ошибочный найм. Один человек с плохим суждением может создать месяцы работы по исправлению. Если хотите внешней помощи в формировании циклов найма, шкал и практических технических интервью, Oleg Sotnikov at oleg.is делает такую fractional CTO работу в прикладном, операционном стиле.