Скрытые тесты для отбора senior-разработчика: 4 компетенции и 4 теста, которые leetcode-интервью не покажет
«Тот, кто пишет код, который понимают только машины — джуниор. Тот, кто пишет код, который понимают другие люди — middle. Тот, кто понимает чужой код и улучшает его без эго — senior».
— Мартин Фаулер, Refactoring, 1999
Четвёртый кейс серии о скрытых тестах в отборе персонала. CTO B2B SaaS-компании Андрей Михайлович искал senior-разработчиков. Leetcode-интервью проходили все, в реальной работе оказывались посредственными. Решение — 4 теста, которые показывают то, что leetcode скрывает.
Стандартное техническое интервью в IT — это leetcode-задачи, теоретические вопросы по алгоритмам, обсуждение архитектурных паттернов. Кандидат, который к этому готовился, проходит. Но через 3 месяца после найма часто оказывается, что он не умеет работать в команде, не задаёт вопросов, защищает свои решения вместо обсуждения. Это не «технические» проблемы — это поведенческие. В реальной разработке senior-уровень определяется не «знанием алгоритмов», а способностью читать чужой код, признавать незнание, работать в паре, переносить критику. Эти навыки не видны в leetcode-интервью. В этой статье — кейс CTO небольшой B2B SaaS-компании Андрея Михайловича, который перестроил отбор senior-разработчиков через 4 скрытых поведенческих теста.
Ко мне пришёл Андрей Михайлович, 51 год, CTO B2B SaaS-компании (продукт для управления складскими операциями). В компании около 30 человек, разработка — 4 команды. Запрос: «Андрей, я уже год нанимаю senior-разработчиков, и три из шести нанятых через 3 месяца оказываются не senior, а middle с громкой самооценкой. Они проходят техническое интервью, я их беру. Через месяц-два видно: они пишут код, но не читают чужой, не задают вопросов команде, защищают свои решения как личное достоинство. Это не senior. Senior — это про коллективную ответственность за код. Как мне их отличить на интервью?». Я разработал ему систему из 4 скрытых тестов:
Тест 1 — Парное программирование с младшим разработчиком (как ведёт себя в роли «старшего»)
Тест 2 — Чтение чужого кода: «расскажи, что он делает» (а не «найди ошибку»)
Тест 3 — Вопрос на незнакомую технологию — тест «я не знаю» (реакция на пробел в знаниях)
Тест 4 — Code review с подсадным «автором» (как кандидат держит позицию и слышит контраргументы)
За 18 месяцев применения: 47 кандидатов прошли день отбора, 5 нанято (5 работают до сих пор); среднее время выхода нового senior на полную продуктивность сократилось с 4 до 2 месяцев; запросы на «помоги разобраться» от подчинённых выросли в 2 раза (хороший знак — старшие стали доступнее); отток senior-разработчиков 0% за 18 месяцев. Главное различие классического технического интервью и системы скрытых тестов: leetcode измеряет, как кандидат решает задачу один. Поведенческие тесты измеряют, как он работает с командой и чужим кодом — что и составляет 80% работы senior-разработчика.
⚠️ Этическая рамка
Особенность тестов для разработчика: 3 из 4 тестов используют действующих сотрудников компании (младший разработчик, автор кода). Они должны знать, что участвуют в ассессменте, и быть проинструктированы. Никакого «обмана сотрудников». Также: исходный код, используемый в тестах, должен быть рабочим (production-grade или близкий) — это даёт реалистичность.
Часть 1. Запрос: «техническое интервью проходят, в работе посредственные»
Андрей Михайлович пришёл по рекомендации коллеги по индустрии. 51 год, CTO B2B SaaS-компании, делающей систему управления складскими операциями для среднего бизнеса. В компании 30 человек, 4 продуктовые команды, ему подчиняется лично 3 тимлида + 1 архитектор + 8 разработчиков.
Первая фраза:
— Андрей, у меня странная проблема. Я уже год нанимаю senior-разработчиков. Из шести нанятых трое — это не senior. Они middle с громкой самооценкой. Они пишут код — нормально. Но они не умеют главного. Они не читают чужой код. Они не задают вопросов в команде, когда не понимают. Они защищают свои решения как личное достоинство — на code review с ними проще согласиться, чем дискутировать.
В моём понимании senior — это не «более опытный middle». Это другой уровень. Senior — это про коллективную ответственность за продукт. Он должен уметь подойти к чужому участку кода, разобраться, улучшить. Он должен задавать вопросы, когда не уверен. Он должен принимать критику и менять решения, если она обоснована.
На техническом интервью этого не видно. Все говорят правильные слова. Алгоритмы решают. Системный дизайн обсуждают. Я не понимаю, как отличать. Я уже потерял на трёх неподходящих кандидатах около 4 миллионов рублей за полгода — зарплата + время на обучение + время на расставание. Помоги.
Я слушал и видел три вещи:
- Классическая проблема современного IT. Техническое интервью оптимизировано под одну форму компетенции (умение решать задачи в одиночку под наблюдением). А реальная работа senior-разработчика — это 70–80% работы с командой и чужим кодом. Эти две вещи слабо коррелируют.
- Андрей точно сформулировал разницу. «Senior — это коллективная ответственность за код». Это не клише. Это рабочее определение, под которое можно делать тесты.
- Он готов к перестройке системы. Он не просит «один волшебный вопрос» — он понимает, что нужен ассессмент. С таким клиентом — можно работать всерьёз.
Часть 2. Четыре ключевых компетенции senior-разработчика
Компетенция 1. Способность читать чужой код
Senior-разработчик ежедневно работает с кодом, который писали другие. Это в десятки раз больше его собственного кода. Способность понимать чужие решения и находить логику автора — базовая, и она напрямую коррелирует с продуктивностью. По исследованиям ICSE (International Conference on Software Engineering, многочисленные), разработчики тратят 58–70% времени на чтение кода, а не на его написание.
Компетенция 2. Готовность сказать «я не знаю»
Senior отличается от middle не тем, что «знает всё». А тем, что умеет признать пробел и быстро найти ответ. Middle часто пытается «выкрутиться», догадаться, замаскировать пробел. Senior говорит «я не знаю, давайте посмотрим документацию» — и продолжает.
Это связано с intellectual humility (Leary et al., 2017) — личностной чертой, коррелирующей с успехом в сложных профессиях. У senior-разработчиков она значительно выше средней.
Компетенция 3. Качественное парное программирование
Способность работать в паре, особенно с менее опытным — критический навык senior. Это включает: умение объяснять, не унижая; умение давать паузы для размышления; умение задавать наводящие вопросы вместо «правильных ответов»; умение оставлять решение за младшим, даже если у самого есть более «быстрое».
Williams & Kessler (2003) в книге Pair Programming Illuminated показали: эффективность пары senior+junior значительно выше двух senior — но только если senior умеет вести парное программирование. Иначе пара становится «senior пишет, junior смотрит».
Компетенция 4. Эго-устойчивость в code review
Code review — это постоянный диалог о коде. Senior должен уметь и принимать критику не как личное оскорбление, и защищать обоснованные решения, не поддаваясь давлению. Это тонкий баланс, которого нет у многих middle.
По исследованиям Bacchelli & Bird (2013, Expectations, Outcomes, and Challenges of Modern Code Review) — главная причина «токсичных» code review — эго-зависимость авторов и ревьюеров. Senior без эго-устойчивости разрушает культуру code review в команде.
Часть 3. Четыре скрытых теста
Тест 1. «Парное программирование с младшим» (60 минут)
Цель: измерить поведение кандидата в роли «старшего» в паре.
Сценарий: кандидата приглашают «попарно поработать над небольшой задачей с одним из наших младших разработчиков, у него возникла трудность, поможете?». Это представляется как помощь, не как тест. В паре — действующий младший разработчик из команды (знает, что это ассессмент).
Задача — реальная: рефакторинг небольшого куска кода с непонятным поведением. Младший разработчик предварительно «уперся» в задачу. Кандидат — в роли наставника.
Поведенческие маркеры (записывает младший после сессии):
- Спросил ли кандидат, что младший уже пробовал? — да/нет
- Сел рядом физически или просил «открой мне на экране»? (Senior предпочитает paired, не «я смотрю»)
- Кто двигал курсор? Senior — обычно младший. Microclass-microservice middle — обычно сам.
- Сколько раз кандидат задавал вопрос «как ты думаешь, что здесь?» вместо «надо сделать так»? Чем больше вопросов — тем сильнее наставник.
- Признал ли кандидат хоть один раз «хорошая мысль» или «я не подумал»?
- В конце — что говорит младший? «Я понял задачу» (хорошо) или «он мне всё объяснил» (плохо — значит, кандидат решил сам)?
Что это раскрывает: базовый паттерн работы senior. Тот, кто не умеет работать с младшим, не справляется и со взрослой командой — он либо ничего не объясняет, либо всё делает сам.
★ Тест 2. «Расскажи, что делает этот код» (45 минут)
Цель: измерить способность читать чужой код.
Сценарий: кандидату показывают кусок реального production-кода из проекта компании (200–400 строк, неочевидная логика, плохо документированный). Задание не «найди баг» и не «отрефактори». Задание: «Расскажите, что этот код делает. По частям, своими словами. Я буду задавать уточняющие вопросы».
CTO сидит рядом, иногда переспрашивает: «А почему здесь возвращается null?», «А что если переменная X не задана?».
Маркеры:
- С чего начал — с верху до низу или с поиска «главной функции»? Senior обычно ищет точку входа.
- Сколько уточняющих вопросов задал кандидат сам? («А что это за тип? А откуда этот импорт?»)
- Через 45 минут — какую часть кода объяснил полностью?
- Был ли момент «не знаю, что здесь происходит»? Если да — что сделал дальше (попросил доступ к окружающему коду / попытался догадаться / «выкрутился»)?
- Заметил ли «странности» в коде (анти-паттерны, потенциальные баги, дубликаты)?
Что это раскрывает: главный навык senior — это чтение кода, не написание. Тот, кто за 45 минут не может объяснить, что делает 300 строк, и не задаёт правильных вопросов — не senior, как бы он leetcode не решал.
Тест 3. «Вопрос на незнакомую технологию» (5–10 минут)
Цель: измерить реакцию на «я не знаю».
Сценарий: в техническом интервью CTO задаёт один вопрос на технологию, которую кандидат точно не использовал. Если он Python-разработчик — вопрос про Erlang OTP. Если Java-Spring — про Rust ownership. Если фронтенд React — про WebGPU. Это не «провал» — это проверка реакции на пробел.
Возможные реакции:
- Пытается «выкрутиться», давая общие фразы про «асинхронность» — плохой сигнал. Middle, маскирующий пробелы.
- Грубо признаёт «нет, не знаю, я в этом не работал», и всё — средний сигнал. Честно, но не любопытно.
- Признаёт «я с этим не работал, но я понимаю общую идею parallel computing, и из того, что вы рассказываете, я предполагаю, что вопрос про конкретные нюансы actor model. Можете рассказать, у меня нет точного ответа, но мне интересно, как они это решают?» — идеальный senior. Признал, но любопытен, способен размышлять «по соседним знаниям», открыт к новому.
Что это раскрывает: intellectual humility — компетенция, которая у настоящих senior намного выше, чем у middle с громкой самооценкой.
Тест 4. «Code review с подсадным автором» (30 минут)
Цель: измерить эго-устойчивость и способность к диалогу.
Сценарий: кандидату дают на review pull request с реальным куском кода. Просят: «Сделайте полноценный review — что здесь хорошо, что плохо, что бы изменили». Кандидат пишет комментарии.
После того, как кандидат закончил, заходит «автор кода» (подсадной — это действующий senior компании). Он принимает комментарии и начинает спорить с частью из них. По 2–3 пунктам он соглашается, по 2–3 — приводит обоснованные контраргументы, по 1–2 — приводит необоснованные аргументы и давит «давайте всё-таки оставим как есть».
Маркеры:
- Когда автор приводит хороший контраргумент — кандидат признаёт «да, вы правы, я не подумал» или продолжает упорствовать?
- Когда автор давит без аргументов — кандидат сдаётся («ну, как хотите») или твёрдо говорит «нет, мне кажется, тут стоит исправить»?
- Какой тон в обсуждении? Senior сохраняет уважительный тон даже в споре. Middle часто переходит на «вы что, не понимаете?»
- После сессии — что кандидат думает о коде? «В целом нормальный, я бы кое-что поправил» (хороший знак) или «там всё плохо» / «там всё хорошо» (плохие — крайние реакции)?
Что это раскрывает: главная компетенция в code review — это дифференцированная позиция: соглашаться, когда обоснованно, и держать позицию, когда давят без аргументов. Senior умеет это делать без эмоциональной нагрузки.
Часть 4. День отбора (5–6 часов)
Расписание:
| Время | Эпизод | Что измеряем |
|---|---|---|
| 10:00–10:30 | Базовое интервью с CTO | Опыт, проекты, мотивация |
| 10:30–11:15 | Техническое интервью (включая Тест 3 — незнакомая технология) | ★ Тест 3 встроен |
| 11:15–12:00 | «Расскажи, что делает этот код» | ★★ Тест 2 — чтение чужого кода |
| 12:00–13:00 | Парное программирование с младшим | ★ Тест 1 — наставничество |
| 13:00–14:00 | Обед с командой | Социальное наблюдение |
| 14:00–14:45 | Code review | Подготовка к Тесту 4 |
| 14:45–15:15 | Дискуссия с «автором» | ★ Тест 4 — эго-устойчивость |
| 15:15–15:45 | Финал + раскрытие тестов + обратная связь | Этическое условие |
Часть 5. Результаты за 18 месяцев
- 47 кандидатов прошли день отбора
- 5 нанятых senior-разработчиков (отбор 10,6%)
- 5 из 5 работают до сих пор
- Время выхода на полную продуктивность: сократилось с 4 до 2 месяцев
- Запросы «помоги разобраться» от подчинённых к нашим senior: выросли в 2 раза (хороший знак — старшие стали доступнее)
- Отток senior: 0% за 18 месяцев (vs. 12% в среднем по индустрии)
- Качество code review: по внутреннему опросу разработчиков — 4,6 из 5 (раньше — 3,4)
Стоимость: 1 рабочий день CTO + 1 день младшего разработчика + 1 день подсадного автора = ~70 тыс. рублей на кандидата. За 18 месяцев — ~3,3 млн. Окупилось — на одних только зарплатах за 4 месяца неподходящих senior, которых не взяли.
Часть 6. Эпилог. Главное
Современное техническое интервью — это leetcode-задачи в одиночку. А реальная работа senior — это работа с командой и чужим кодом. Это разные навыки, и они слабо коррелируют. Поэтому многие компании годами нанимают «не тех» senior.
Андрей Михайлович не «научился отбирать разработчиков интуитивно». Он построил систему, в которой кандидат проявляет реальные senior-навыки: чтение кода, признание незнания, наставничество, эго-устойчивость. И в результате нанимает только тех, у кого они есть.
Главное: не отбирайте senior через одиночные leetcode-задачи. Senior — это не «лучший решатель задач». Senior — это «лучший работник в команде». Тестируйте парное программирование, чтение чужого кода, реакцию на «я не знаю» и эго-устойчивость в code review. Иначе вы будете годами нанимать middle с громкой самооценкой.
А теперь — практика
Если у вас IT-компания и проблема с отбором senior — напишите в комментариях:
- Размер команды, стек, продукт
- Какие проблемы с нанятыми senior (не читают код? защищают решения? не наставничают?)
- Что уже пробовали (leetcode? system design? домашка?)
Я и коллеги сконструируем для вас 2–3 персональных скрытых теста под вашу специфику. Бесплатно.
Серия «Система отбора персонала»
Это четвёртый кейс. Также: главная (теоретическая) статья, №1 — менеджер по продажам, №2 — бухгалтер, №3 — тимлид.
Следующие: секретарь/ассистент, маркетолог, руководитель отдела.
Для тихого знакомства — попробуйте Фреди, бесплатного виртуального психолога 24/7.
Открыть Фреди →Источники и научная база
- Fowler M. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
- Schmidt F.L., Hunter J.E. The Validity and Utility of Selection Methods in Personnel Psychology. Psychological Bulletin, 1998.
- Leary M.R., Diebels K.J., Davisson E.K., Jongman-Sereno K.P., Isherwood J.C., Raimi K.T., Deffler S.A., Hoyle R.H. Cognitive and interpersonal features of intellectual humility. Personality and Social Psychology Bulletin, 2017, 43(6): 793–813.
- Williams L., Kessler R. Pair Programming Illuminated. Addison-Wesley, 2003.
- Bacchelli A., Bird C. Expectations, outcomes, and challenges of modern code review. Proc. of 35th International Conference on Software Engineering (ICSE), 2013.
- Xia X., Bao L., Lo D., Xing Z., Hassan A.E., Li S. Measuring program comprehension: A large-scale field study with professionals. IEEE Transactions on Software Engineering, 2017.
- Ericsson K.A., Krampe R.T., Tesch-Römer C. The role of deliberate practice in the acquisition of expert performance. Psychological Review, 1993, 100(3): 363–406.
- Brooks F.P. The Mythical Man-Month. Addison-Wesley, 1975.
- Goffman E. The Presentation of Self in Everyday Life. Anchor Books, 1959.
- Kahneman D., Sibony O., Sunstein C.R. Noise: A Flaw in Human Judgment. Little, Brown Spark, 2021.