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

IT-рынок переживает кадровый перегрев как со стороны работодателей-компаний, так и соискателей-разработчиков. Найти эффективного сотрудника – сложно. Важно не ошибиться при найме работника и не держать в команде некомпетентного специалиста. Алексей Лихацкий, CEO IT-компании AppEvent, собрал 11 красных флагов, которые помогут не допустить обеих ситуаций в вашем отделе разработки.

Красный флаг или Red flag – тот самый тревожный звоночек. Сигнал, считав который можно понять, что с человеком вам не по пути.

Я не просто владельцем компании, но и IT-специалист с десятилетним опытом работы. Поэтому сам провожу собеседования в отдел разработки и помогаю команде решать крупные задачи. Признаки, приведенные в статье, – мой опыт, наработанный в найме, стартапах и собственном бизнесе. Это не правила, а личные наблюдения. Они не универсальны, но могут послужить кейсом для IT-нанимателя.

1. Высокие зарплатные требования при отсутствии опыта и кейсов. В онлайн-школах есть отдельный HR-блок. Ученикам рассказывают, как «продать» себя нанимателю, и обещают высокую заработную плату. Однако в большинстве компаний джуны начинают далеко не с такой суммы. Возникает непонимание между кандидатом, не желающим соглашаться на меньшее, и работодателем, не готовым платить больше сотруднику без опыта. Такие зарплатные требования могут указывать на отсутствие критического мышления и трезвого суждения собственных навыков. Если в кандидате вы все же видите потенциал, попробуйте убедить его статистикой и реальными цифрами рынка.
2. Частые смены рабочих мест. Резюме «Пять мест работы по два месяца на каждом» – повод насторожиться. Возможны два варианта: либо кандидату не подходили компании, либо он не устраивал их. Иметь одну-две такие строки в резюме – допустимо. Возможно, кандидату не подошла политика компании или руководство не сошлось с сотрудником в необходимых навыках. Однако если весь опыт кандидата состоит из таких кейсов, стоит узнать подробности. Открыто обсудите это на собеседовании или свяжитесь с предыдущим работодателем.
3. Отсутствие логики. На собеседованиях я даю простое тестовое на построение алгоритмов. Такое задание – лучший способ проверить логику кадра. Человек без хорошей логики не может соединить несколько компонентов в код или грамотно составить структуру алгоритма. Дальше с кандидатом работать будет сложно, так как логика – важнейший навык для IT-специалиста.

1. Нежелание учиться и развиваться. Полностью изучить язык программирования – невозможно. Разработчику нужна насмотренность: кейсы внедрения, методологии, библиотеки. Хороший разработчик не стакается с одной и той же проблемой дважды. Чем опытнее разработчик, тем легче ему спускаться на низкоуровневые особенности кода, выдвигать гипотезы для решения проблем. Чтобы набраться опыта и повысить грейд, нужно желание. Если сотрудник не готов развиваться и прокачивать себя, он становится неэффективным членом команды и застревает на одном уровне. Допускает одинаковые ошибки и вредит продукту.
2. Пренебрежение методологиями разработки. Если сотрудник не верит в методологию компании и не готов следовать ей, работать с ним будет сложно. Противостояние общим принципам бизнеса навредит команде, продукту и самому специалисту. Методология, примененная частично, так же и работает. Оставим демо-встречи, но уберем ежедневные митинги – получим Waterfall. Задумайтесь, есть ли у вас время на споры с неверящим сотрудником?
3. Сложность поддержки и модификации кода членами команды. Красивый код – понятен и логичен. В него легче внести изменения без багов. IDE вводили ограничение по ширине кода – 80 символов. При большем количестве знаков пользователям приходилось скролить, что влияло на понимание кода. Если сложный код пишет разработчик без опыта, ситуацию можно исправить. Однако если так пишет middle, переучивать его придется долго.
4. Сорванные дедлайны. Постоянное неуважение дедлайнов замедляет развитие компании. Особенно последствия видны, когда задачи выполняются по цепочке. Мы на деле убедились, как важна пунктуация разработчика. В этом году Google выдвинул новые требования для сохранения интеграции с их проектами через API. Нужно было как можно скорее провести ревью нашего кода. Сотрудники успели вовремя. Но если бы кто-то из них сорвал дедлайн, мы потеряли бы сотни клиентов.
5. Игнорирование фидбэка со стороны юзеров. Только юзеры могут сделать систему удобной и максимально полезной.Опыт любого клиента можно обратить в пользу для компании. При создании AppEvent мы ориентировались на интерфейс Google Календарь – для наших потенциальных клиентов он был привычным. Благодаря этому первым пользователям было легче ориентироваться в системе. Если бы отдел разработки не прислушался к мнению клиентов, компания не обрела бы лояльную базу так быстро.
6. Игнорирование фидбэка со стороны наставника. Такой сотрудник не воспринимает наставника как опытного игрока. Игнорируя его советы, такой специалист растягивает время своего развития, а иногда – работу над продуктом. Если сотрудник обижается на здоровую критику и советы, задумайтесь, есть ли у компании ресурс для его развития.
7. Плохая память. Напрямую влияет на скорость и качество выполнения задач.Чтобы найти место для изменений по ТЗ и ничего не поломать, нужно помнить, как все устроено. В крупных системах с этим даже нарисованная схема не поможет. Все взаимосвязи нужно держать в голове. Если сотрудник так не умеет – багов не избежать.
8. Безучастность. Может негативно сказаться на командной деятельности рядового разработчика. Помимо этого равнодушие особенно опасный красный флаг для тимлида. Эта фигура в команде максимально вовлечена в управление и мотивацию подопечных. Пассивный подход к такой роли серьезно снижает эффективность сотрудников и влияет на сроки выполнения задач. Важно вовремя распознать качество и оценить все риски влияния пассивного тимлида на команду.

Ошибки в найме стоят компании не только денег, но и качества продукта. Собрали чек-лист, который поможет избежать некачественных специалистов в отделе. Наши простые рекомендации усилят команду и повысят мотивацию сотрудников.