AlexMorozov
New member
За годы найма я провёл, наверное, не одну сотню собеседований и давно перестал удивляться разнице в ценах на рынке. Два разработчика с одинаковым стажем в резюме, похожими стеками и одинаковым набором модных слов могут отличаться по стоимости в два, а то и в три раза. И это не всегда про несправедливость рынка. Обычно за высокой ставкой стоит не количество лет, а характер задач, которые человек способен закрыть без постоянной подстраховки. Поэтому вопрос не в том, почему Senior дороже, а в том, умеем ли мы вообще разглядеть эту разницу до того, как подписан оффер.
Мой первый опыт найма был болезненным. Я смотрел на красивое резюме, на список технологий, на громкие названия компаний и делал вывод по косвенным признакам. В итоге получил ситуацию, когда человек блестяще рассказывал про паттерны, но при первом же инциденте на проде растерялся и неделю ждал, пока кто-то скажет, что делать. Именно тогда я понял: оценка разработчика — это не проверка памяти, а проверка мышления в условиях неопределённости. И делать её нужно задолго до финальной встречи, а не в последний вечер перед оффером.
Теперь я всегда начинаю с контекста задач, а не с технологий. Мне важно понять, что именно этот человек должен приносить команде: закрывать подзадачи по чёткому ТЗ или самому формулировать, что вообще нужно сделать. Если работе нужен исполнитель, то отсутствие инициативы — не минус, а нормально вписывающаяся черта. Если же нужен тот, кто будет отвечать за направление, то я сознательно ищу неудобного кандидата, который задаёт неудобные вопросы на встрече. Такие вопросы, кстати, лучший бесплатный маркер зрелости, какой я знаю.
На технической части я давно отошёл от задач на заучивание алгоритмов для всех подряд. Вместо этого даю небольшой кусок реального кода с реальной проблемой и прошу объяснить, что здесь не так и как бы он это переписал. Меня интересует не правильный ответ, а ход мысли: замечает ли он границы ответственности модулей, думает ли о тестируемости, спрашивает ли про нагрузку и откаты. Senior отличается тем, что его решения не разваливаются через полгода, и это видно уже на маленьком примере, если внимательно слушать.
Отдельный пласт, который почти никогда не проверяют в резюме, — это работа с людьми и с рисками. Я специально спрашиваю про самый провальный проект в его жизни и смотрю, как человек формулирует причины провала. Зрелый специалист говорит про свои решения и про то, как он увидел проблему поздно, а не про то, что продукт-менеджер был плохой, а легаси виновато. То же самое с оценками сроков: умение честно сказать, что задача может затянуться, и предложить план с промежуточными точками ценится дороже, чем бесконечный энтузиазм.
Отдельно скажу про деньги, потому что здесь ломается больше всего сделок. Я стараюсь не спрашивать абстрактное ожидание по зарплате, а привязывать разговор к диапазону и к тому, что за него человек будет делать в первые три месяца. Если кандидат просит верхнюю границу, я честно говорю, какие задачи эту границу оправдывают, и прошу показать, что он действительно к ним готов. Такой разговор снимает половину напряжения: обе стороны понимают, за что именно платят, а не просто торгуются за цифру.
Итог моего опыта простой. Senior дороже не потому, что он знает больше команд или библиотек, а потому что он снимает с команды часть неопределённости и делает это молча, без напоминаний. Оценивать это надо до оффера, на живых задачах и разговорах о провалах, а не по строчкам в резюме. Если научиться смотреть именно на это, найм становится спокойнее, а ставки перестают казаться необоснованными. А теперь вопрос к вам, форумчане: какая задача или вопрос на собеседовании лучше всего помогли вам разглядеть сильного разработчика, и чем этот случай вам запомнился?
Мой первый опыт найма был болезненным. Я смотрел на красивое резюме, на список технологий, на громкие названия компаний и делал вывод по косвенным признакам. В итоге получил ситуацию, когда человек блестяще рассказывал про паттерны, но при первом же инциденте на проде растерялся и неделю ждал, пока кто-то скажет, что делать. Именно тогда я понял: оценка разработчика — это не проверка памяти, а проверка мышления в условиях неопределённости. И делать её нужно задолго до финальной встречи, а не в последний вечер перед оффером.
Теперь я всегда начинаю с контекста задач, а не с технологий. Мне важно понять, что именно этот человек должен приносить команде: закрывать подзадачи по чёткому ТЗ или самому формулировать, что вообще нужно сделать. Если работе нужен исполнитель, то отсутствие инициативы — не минус, а нормально вписывающаяся черта. Если же нужен тот, кто будет отвечать за направление, то я сознательно ищу неудобного кандидата, который задаёт неудобные вопросы на встрече. Такие вопросы, кстати, лучший бесплатный маркер зрелости, какой я знаю.
На технической части я давно отошёл от задач на заучивание алгоритмов для всех подряд. Вместо этого даю небольшой кусок реального кода с реальной проблемой и прошу объяснить, что здесь не так и как бы он это переписал. Меня интересует не правильный ответ, а ход мысли: замечает ли он границы ответственности модулей, думает ли о тестируемости, спрашивает ли про нагрузку и откаты. Senior отличается тем, что его решения не разваливаются через полгода, и это видно уже на маленьком примере, если внимательно слушать.
Отдельный пласт, который почти никогда не проверяют в резюме, — это работа с людьми и с рисками. Я специально спрашиваю про самый провальный проект в его жизни и смотрю, как человек формулирует причины провала. Зрелый специалист говорит про свои решения и про то, как он увидел проблему поздно, а не про то, что продукт-менеджер был плохой, а легаси виновато. То же самое с оценками сроков: умение честно сказать, что задача может затянуться, и предложить план с промежуточными точками ценится дороже, чем бесконечный энтузиазм.
Отдельно скажу про деньги, потому что здесь ломается больше всего сделок. Я стараюсь не спрашивать абстрактное ожидание по зарплате, а привязывать разговор к диапазону и к тому, что за него человек будет делать в первые три месяца. Если кандидат просит верхнюю границу, я честно говорю, какие задачи эту границу оправдывают, и прошу показать, что он действительно к ним готов. Такой разговор снимает половину напряжения: обе стороны понимают, за что именно платят, а не просто торгуются за цифру.
Итог моего опыта простой. Senior дороже не потому, что он знает больше команд или библиотек, а потому что он снимает с команды часть неопределённости и делает это молча, без напоминаний. Оценивать это надо до оффера, на живых задачах и разговорах о провалах, а не по строчкам в резюме. Если научиться смотреть именно на это, найм становится спокойнее, а ставки перестают казаться необоснованными. А теперь вопрос к вам, форумчане: какая задача или вопрос на собеседовании лучше всего помогли вам разглядеть сильного разработчика, и чем этот случай вам запомнился?