За последних два года я провёл больше 80 собеседований на позиции разработчиков в нашу студию. Научился видеть определённые паттерны, которые предсказывают проблемы точнее, чем тестовое задание.
Я не технарь. Точнее — я понимаю разработку, но не пишу код каждый день. Именно поэтому мои сигналы — поведенческие, а не технические. И именно это может быть полезно тем из вас, кто нанимает первых разработчиков без технического бэкграунда.
Флаг #1: «Это зависит» без объяснения
Хороший признак опытного разработчика — умение говорить «это зависит от контекста». Это правда: большинство архитектурных решений не имеют одного правильного ответа.
Но есть кандидаты, которые говорят «это зависит» и... останавливаются.
Как это звучит: — Какую базу данных выбрать для стартапа? — Ну, это зависит... — От чего? — Ну, от нагрузки, от требований, от команды... — И что вы выбрали бы для типичного B2B SaaS? — Сложно сказать без деталей.
Что это значит: человек либо не имеет реального опыта принятия решений, либо боится ошибиться и занимает максимально безопасную позицию.
Правильный ответ звучит так: «Это зависит от Х и Y. Для большинства стартапов я бы выбрал PostgreSQL — потому что Z. Но если есть требование W, рассмотрел бы MongoDB».
Умение принимать конкретные решения и объяснять их — ключевой навык, который я ищу.
Флаг #2: Портфолио из CRUD-приложений без контекста
У меня на столе лежат десятки GitHub-репозиториев с «TODO-list», «Blog API», «E-commerce». Технически грамотные. Но они ни о чём не говорят.
Вопрос, который я задаю: «Расскажите про проект, которым вы гордитесь. Что там было сложного?»
Красный флаг: кандидат начинает описывать функционал («там был CRUD, авторизация, загрузка файлов»), но не может назвать ни одного нетривиального решения или проблемы, с которой столкнулся.
Хороший ответ: «Делал интеграцию с платёжной системой. Столкнулся с тем, что вебхуки иногда приходят дважды, и нам нужна была идемпотентность. Решил это через...»
Проблемы, которые человек решал и помнит — это его реальный опыт. Отсутствие таких историй — признак того, что либо опыта мало, либо человек работал по шаблону без погружения.
Флаг #3: «Я не занимаюсь DevOps» или «это не моя зона»
Это не про то, что разработчик должен быть DevOps-инженером. Это про отношение к части работы, которая «не моя».
Для стартапа, особенно в первой версии продукта, крайне важны люди с широким взглядом. Разработчик, который не может задеплоить своё приложение, поднять контейнер или разобраться с простым nginx-конфигом — это лишняя зависимость.
Как проверяю: «Опишите, как вы деплоите свои проекты».
Если ответ: «Я передаю коллеге/девопсу/системному администратору» — это флаг.
Если ответ: «Я использую Railway/Render/Vercel» — это нормально для джуна.
Если ответ: «Я сам настраиваю GitHub Actions, деплою на VPS через Docker» — отлично.
Важно понимать полный путь кода от git push до работающего в продакшне.
Флаг #4: Негативные истории о предыдущих командах без рефлексии
Этот флаг работает не против людей, которые критикуют предыдущие команды. Критика — это нормально, если из неё есть выводы.
Красный флаг — это когда человек рассказывает, как всё было плохо, и единственный вывод — «я ушёл».
Как звучит: — Почему ушли с последнего места? — Там был хаос, никто не знал что делает, менеджер был некомпетентен, требования менялись каждый день. — Что вы пробовали изменить? — Ну, говорил, что так нельзя работать... — Что конкретно? — Ну, я несколько раз поднимал этот вопрос...
Хороший ответ: «Там были проблемы с процессами. Я предложил ввести еженедельные синки, написал регламент на wiki, но в итоге культура компании не менялась. Понял, что мне важно работать в команде с определёнными стандартами и ушёл целенаправленно».
Разница — в agency. Хороший кандидат пробовал что-то сделать и принял осознанное решение. Плохой — просто «ушёл от».
Флаг #5: Не задаёт вопросы о продукте и бизнесе
Это самый тонкий флаг, но для меня самый важный.
После технической части я всегда говорю: «Расскажите, что вы хотите узнать о нас и проекте».
Красный флаг: вопросы только про технологии и зарплату. «Какой стек?», «Будет ли удалёнка?», «Как ревью проходит?» — это окей, но недостаточно.
Хороший признак: «А какую проблему решает этот продукт для пользователей? Вы уже валидировали спрос?», «Есть ли конкуренты, как вы от них отстраиваетесь?», «Какой план на следующие 6 месяцев?»
Разработчик, которому интересен бизнес — не просто исполнитель. Такой человек будет задавать правильные вопросы во время разработки, предлагать альтернативы, думать о продукте. Это критически важно для стартапа, где каждый человек влияет на результат.
Бонус: как проверить компетенции без технического бэкграунда
Три приёма, которые работают для нетехнических интервьюеров:
1. Попросите объяснить сложное просто
«Объясните, что такое API, как будто я не знаю, что это». Умение объяснять — признак понимания. Если человек тонет в терминах — он либо не понимает сам, либо не умеет работать с нетехническими стейкхолдерами.
2. Задайте вопрос о провале
«Расскажите про самый серьёзный баг, который вы допустили». Нет провалов = нет опыта или нет честности. Реакция на ошибки важнее самих ошибок.
3. Проверьте реакцию на неопределённость
«У нас есть задача, но требования пока нечёткие. Как вы работаете в таких условиях?» Разработчик, который паникует от неопределённости — проблема для стартапа. Тот, кто умеет работать итерационно — ценность.
В нашей студии мы используем эти же критерии при формировании пула разработчиков. Нам важны люди, которые не просто пишут код, но понимают продукт и бизнес. Это напрямую влияет на качество того, что мы создаём для клиентов.
Если вам нужна помощь в техническом скрининге кандидатов — можем помочь. Пишите в @hexbit_requests_bot.
Следующая статья: кейс о BI-дашборде для интернет-магазина. Как владелец бизнеса перестал принимать решения вслепую.