Red Flags в найме глазами лида

Когда начинаешь слышать людей, а не слова

Несколько сотен собеседований за карьеру. Начинал как все — с паттернов проектирования и SQL-джоинов. Был уверен: найди технически сильного человека, остальное приложится.

Переломный момент — проект по построению event-driven платформы. Нанял разработчика, который на техническом интервью разложил архитектуру микросервисов так, что хотелось аплодировать стоя. Глубокие знания Kafka, Flink, понимание распределённых систем на уровне, который редко встречаешь. Оффер сделали в тот же день.

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

С тех пор я слушаю не ответы, а паттерны. Не что говорит кандидат, а как.

Важная оговорка: red flag — не приговор. Это сигнал о возможном несовпадении ценностей. Один и тот же человек может быть токсичным в одной команде и звездой в другой. Но если ты строишь конкретную культуру — нужно уметь распознавать то, что в неё не впишется.

Архетип 1: Раненый герой

Узнаёшь по тому, как много он рассказывает о предыдущем месте — и как мало хорошего в этих рассказах. Прошлый руководитель был некомпетентен, команда не понимала его идей, компания не ценила вклад.

Проблема не в негативном опыте — такое бывает. Проблема в позиции. Раненый герой не рефлексирует: он обвиняет. Спрашиваешь «а что бы ты сделал иначе?» — ответ сводится к «ну, если бы меня слушали…».

Почему это опасно для команды. Раненый герой приносит обиду с собой. Любой конфликт интерпретирует через призму прошлого. Руководитель принял решение без совещания — значит, опять не ценят. Коллега не согласился с подходом — значит, опять не слушают. Ты получаешь сотрудника, который воюет не с текущими проблемами, а с призраками предыдущей работы.

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

Архетип 2: Одинокий кодер

«Мне бы просто писать код. Созвоны, ретро, планирования — это всё мешает работать.» Звучит как здоровый прагматизм. На практике — бомба замедленного действия.

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

У меня был такой. Сильный, быстрый, решал задачи в два раза быстрее остальных. За три месяца написал сервис, который никто в команде не мог поддерживать. Документации ноль. Тесты — «это очевидный код, зачем тесты». Когда он ушёл в отпуск, а в его сервисе нашли баг — команда потратила неделю на то, чтобы разобраться в коде, который один человек написал за день. Экономика отрицательная.

Как распознать. Спроси про code review. Если человек воспринимает ревью как формальность или, хуже, как нападение на компетенцию — сигнал. Хороший командный игрок видит в ревью инструмент, а не оценку.

Архетип 3: Гибкий в этике

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

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

Был случай. Разработчик из смежной команды подписал акт о проведении нагрузочного тестирования. Тестирование провели — на десяти процентах целевой нагрузки. В акте — «тестирование пройдено успешно». Формально — правда. По сути — ложь. На проде система легла в первый час. Разбор полётов длился дольше, чем само падение.

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

Архетип 4: Расфокусированная звезда

Знает React, Vue, Angular, Svelte. Пробовал Rust, Go, Elixir. Pet-проект на Haskell. На прошлой работе внедрял Kubernetes, до этого — CI/CD, ещё раньше — базы данных. Резюме впечатляет. Глубина — нет.

Расфокусированная звезда коллекционирует технологии. Каждые полгода — новый стек. Ни в одной теме нет глубины, достаточной для production-решений.

Почему это опасно. Enterprise требует глубины, не ширины. Когда Tarantool деградирует под нагрузкой — нужен человек, который знает внутренности, а не тот, кто «трогал на хакатоне». Когда Flink-джоба не укладывается в SLA — нужен эксперт, а не энтузиаст.

Был конкретный случай. Кандидат на позицию senior-разработчика, в резюме — внушительный список: Kubernetes, Terraform, Ansible, три облака, два языка. На вопрос «расскажи про самый сложный деплой» ответил историей, как настраивал Helm-чарт для простого CRUD-сервиса. Ок, копаю дальше: «Какие проблемы были с liveness/readiness пробами?» — «Ну, стандартные настроили, вроде работало.» «А если под не поднимается после деплоя — как дебажишь?» — долгая пауза и переход на рассказ о том, как он параллельно изучает Rust. Человек собрал впечатляющую коллекцию инструментов и ни одним не владел на уровне, нужном для решения реальных проблем в продакшене. Через полгода он снова сменит стек и напишет в резюме ещё одну строчку.

Как распознать. Возьми любую технологию из резюме, копни на два уровня. Не «что такое Kafka», а «как работает rebalancing консьюмер-группы и когда это становится проблемой». Расфокусированная звезда плывёт после первого уточняющего вопроса.

Архетип 5: Фантом результатов

Самый опасный, потому что самый скрытный. Мастер презентации. Красиво рассказывает о масштабных проектах, правильные buzzwords, нарратив о личном спасении ситуации.

Начинаешь задавать конкретику — «какой SLA?», «сколько событий в секунду?», «какие альтернативы рассматривали?» — ответы тают. «Ну, большой проект…», «Точные цифры не помню…», «Я отвечал за общее направление…».

Однажды собеседовал кандидата на сеньорную позицию. Резюме — космос: распределённые системы, высоконагруженные сервисы, архитектурные решения. Двадцать минут — блестящий рассказ. Потом я спросил: «Ты упомянул, что оптимизировал запросы к базе данных. Расскажи про самый сложный случай — какой был план запроса до и после?» Пауза. «Ну, мы использовали индексы…» — «Какие именно?» — «B-tree…» — «А почему не partial index? Данные ведь были с фильтрацией по статусу, как ты описывал.» Ещё одна пауза. Стало ясно: человек руководил проектом, где всё это происходило. Но не он это делал.

Как распознать. Метод STAR — Situation, Task, Action, Result. Проси конкретику: цифры, метрики, хронологию. Настоящий эксперт помнит детали проектов, в которых жил. Фантом — нет, потому что участвовал на другом уровне.

Архетип 6: Профессиональный собеседуемый

Отдельный вид, который я выделил недавно. Человек, который проходит собеседования как спорт. Идеальные ответы. Правильная структура STAR на каждый вопрос. Заготовленные истории под каждый тип вопроса.

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

Я однажды собеседовал кандидата, который отвечал настолько гладко, что мне стало не по себе. Каждый ответ — как из учебника. Идеальная структура, правильные паузы, даже самоирония была заготовлена и отрепетирована. Я спросил: «Расскажи про ситуацию, когда ты облажался на проекте и не смог это исправить.» Он начал рассказывать историю — но в ней «облажался» плавно перетёк в «принял непопулярное решение, которое в итоге оказалось правильным». Я переспросил: «Нет, именно облажался. Без хеппи-энда.» Секунд пятнадцать тишины. Потом — «Ну, наверное, когда-то был такой случай, но я не помню деталей.» Человек, который не помнит свои провалы — либо ни разу не ошибался (невозможно), либо настолько отрепетировал самопрезентацию, что реальный опыт спрятался за фасадом.

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

Архетип 7: Внешний локус

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

«Менеджер не объяснил задачу». «Процессы у вас плохо выстроены». «Я бы сделал, но у нас так не принято». «До меня там уже всё сломали». Звучит как конструктивная критика. Но паттерн один: собственная зона управления отсутствует. Не потому что человек ленив — просто его внутренняя модель такова, что события происходят с ним, а не по его воле.

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

Почему это проблема. В банковской разработке, где инцидент требует root cause analysis и конкретного ответственного, такой человек парализует разбор. Не злонамеренно — он искренне описывает события как они «случились». Проблема в том, что команда не может учиться и меняться на основе анализа, в котором нет субъекта.

Как распознать. Попроси рассказать про провальный проект. Слушай, кто субъект предложений. «Мы не успели» — нормально. «Нас не предупредили, сроки поставили нереальные, архитектура была изначально неправильная» — каждое предложение без «я» и без действия. Один раз — ситуация. Три раза подряд — паттерн.

Рефлексивный подход

Я не использую архетипы как чёрный список. Это инструмент рефлексии — для себя. За годы найма я понял: идеальных собеседований не бывает, как не бывает идеальных кандидатов. Каждое интервью — это два человека, которые пытаются за час понять, смогут ли они вместе строить что-то сложное.

Каждый раз, когда вижу red flag, задаю три вопроса:

1. Паттерн или момент? Человек нервничает на интервью — нормально.
2. Несовместимо или непривычно? Разнообразие подходов — сила.
3. Могу ли работать с этим? Некоторые паттерны корректируются менторством. Другие — фундаментальны.

Я ищу не идеальных специалистов. Ищу людей, которые готовы быть совладельцами результата. Которые воспринимают команду как инструмент общей цели, а не среду обитания. Которые умеют рефлексировать.

Способность работать в команде, брать ответственность и честно говорить о проблемах — это либо есть, либо нет. Технологии можно выучить. Характер — нет.

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

Впрочем, я тоже проходил собеседования, где был раненым героем. Просто не замечал.

Если тема найма и управления командами тебе близка — я провожу менторинг для начинающих тех-лидов, где разбираем в том числе найм, удержание и построение культуры. А если ты из тех, кто хочет строить команды на принципах совладения — посмотри, как устроена Digital Artel.

---

Оригинал статьи: Red Flags в найме глазами лида на Habr

Ваш ДПУПП