Цикл собеседований для Staff Engineer: в чём ошибаются senior циклы

Почему большинство циклов для staff выдают офёрты senior

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

Причина, по которой это продолжает происходить, в том, что критерии для «senior» хорошо понимаются — хороший код, управляет сервисом, наставляет junior, проектирует фичи от начала до конца — а критерии для «staff» остаются размытыми. Staff engineering — это дисциплина выбора правильной задачи, выравнивания группы команд вокруг решения и правильности оценки технических trade-off на масштабе, где ошибка обходится дорого. Ничто из этого не видно в 45-минутном раунде кодирования.

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

Четыре измерения, которые действительно отличают staff

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

1. Масштаб суждения. Может ли кандидат определить правильную задачу в незнакомой ему области, при неполной информации и конкурирующих ограничениях? Senior инженеры решают задачу, которую вы им дали. Staff инженеры указывают, какую задачу решать.
2. Качество архитектурных решений. Может ли кандидат рассуждать о системе на уровне, где trade-off реальны — стоимость, latency, blast radius, организационная связанность — и защитить решение в письменной форме? Это не то же самое, что воспроизведение учебного проекта.
3. Влияние через команды. Может ли кандидат описать время, когда они изменили направление работы вне своей прямой команды, и объяснить механизмы — документ, встреча, прототип — которые это сделали возможным? «Я дал обратную связь в ревью» — это не staff уровень. «Я написал дизайн-документ, который объединил три конкурирующих предложения в одно» — это staff уровень.
4. Техническое наставничество на расстоянии. Может ли кандидат повышать стандарты инженеров, которыми они не управляют, по темам, в которых они не эксперты команды? Это порог, отделяющий staff от senior инженера с дополнительными годами опыта.

Каждый этап цикла должен быть спроектирован для проверки одного или двух из них, а не для переоценки senior уровня.

Цикл, этап за этапом

Итого: примерно 6 часов времени кандидата, примерно 10 часов времени интервьюеров. Шесть этапов:

Этап 1: Экран менеджера по найму (60 мин)

Не обсуждение fit. Рабочий разговор о реальной проблеме в вашем стеке, сформулированной достаточно свободно, чтобы кандидат задал вопросы перед предложением решения. Менеджер по найму слушает: сужает ли кандидат проблему перед решением? Спрашивает ли о ограничениях, которые пропустит senior — структуре организации, стоимости on-call, риске миграции?

Этот этап заменяет раунд «расскажи о себе», возглавляемый рекрутёром. Сохраните логистику для отдельного 20-минутного звонка по расписанию.

Этап 2: Письменный дизайн-документ (4–8 часов, асинхронно)

Самый высокосигнальный этап в staff цикле и тот, который большинство компаний пропускают, потому что беспокоятся, что это слишком много требовать от кандидата. Но это не так. Senior кандидаты регулярно выполняют 2-часовые домашние задания; staff кандидат выполняет сосредоточенное дизайн-упражнение, потому что артефакт также служит способом оценить роль.

Формулировка: реалистичная, намеренно недоопределённая задача из вашей области. «Мы хотим внедрить workflow engine для оркестрации, которую наша команда payments в настоящий момент делает в ad-hoc Lambda'ах. Напишите документ из 3–8 страниц, который обосновывает подход, называет рассмотренные альтернативы и определяет три главных риска.»

Что документ скажет вам, чего не может 60-минутное совещание у доски:

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

Оценивайте документ по его собственной рубрике до следующего раунда. Слабый документ не спасают сильным whiteboard раундом.

Этап 3: Глубокий разбор дизайн-документа (75 мин)

Панель из двух человек — менеджер по найму и один staff или principal инженер — работают с документом вместе с кандидатом. Кандидат не презентует; панель читает документ заранее, и время уходит на follow-up вопросы. Формат:

• Первые 15 минут: альтернативы. «Вы отклонили approach с использованием step-functions. Почему? Что изменилось бы, если бы ваш latency budget был 50 ms вместо 5 s?»
• Следующие 30 минут: режимы отказа. Пройдите, как система ломается в трёх конкретных условиях, которые вы предоставляете. Наблюдайте, как кандидат обновляет свой дизайн в реальном времени.
• Последние 30 минут: миграция. «У нас есть 47 существующих Lambda'ах, которые нужно переместить в это. Пройдитесь через первые 90 дней.»

Этот этап тестирует измерения 1 и 2 совместно: определил ли кандидат правильную задачу, и действительно ли их дизайн защищён, когда ограничения меняются?

Этап 4: Раунд кодирования (60 мин)

Всё ещё требуется, даже для staff. Две причины: staff инженер, который вообще не может писать код, редкий и плохой, и раунд показывает, может ли кандидат всё ещё делать пару с senior инженерами на работе, которую они действительно должны делать.

Пропустите LeetCode. Используйте раунд отладки или рефакторинга на реальном коде — 200–400 строк, нетривиальный баг, явный запрос оставить кодовую базу в лучшей форме, чем они её нашли. Оценивайте по рубрике кодирования, которую вы используете для senior кандидатов, но взвешивайте диагностическое мышление и качество code-review выше, чем throughput.

Staff кандидат, который бегло определяет баг, называет два других проблемы, которые он не будет исправлять, и объясняет наименьший безопасный рефакторинг, делает ровно то, что требуется в работе. Тот, кто пишет код быстрее senior кандидата — нет.

Этап 5: Интервью по влиянию через команды (60 мин)

Это раунд, который большинство staff циклов не запускают, и именно он наиболее надёжно ловит ложноположительный результат — senior инженер, который блестяще решает проблемы, но не может сдвинуть группу команд.

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

1. «Расскажите о технической позиции, которую вы занимали, и которая была непопулярна в команде. Что изменило вашу позицию, или что изменило их?»
2. «Опишите время, когда вы остановили проект, который не должен был выходить в продакшн. Как вы это сделали, не теряя доверия людей, работавших над ним?»
3. «Пройдитесь по последнему техническому документу, который вы написали и который другая команда приняла как основу для своей работы.»
4. «Расскажите о времени, когда вы наставляли инженера вне своей цепочки отчётности по чему-то, в чём они через год были лучше вас. Что вы сделали?»

Ответы кандидата должны называть людей, документы, встречи и результаты. Неясные ответы — «мы выравнялись, мы построили консенсус, мы выпустили» — проваливают этот раунд. Работа богата механизмами; интервью должно быть таким же.

Этап 6: Bar raiser (45 мин)

Staff или principal инженер из-за пределов команды, оценивающий кандидата по staff бару компании, а не по потребностям команды. Их вопрос к себе в конце: «Я бы хотел работать с этим человеком над задачей, которая мне нравится?»

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

Что исключить

Несколько вещей, которые цикл для staff не должен включать, и причины, почему каждая — это ловушка:

• Два раунда кодирования. Один достаточен. Второй не скажет вам ничего нового и даст кандидату сигнал, что вы не знаете, кого нанимаете.
• Раунд проектирования систем, который просто «спроектировать Twitter». Общие формулировки тестируют запоминание. Используйте задачу из вашей реальной области, чтобы кандидат действительно должен был думать.
• Интервью «принципов лидерства», которое просто поведенческое интервью с другим названием. Если вы уже запускаете структурированный поведенческий раунд, складывание его в один хорошо продуманный раунд по влиянию через команды сильнее, чем запуск двух тонких.
• Раунд презентации, если только презентация не является частью работы. Просить кандидата представить 30 минут своей прошлой работы нормально, если роль требует публичных презентаций инженерам. В противном случае он тестирует неправильный навык.

Калибровка интервьюеров на bar для staff

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

1. Напишите якорированные руководства по оценке для каждого измерения. 3 из 4 по «качеству архитектурных решений» должно означать конкретное — например, «определяет trade-off балансировки нагрузки без подсказки и объясняет стоимость ошибки». 4 должно означать «поднимает ограничение, которое не содержалось в формулировке, и переформулирует задачу». Это та же дисциплина оценочных карт, которая работает на senior уровне, с разными якорями.
2. Запустите два тренировочных дебрифа перед первым реальным. Возьмите два недавних staff офера (один принят, один отклонен) и имейте интервьюеров цикла оценить их вслепую, затем дебрифинг. Цель — выявить, где панель не согласна относительно того, что означает staff, перед тем как реальный кандидат будет на линии. Это точно калибровка, которую большинство команд пропускает и потом жалеют.
3. Отслеживайте коэффициент даунлевелирования. Если ваш цикл выдаёт staff офер 30% времени и senior офер 50% времени для кандидатов, применившихся на staff, ваш экран менеджера по найму пропускает слишком много senior кандидатов. Если он выдаёт no-hire 60% времени, ваш входящий источник неправильный. В любом случае, метрика показывает вам, где это исправить.

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

Если вы настраиваете или исправляете цикл собеседований для staff engineer:

1. Напишите рубрику четырёх измерений на этой неделе. Даже v1 с грубыми якорями лучше, чем отсутствие рубрики вообще.
2. Добавьте письменный дизайн-документ, если вы его ещё не добавили. Это самый высокосигнальный раунд и дешевле всего внедрять.
3. Замените один из ваших раундов кодирования интервью по влиянию через команды. Trade практически всегда стоит того.
4. Запустите два калибровочных дебрифа на прошлых кандидатах перед следующим live циклом.
5. Проведите аудит последних трёх найма staff относительно рубрики задним числом. Если двое из них слабо оценивают измерение, которое вы не тестировали, это раунд, который вам не хватает.

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