Чтобы нанять хорошего инженера, недостаточно проверить только его харды. В статье я расскажу о трех софт-скиллах, которые я обязательно проверяю у каждого кандидата. Если вы начнете проверять эти три навыка, вы начнете нанимать лучших специалистов. А еще я расскажу обратную, темную сторону каждого из качеств.
Меня зовут Олег Федоткин, я программист и менеджер в ИТ. Я провел более сотни собеседований (мне HR даже толстовку «Hiring Hero» по такому случаю подарили) и нанял десятки человек: программистов, тим лидов, юнит лидов, архитекторов — да всех. После всех интервью я выделил три качества, которые неизменно определяют классного специалиста.
Кстати, если захотите почитать больше про менеджмент и карьеру в ИТ — заглядывайте в мой ТГ канал.
Качество #1: ему не пофигу на работу
Самое ценное качество в специалисте.
Это те люди, которые не закроют ноутбук, пока не пофиксят тот плавающий баг. Они будут повышать coverage тестов в чужом коде и следуют правилу «оставляй код чище, чем он был до тебя». Они сами предлагают менеджеру идеи для улучшения продукта и приносят в бэклог найденный технический долг. Успехи и провалы проекта они воспринимают как свои собственные. Скорее всего, вам придется уговаривать их прекратить овертаймить, и я советую вам быть настойчивым. Если нашли такого — удерживайте всеми силами и следите, чтобы не выгорел.
Даже если сотрудник не тащит по хардам, ничего страшного — хардам вы его научить сможете. А вот научить человека болеть душой за свое дело — нет.
Как увидеть на интервью
Спросите, какие проблемы у него были на прошлом месте и как они решились. Именно решились — если вы спросите «как ты их решал», это зафреймит вопрос не в ту сторону. Хорошим ответом будет рассказ, как кандидат самостоятельно решил проблему или эскалировал ее, если самостоятельно не получилось.
Задайте вопрос, как его фичи влияли на продукт. Если человеку не пофигу на работу, ему и на продукт не пофигу и он понимает, как именно его фичи сделали продукт лучше.
Узнайте, влиял ли кандидат на бэклог команды. Проактивные люди сами наполняют бэклог найденным техдолгом или приносят идеи продакт менеджеру. Я сам видел и руководил командами, где программисты напрямую влияют на фичи.
Обратная сторона
«Не пофигу» — не тумблер, который вы сможете выключить. Такие специалисты не смогут долго работать в компании, где их инициативы не видят, не ценят и не дают ход. Погрузите его в пучину легаси без возможности исправления — и вы его потеряете.
Если «не пофиг» у человека развито чрезмерно, он будет рьяно указывать людям на точки роста — их проекта и их личные. Некоторых будет триггерить такая назойливость. Если у вашей команды или отдела проблема, готовьтесь услышать на 1-1 критику в ваш адрес.
«Не пофигу» — самое ценное качество. Нанимайте таких людей, цените их и держитесь за них. Из них вырастут ваши будущие тимлиды, юнитлиды и — кто знает — ваша будущая замена, когда вы решите сменить работу.
Качество #2: самонаводимость
Второе качество, которое нужно смотреть. Впервые мне про него рассказал Миша Петров — СТО Рокетбанка. Когда я только начинал карьеру тимлида, я спросил у Миши, кто для него идеальный разработчик? Михаил ответил: «Идеальный разработчик — это самонаводящийся дятел, который получает задачу и летит долбить нужное дерево, пока не выдолбит». За точность цитаты не ручаюсь, но посыл такой.
По пунктам, что для меня значит самонаводимость:
Человек способен сам доуточнить задачу. Высокая самонаводимость позволяет человеку решать задачи с высокой неопределенностью. Например, если задача связана с бухгалтерией, он доуточнит у конкретного бухгалтера критерий готовности задачи. Конечно, в идеальном мире задача поставлена так, что доуточнять не придется — но где вы видели идеальный мир?
Человек сам зайдет в другие команды, если нужна их помощь. Например, дойдет до девопс или фронтов и положит задачу к ним в бэклог без помощи своего тимлида.
Когда человек «навелся», он не забьет на задачу, пока не получит результат. Например, как-то раз программист поставил задачу соседней команде и забыл про нее. В итоге, про задачу забыли вообще все, никто ее не сделал, а спустя время задача стала критическим блокером для проекта. Когда программиста спросили, почему так, он ответил, что с его стороны пули вылетели. Классика! Самонаводящийся боец продолжал бы раз в день-два спрашивать, как поживает его задача и пушил ее дальше.
Как увидеть на интервью
Спросите про задачи с самыми туманными требованиями и послушайте ответ. Не пугайтесь, если туманные требования соискателю не понравились — это не красный флаг, это нормально. Важно то, как он обработал эти туманные требования.
Узнайте, как часто ему приходилось общаться к людьми не из своего отдела. В идеале, если это были люди даже не из ИТ, как можно ближе к бизнесу. Самонаводимые люди неизбежно контактируют с бизнесом.
Задайте вопрос «расскажи мне про самую долгую задачу». Здесь важно узнать, насколько человек контролировал расплывшуюся по времени задачу и не забил ли он на нее.
Обратная сторона
Чем выше самонаводимость, тем выше соблазн забить на формулировку задачи и просто говорить человеку «сделай хорошо, чо ты». Во-первых, это может демотивировать человека. Во-вторых, результат может в корне отличаться от того, что вы изначально ожидали.
Самонаводимость — отличное качество человека, которое в разы снижает время на его менеджмент и сильно выделяет человека из рядов обычных специалистов.
Качество #3: внутренний локус контроля
В психологии есть такая абстракция как локус контроля. У человек превалирует либо внешний, либо внутренний локус. В чем разница:
Внешний локус контроля диктует человеку, что в его неудачах виноваты внешние факторы. Опоздал на работу — это проклятые пробки, ничего не могу поделать. Завалил спринт — это коллеги не вовремя завершили тестирование или развернули стенд, ничего не попишешь.
Внутренний локус контроля диктует, что во всех неудачах виноваты мы сами. Если опоздали, то надо было раньше выходить из дома. Если спринт завалили, надо было активнее пинговать тестеров или девопсов.
К сожалению, мой опыт говорит, что локус контроля очень сложно сместить во внутрь, если у человека он находится вовне. Очень сложно — не значит невозможно.
Главный плюс человека с внутренним локусом — он не просто принимает внешние факторы, он старается их менять. Такая любимая всеми «проактивность» это следствие внутреннего локуса.
А еще с такими людьми просто приятнее общаться: сами подумайте, кому нравится, когда ваш собеседник винит в своих проблемах всех, кроме себя? Я заметил: чем более явно выражен у человека внешний локус, тем токсичнее его поведение.
Как увидеть на интервью
Задать вопросы вида:
«Расскажи про свой самый большой провал. Что привело тебя к нему?» — максимально лобовой вопрос. Если виноваты вообще все, кроме самого человека это повод копнуть глубже, но делайте выводы лишь на основании одного ответа!
«Расскажи про случаи, когда не удалось выстроить отношения с другой командой или человеком». Если соискатель обвиняет лишь другую сторону, это не здорово. Часто в проваленной коммуникации виноваты обе стороны, здорово, если соискатель подсветит эти моменты.
Обратная сторона
Люди с внутренним локусом любят загоняться там, где не надо. Иногда ситуация действительно диктует условия, с которыми можно только смириться. Но внутренний локус — это не отключаемая фича и за провалы такие люди съедают себя очень сурово.
Итог
Три качества, которые я обязательно выясняю на интервью:
Насколько «не пофигу» на работу
Уровень самонаводимости
Где находится локус контроля
Попробуйте задать мои вопросы или переформулируйте их под себя — и качество вашего найма возрастет.
Больше контента про менеджмент, мотивацию и карьеру в ИТ вы найдете у меня в ТГ канале — подпишитесь, если еще не.
Tech-команда Купера (ex СберМаркет) ведет подкаст «Для tech и этих» от наших it-менеджеров. Я там тоже есть :)
Комментарии (16)
Spellinger
06.08.2024 10:16+4"Самонаводящийся боец продолжал бы раз в день-два спрашивать, как поживает его задача и пушил ее дальше. " - быть пинальщиком это не работа инженера, это всякие PM и прочие администраторы.
Положить задачу в чужой бэклог так чтобы ее взяли ,при этом забив на свои задачи чтобы ее выполнить? )) -- Ну серьезно что ли? Это решаетвся тимлидами и,чаще всего ,с привлечением вышестоящего начальства.
Мне не пофиг -но шевелить я буду своего менеджера ,а не делать его работу.
Софтскиллы нужны тем,у кого с хардскиллами плохо )
alextodef Автор
06.08.2024 10:16В общем, в этом и различие. Самонаводимый человек считает, что его работа — это доставить ценность клиенту.
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство, то это приведет к росту сроков и тонне лишней коммуникации на ровном месте.
S_gray
06.08.2024 10:16+1С таким человеком, конечно, менеджеру работать проще - чего там, чувак за свою ЗП тянет ещё немножко и менеджерскую часть работы, но в сознании исполнителей часто присутствует иерархия: "чего это мне тут кто-то кидает работу, у меня своих дел, поставленных начальством, по горло". И задача пропадает, а менеджер потом руками разводит:"А кто мне сказал?" Я вообще замечал у менеджеров такую привычку - размазать свои обязанности по подчинённым и таким образом ещё и ответственности избежать - инициатива же наказуема...
alextodef Автор
06.08.2024 10:16А вот тут мы подбираемся к вопросу о хорошем процессе поставки ценности. Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим. Можно выставить WIP-лимит или ограничить поток входящих задач, потому что незавершенная работа — это яд, который постепенно разъедает проект.
И разводить руками менеджеру тут нельзя, его прямая задача — не допустить подобных ситуаций. Хорошего руководителя отличает понимание, что процессные проблемы — это именно его проблемы, и решать их надо ему. Но не любой блокер является процессной проблемой.S_gray
06.08.2024 10:16"Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим." Странно, по собственному опыту мог бы сказать, что как правило на сотруднике висит не просто несколько, а много задач, причём часть из них напрямую связаны с его рутинными должностными обязанностями, а часть - с входящими внеплановыми задачами... То есть, может быть, идеально отлаженный рабочий процесс теоретически и можно представить, но на практике так, по-моему, не бывает. Да и нет ничего катастрофического в наличии у работников некоего пула текущих задач, главное, чтобы работник четко представлял, что он может отложить в сторону, на что переключиться, а что нельзя просто бросить посередине - а это значит, что всякого рода дедлайны должны достаточно гибкими и предполагающими разделение ответственности за них между менеджером и работником, чтобы не вводить последнего в перманентно стрессовое состояние...
michael_v89
06.08.2024 10:16А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство
То это правильно постренный процесс управления. У рядового сотрудника нет никаких полномочий ставить задачи другим отделам и контролировать их выполнение. У другого отдела есть план и свои задачи. Если есть задача для другого отдела, сотрудник обращается к тимлиду своей команды, он идет к тимлиду другой команды, тимлид другой команды на выделенном для планирования созвоне добавляет ее в план и контролирует выполнение. Тогда, если задача оказалсь просрочена, то ответственный за это тимлид/менеджер другой команды, он не выполнил свои обязанности.
Каких только причин менеджеры не придумают, лишь бы не делать свою работу.
то это приведет к росту сроков и тонне лишней коммуникации на ровном месте
У вас в примере к росту сроков привело противоположное действие. Не видите проблем в своей логике? Можно жаловаться, какие разработчики плохие, не хотят делать менеджерскую работу, а можно выстроить процессы так, чтобы этого не происходило.
alextodef Автор
06.08.2024 10:16О правильность процесса можно сломать много копий. Мой взгляд: эффективнее наладить взаимодействие между командами и отделами, чем любое взаимодействие вести через руководителя.
Если у разработчика возникла необходимость получить помощь другой команды, например, допилить API их сервиса, то он может пойти и к тимлиду другой команды, и к линейному сотруднику. Оба могут на следующем PBR'е, груминге или даже дейлике внести таску в бэклог спринта (некоторые команды закладывают время на непредвиденные задачи в спринт) или заложить капасити на следующий спринт. Мы живем в мире распределенных систем, и сервисы взаимодействуют друг с другом — поэтому взаимодействие людей неизбежно. Как бы программист не продумал API сервиса, доработки и фиксы будут.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Такой подход снижает басфактор, потому что не все упирается в тимлида. Что если тимлид заболеет? Команда будет отрезана от внешнего мира, потому что контакты не налажены.
Такой подход расширяет знание самой команды о сервисах вне ее скоупа. Это полезно и для архитектуры, и в случае инцидента.
Такой подход поможет вырастить людей, которым интересен дальнейший рост в менеджмент.
Тогда, если задача оказалсь просрочена, то ответственный за это тимлид/менеджер другой команды, он не выполнил свои обязанности.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я. Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти. Так что даже если часть моей задачи лежит в бэклоге другой команды, убедиться, что по ней есть прогресс должен тоже я. Главное, не возводить это в чайка-менеджмент и микро-контроль. Важна умеренность.
Не видите проблем в своей логике?
Искренне — нет. Не троллю :) Если более явно подсветите, будет здорово.
можно выстроить процессы так, чтобы этого не происходило.
Соглашусь, но только в определенных условиях. В реальной жизни команды меняются, компания может нанять целые отделы, которые еще не влились в выстроенные процессы. Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы. Как бы не был крут онбординг, он займет время.
Я люблю повторять, что hope — is not a strategy (спер у гугла) и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу. Тем более, если процессы хорошие, для этого достаточно просто зайти на доску команды и увидеть свою задачу в To Do и потом в In Progress. Это не займет более одной минуты. Тем более, что у любого процесса есть свои точки роста и абсолютного идеала, где все работает как часы, даже условная Toyota не достигла.michael_v89
06.08.2024 10:16+2Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Ну как это работает, если вы сами привели пример, что не работает. А всего-то надо было, чтобы тимлид сказал тимлиду, а не разработчик разработчику.
Что если тимлид заболеет?
Вы прикалываетесь что-ли?) Еще и менеджером называетесь. Если тимлид заболеет, назначается тот, кто будет выполнять его обязанности. Процесс остается тем же.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я.
При чем тут ваша задача, если разговор про задачу другому человеку из другой команды? Она связана с вашей, но это другая задача.
Хотите быть менеджером - пожалуйста, непонятно, почему вы ждете это от всех разработчиков.Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти.
Неважно, что может произойти, важно, что управление задачами команды это его прямая обязанность, и причина, по которой он получает зарплату.
убедиться, что по ней есть прогресс должен тоже я
У вас как разработчика есть свои задачи, за которые вы получаете зарплату. Если вы будете заниматься посторонними вещами, ваши задачи не будут выполнены в срок, что плохо для проекта и компании.
Если более явно подсветите, будет здорово.
Я это сделал в предыдущем комментарии. Вы предлагаете способ как избежать роста сроков, при этом сами приводите пример, как он привел к росту сроков.
Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы.
И? Я не понимаю, как это связано с моими словами. Если он не знает, к кому обращаться, пусть пойдет и спросит, хоть у того же разработчика.
и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу
Я не говорил про надежду, что за подмена понятий. Есть человек, чьей обязанностью является убеждаться и контролировать, и это тимлид или менеджер проекта. Тот, кто имеет полномочия ставить задачи разработчикам.
Это не займет более одной минуты.
И? Я не понимаю, как из этого следует, что эту минуту должен тратить не тот, в чьи обязанности это входит.
И нет, это не одна минута. Разработчик зашел, увидел, что задача еще в To Do, потратил еще 2 минуты на сообщение вида "Привет, что там с задачей?", начал делать свою задачу 10 минут, потом ему пришел ответ, он отвлекся, прочитал его, выпал из контекста, потратил еще 8 минут, что вернуться обратно в контекст. В итоге минус полчаса, 6% рабочего времени. А что в это время делает тимлид? Ничего не делает.
ILikeWorking
06.08.2024 10:16«Расскажи про свой самый большой провал. Что привело тебя к нему?» — максимально лобовой вопрос. Если виноваты вообще все, кроме самого человека это повод копнуть глубже, но делайте выводы лишь на основании одного ответа!
«Расскажи про случаи, когда не удалось выстроить отношения с другой командой или человеком». Если соискатель обвиняет лишь другую сторону, это не здорово. Часто в проваленной коммуникации виноваты обе стороны, здорово, если соискатель подсветит эти моменты.
Существует вероятность, что если в провалах обвинять только себя, то на собеседовании просто откажут такому кандидату. "Зачем он нужен, если такие ошибки делает..."
Статья мне понравилась, буду учитывать данные скиллы и вопросы на собеседованиях...P.S. "Проактивность" не нравиться ичарам. У меня уже было несколько случаев, когда я несколько дней ждал результатов по моему отклику на вакансию, потом звонил или писал в компанию ичару. В результате через несколько минут приходил отказ по вакансии.
alextodef Автор
06.08.2024 10:16На интервью кампания смотрит кандидата, а кандидат — компанию. Если так получается, что в компании не принято брать ответственность за ошибки, а к самим ошибкам относятся как к чему-то непростительному и пытаются замести под ковер, для меня это стало бы красным флагом :)
Ошибка — это шанс стать лучше. Главное, чтобы одни и те же ошибки не повторялись из раза в раз, вот это действительно печально.
maxim-kiryanov
Интересно какой в Купере burnout rate и статистика по увольнениям
alextodef Автор
За весь Купер не отвечу, у меня из ста человек в год уходило по 2-3 в среднем.
zloddey
С Качествами или без? (ирония)