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

Продолжение предыдущего поста

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

Что делать при найме
- В описании вакансии явно требуйте: дизайн-док перед реализацией, умение формулировать trade-off’ы, опыт написания ADR.
- Просите портфолио артефактов мышления: тех.дизайн-дока, пример постмортема.
- Предлагайте короткую домашку по тех.дизайну.

Например, кейсы на интервью
- Дизайн-кейс с неопределённостью: дать размытое требование и смотреть, как кандидат его уточняет. Хорошие вопросы - про SLA, объём данных, пиковую нагрузку, бюджеты, риски.
- Мини-RFC/ADR письменно: контекст, решение, альтернативы, последствия, риски, что откладываем.
- План проверки гипотез: как валидировать решение до большого релиза — фичефлаги, эксперименты, метрики, rollback.
- Ревью чужого кода/репозитория: составить план стабилизации и поэтапного улучшения с оценкой стоимости.
- Моделирование домена: выделить агрегаты, инварианты, границы контекстов, источники правды.

Что именно оценивать
- Карту ограничений: умеет ли кандидат собрать NFR (латентность, доступность, стоимость, комплаенс) и увязать их с выбором архитектуры.
- Trade-off’ы и критерии: называет альтернативы, вводит оценочные критерии, делает сопоставление, фиксирует, что потеряем.
- Простоту и эволюционность: как решение будет меняться, где точки расширения, что можно выбросить без боли.
- План рисков и валидации: какие эксплойты/сбои возможны, как обнаружим, как откатимся.
- Стоимость изменений: умеет прикидывать цену подходов и сравнивать TCO, а не только скорость первой версии.
- Коммуникацию: ясность структуры, умение принять решение и объяснить его.

Красные флаги
- Сразу прыгает в детали реализации, минуя постановку задачи.
- «Зависит» без конкретных критериев, общие слова вместо выбора.
- Игнорирует NFR, безопасность, наблюдаемость, тестируемость.
- Склонность к оверинжинирингу или наоборот к «быстро запилим и потом разберёмся».

Как с такими работать после найма
- «Сначала документ - потом код». Лёгкий шаблон дизайн-дока и ADR-лог в репозитории.
- Время на мыслительную работу: ревью документов, не ругать за отсутствие коммитов в день написания дока.
- Награда за качество: учитывать снижение дефектов, стабильность lead time, точность планирования.

Итог: чтобы нанимать тех, кто сначала думает, настройте процесс так, чтобы именно это поведение было видно, оценено и вознаграждено. Тогда «идеальные разработчики» начнут сами к вам приходить и задерживаться.

#менеджмент #эффективность #найм