Alex.Popov
Member
Я возглавлял разработку в стартапе и за пять лет нанял около тридцати разработчиков. Из них не менее двадцати пришлось отправить в отставку или уволить. Каждая ошибка стоила не только денег, но и времени команды, мотивации и репутации продукта. Сегодня хочу поделиться семью типичными ошибками, которые я совершал и которые, уверен, совершает каждый, кто нанимает разработчиков впервые или вторично.
Нажать чтобы Перейти на сайт
Первая ошибка — верить собеседованию. Мне казалось, что если человек уверенно отвечает на вопросы, значит, он справится с реальными задачами. Однажды я нанял очень уверенного специалиста, который блестяще объяснял архитектуру микросервисов. Через два месяца выяснилось, что он не может разобраться в существующем коде проекта и блокирует весь спринт. Вторая и третья ошибки связаны с процессом найма: я торопился и брал первого кандидата, который выглядел достаточно хорошо, вместо того чтобы подождать правильного человека. Также недостаточно проверял рекомендации — верил тому, что написано в резюме. Однажды кандидат указал три года опыта с конкретным фреймворком, а на практике оказалось, что он использовал его один месяц в учебном проекте.
Четвёртая ошибка — нанимать в одиночку. Я сам проводил все собеседования и сам принимал решение. Из-за этого пропускал слабые стороны кандидатов, которые другие интервьюеры могли бы заметить. Потом начал приглашать на собеседования технических наставников и тимлидов, и质量 найма заметно выросло.
Пятая ошибка — не задавать правильные условия на испытательном сроке. Раньше я просто давал задачу и ждал результата. Но без чёткого критерия успеха невозможно объективно оценить, подходит ли человек команде. Теперь я формулирую три конкретные задачи с понятными метриками и обсуждаю их с кандидатом до первого дня работы.
Узнать подробнее →
Шестая и седьмая ошибки — игнорировать культурное соответствие и не инвестировать в онбординг. Технические навыки можно подтянуть, но если человек не встраивается в команду, конфликтует с коллегами или не понимает ценности продукта, это разрушает атмосферу. А плохой онбординг превращает отличного разработчика в разгневанный продукт через месяц.
А теперь вопрос к вам: какую ошибку при найме разработчиков вы совершили и что сделали, чтобы она не повторилась?
По теме советую почитать: Автоматизация бизнес-процессов: с чего начать без хаоса
Нажать чтобы Перейти на сайтПервая ошибка — верить собеседованию. Мне казалось, что если человек уверенно отвечает на вопросы, значит, он справится с реальными задачами. Однажды я нанял очень уверенного специалиста, который блестяще объяснял архитектуру микросервисов. Через два месяца выяснилось, что он не может разобраться в существующем коде проекта и блокирует весь спринт. Вторая и третья ошибки связаны с процессом найма: я торопился и брал первого кандидата, который выглядел достаточно хорошо, вместо того чтобы подождать правильного человека. Также недостаточно проверял рекомендации — верил тому, что написано в резюме. Однажды кандидат указал три года опыта с конкретным фреймворком, а на практике оказалось, что он использовал его один месяц в учебном проекте.
Четвёртая ошибка — нанимать в одиночку. Я сам проводил все собеседования и сам принимал решение. Из-за этого пропускал слабые стороны кандидатов, которые другие интервьюеры могли бы заметить. Потом начал приглашать на собеседования технических наставников и тимлидов, и质量 найма заметно выросло.
Пятая ошибка — не задавать правильные условия на испытательном сроке. Раньше я просто давал задачу и ждал результата. Но без чёткого критерия успеха невозможно объективно оценить, подходит ли человек команде. Теперь я формулирую три конкретные задачи с понятными метриками и обсуждаю их с кандидатом до первого дня работы.
Узнать подробнее →Шестая и седьмая ошибки — игнорировать культурное соответствие и не инвестировать в онбординг. Технические навыки можно подтянуть, но если человек не встраивается в команду, конфликтует с коллегами или не понимает ценности продукта, это разрушает атмосферу. А плохой онбординг превращает отличного разработчика в разгневанный продукт через месяц.
А теперь вопрос к вам: какую ошибку при найме разработчиков вы совершили и что сделали, чтобы она не повторилась?
По теме советую почитать: Автоматизация бизнес-процессов: с чего начать без хаоса
Честно говоря, правильный подбор команды с пониманием безопасности – это лучшая инвестиция в проект. У нас был шикарный кейс, когда мы наняли разработчиков, которые сразу закладывали защиту на этапе архитектуры. Это дало невероятный прирост качества и уверенности в продукте! Все процессы стали прозрачными и эффективными. Очень рекомендую всем коллегам инвестировать в экспертизу и искать тех, кто горит делом – это окупается сторицей!