В предыдущих статьях (тут, тут и тут) я довольно плотно проработал тему собеседований (по крайней мере мне хочется на это надеяться). Мы выяснили, что человека нужно спрашивать о том, что он реально делал руками. Но вот проблема – руководитель не делает ничего сам, главным инструментом руководителя для решения поставленных перед ним задач является организация его подчиненных, налаживание процессов и коммуникации. А вот как собеседовать человека, который ничего руками не делает? Об этом мы сегодня и поговорим.
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь задавать правильные вопросы будущим коллегам. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно.
Ранее мы определились, как нанимать линейных сотрудников. Если кратко – стоит проверить, что они делали руками, про что читали, про что только слышали, и про что врут что просто занесли в резюме, чтобы HR сразу не выбросил его в урну. С руководителем такое не проходит.
Наверное единственный более-менее надежный способ узнать, насколько эффективен руководитель – спросить у его коллег. Это конечно тоже опасно, потому что личная оценка эффективности работы часто отличается от объективной, но это хоть сколь-нибудь надежно. Но что делать в тех очень частых ситуациях, когда такой информации получить нельзя?
Мой подход вы уже знаете – сначала надо подумать. Над тем, что же руководитель делает в своей повседневной работе, над его рутиной. И, обобщая руководящую работу совершенно любого уровня, мы в конце концов додумаемся до следующего – руководитель вырабатывает цели и задачи в рамках своей зоны ответственности, доводит их до подчиненных, контролирует качество выполнения задач и сроки достижения целей, собирает метрики и показатели, оценивает их, на основании оценки принимает руководящие решения, и готовит отчетность для вышестоящего руководства. И вот у нас появляется целый список того, о чем можно поговорить с потенциальным коллегой.
Во-первых, следует поговорить о зоне ответственности, в которой кандидат уже работал. Что туда входило, что нет? Описать зону ответственности на той позиции, на которую его собеседуют, найти несоответствия и прояснить, готов ли кандидат взять на себя дополнительные обязательства на вашей позиции. Въедливый читатель тут же заметит – кандидат просто согласится на все обязательства, так как очень хочет попасть на позицию. Тут следует быть открытым с кандидатом и пояснить, что за невыполнение обязательств будут санкции. Мы же все хотим выполнить поставленные задачи, получить славу, почет и премию, а не сорвать сроки и с позором уволиться? Обычно люди это понимают.
Часто именно на данном этапе интервью всплывает необходимость создания команды с нуля, тут следует спросить кандидата, как он вообще планирует организовать выполнение задач и достижение целей? Какие структурные единицы он выделит в команде, как это уложится в бюджет? Нужно четко понимать, что теоретизирование бесполезно, нужно привязывать ваши вопросы к вашей же практической работе, иначе это начинает подозрительно напоминать решение алгоритмических задач на листочке.
Когда зона ответственности определена, команда либо есть, либо её примерно набросали, следует определить цели, задачи, сроки. Это очень тонкий момент, который требует большого опыта от интервьюера, и на котором можно срезать всех краснобаев, ибо определение сроков требует неслабого практического опыта руководства. Например, у вас есть один аналитик, один фронт разработчик, два бэкендера и тестировщик, какой объем задач они решат за полгода? За какой срок успеют реализовать проект? Сколько вообще кода пишет один усредненный разработчик в двухнедельный спринт? Или, если уровень руководителя выше, за какой срок при известной структуре департамента (её набросали в предыдущем абзаце) будут достигнуты поставленные цели? Очень интересные вопросы, не так ли? И, самое главное, чисто практические, их придется решать на работе.
Далее следует поговорить о вопросах распределения задач, контроля сроков и качества выполнения. Как будет действовать кандидат, когда если сроки начнут срываться и качество проседать? Как кандидат вообще поймет, что его отдел не укладывается в сроки и просел по качеству? Какие решения примет?
Ну и в конце следует спросить, как кандидат отчитывался перед руководством на предыдущем месте работы. Это наименее важная часть, так как в каждой организации отчетность своя, она часто автоматизирована, поэтому в принципе это не особо важно.
Заметьте, тут нет ничего про общение с заказчиком и с подчиненными, потому что спрашивать про подобное совершенно бесполезно. Навыки общения можно проверить только на практике.
Делимтесь своим опытом в комментариях, это всегда интересно и вызывает дискуссии, в которых рождается истина. Удачного вам найма, и
Комментарии (30)
ganqqwerty
18.06.2024 18:28+2Сколько вообще кода пишет один усредненный разработчик в двухнедельный спринт?
И впрямь
Trihlorid Автор
18.06.2024 18:28+1Что бы это значило...
ganqqwerty
18.06.2024 18:28+9Все вот эти вопросы:
Например, у вас есть один аналитик, один фронт разработчик, два бэкендера и тестировщик, какой объем задач они решат за полгода? За какой срок успеют реализовать проект? Сколько вообще кода пишет один усредненный разработчик в двухнедельный спринт? Или, если уровень руководителя выше, за какой срок при известной структуре департамента (её набросали в предыдущем абзаце) будут достигнуты поставленные цели?
... имеют какой-то смысл если это кандидат спрашивает их у интервьюера. Типа, "ну давайте прикинем, расскажите, как у вас обычно это бывает". А если интервьюер такое спрашивает у кандидата, то самый правильный ответ будет "двадцать шесть". "Что двадцать шесть"? "А что – "сколько кода" "?
Trihlorid Автор
18.06.2024 18:28Не совсем понял мысль. Вот у вас должность - тимлид, самый простой руководитель, под ним только исполнители. Вот проект, вот команда, определи сроки. Чисто рабочая задача. Или вы своему руководству так всегда и отвечаете - "двадцать шесть"?
glebiuskv
18.06.2024 18:28+1Я знаю, какой объём моя команда делает в определённые сроки. Конкретные люди с конкретными компетенциями и навыками.
А вы говорите про оценку абстрактных сотрудников. И как их оценить? Как оценить затраты времени на различные созвоны, совещания и т.д. не зная, как у интрвьюера устроены процессы?
vlaubenshtein
18.06.2024 18:28У нас в компании разработка идет по Scrum, без сроков, планы на год, конечно, есть, но они постоянно срываются. И ничего, все работают, никого не уволили. Ну сделали на месяц позже или на три - ну и что ? На то есть определенные причины.
anokru
18.06.2024 18:28Браво. "Ну сделали на 1-3 позже ну и что". Прям сквозит и отношение к своему продукту и к работе и к заказчику. Спасибо что подкрепляете мою уверенность в том как работает современный IT и во что он превратился.
vlaubenshtein
18.06.2024 18:28Заказчик внутренний. Компания очень крупная, зависимостей от смежных команд много (так как много интеграций с другими сервисами), но у этих смежных команд есть свои планы по разработке, которые точно также зависят от других смежных команд (потому что тоже много интеграций :-D). Именно поэтому обычно разработка затягивается. В условиях ограниченных ресурсов нет возможности взять и сделать, а иногда, как известно, появляются срочные задачи, которые надо делать, бросив остальные. Сейчас вы скажете, что страдает планирование - возможно, и так. Тем не менее, продукты создаются и релизятся.
Trihlorid Автор
18.06.2024 18:28без сроков, планы на год, конечно, есть
То есть сроки есть, но сроков нет. Интересно.
1CUnlimited
18.06.2024 18:28Я сделаю точно в срок только
1 доп хотелки и хорошие идеи все на потом на другой бюджет
2 на старте будут детальные ТЗ и спецификации - никаких аджайлов
3 все неопределенности в ТЗ либо реализуем по простому либо далеко потом
4 время на реализацию и тестирование будет заложено с двойным или тройным запасом в зависимости от активности ключевых заказчиков на этапе т.з.
Я думаю ключевые пользователи и спонсоры проекта при таком раскладе легко подвинут сроки
BatteringRam
18.06.2024 18:28+1Мне показалось, что в статье есть довольно общая информация, прям general. Для начала, руководителя какого уровня мы в первую очередь должны оценивать: лида отдела на проекте, лида отдела в компании, руководителя проекта и т.д.? Для каждого нужен разный подход, чтобы оценить его навыки. Как минимум степень погружения и степень необходимости делегирования.
Как лид отдела на проекте и фичеоунер я могу сказать, что мне довольно много приходится (сравнительно много) работать руками. При этом необходимо не только менеджить свой отдел, но и менеджить мини-команды в рамках разработки. И исходя из своего опыта и насмотренности я могу сказать, что для руководителей всех звеньев самыми критичными навыками являются умение делегировать, аналитическое мышление и умение признавать свои ошибки вовремя, а таковые будут, это точно. Это лишь мое субъективное мнение.
Я ни в коем случае не хочу сказать, что статья плохая. Мне было приятно с ней ознакомиться, очень хороший слог и интересные мысли. Спасибо за материал.
dancykt
18.06.2024 18:28Не понял статью. Ради статьи написано)
На собесе лидов спрашиваю что было сделано из достижений, как шел процесс, какие коммуникации и с кем были, сильные/слабые моменты, где приходилось вмешиваться и как решались проблемы с другими подразделениями. С каким багажом приходит к нам человек.
И да, я не беру лидов, без опыта работы руками. Человек должен системно расти от исполнителя до руководителя. Поэтому спрашиваю и про ручную работу.
"Сколько кода пишет программист" это абстрактно, сам раньше писал, мог за ночь накидать много рабочего кода, мог за неделю немного гавнокода накидать.
Trihlorid Автор
18.06.2024 18:28На собесе лидов спрашиваю что было сделано из достижений, как шел процесс, какие коммуникации и с кем были, сильные/слабые моменты, где приходилось вмешиваться и как решались проблемы с другими подразделениями
То есть вы просто разговариваете о вечном, а не о конкретных задачах лидов?
я не беру лидов, без опыта работы руками
Очень часто встречал такое, что в вакансии указано "тимлид", а нужен просто хороший программист, чтобы работу работать. Может у вас так?
"Сколько кода пишет программист" это абстрактно
Нет, это вполне конкретно. Вот у нас есть задача - выкопать траншею, и есть два землекопа. Сколько времени займет выполнение задачи? Можно ли это оценить? А почему с программистами иначе работает?
aka352
18.06.2024 18:28+1А траншея в чистом поле или в городе, где возможно нахождение коммуникаций, старых фундаментов, строительного мусора в конце концов? ) Если в чистом поле, то грунт песчанистый или через полметра пойдёт глина? А время года и погодные условия надо учитывать? Что-то много вопросов возникает для одной траншеи. Что-то тут не то...
wboll
18.06.2024 18:28Потому что писать код не грядки копать. Одно дело исполнять работу по одному и тому же алгоритму с поправкой на локальные случаи, а другое дело когда вся работа представляет из себя работу с локальными случаями, для решения которых нужно всякий раз думать по иному. Глупый вопрос
ABy
18.06.2024 18:28+5Как собеседовать того, кто ничего (руками) не делает
По длине ногтей!
Из The Weel of Time
Fantasi_Anna
18.06.2024 18:28+4Автор умеет писать поджигающие сообщество посты, я даже зарегалась в хабре, настолько хочется оставить комментарий.
"кандидат просто согласится на все обязательства, так как очень хочет попасть на позицию" - может конечно это мое восприятие искажено, но когда я, как руководитель, хожу на собесы, это я выбираю в какой компании мне работать и какие обязанности выполнять.
Бррр, просто жуть от всех последующих высказываний, я не дочитала до конца. Запишу себе имя автора и его компанию, чтобы обходить ее за километр.
Batalmv
18.06.2024 18:28+2По опыту, и в том числе негативному
Сначала о негативе
Была проблема с лидом, который нет был ориентирован на результат, а больше на соблюдение процессов. Это проявляется в том, что у нас срыв сроков, а лид вместо поиска вариантов решения и причин рассказывает, почему это норм. В этом случае было и по технологии норм, и код норм - но в сроки мы никак не вписывались. Сделали аудит кода с привлечением других лидов, получилось что разработчики делали работу реально медленно. Т.е. сложность и объем задачи никак "не бились" с тем, сколько на нее тратилось времени. Причем были разговоры, и на примерах конкретных тасок, и вопросы по объему unit-тестов, и по другим процедурным моментам - но на тет-а-тет встречах лид "да-да-да", а потом уже с командой - "нет-нет-нет". Ну и бесконечные торги по поводу стори поинтов и т.д. уже достали половину команды.
Также был кейс, когда лид был очень опытный и знающий, но вместо реальной работы изображал деятельность команды и прикрывал косяки. Когда баги стали открываться многократно, начали разбираться и вскрылось, что половина команды просто подгоняла код под конкретные ошибки найденные сегодня, и по фиг, что решение в целом не работает. Было ли причиной непонимание бизнес задач, либо просто "усталость" от жизни - неясно, так как после разгона половины команды с лидом, оставшая часть дописала решение, причем код был по большей части переписан, ну уже под надзором и постоянным ревью, иногда в стиле "сидим вдвоем, вот дока, вот код, сличаем и принимаем решение по пациенту".
Т.е. получается, что проблемы были не из-за того, что лиды чего-то не знали технически. С этим ни разу не было проблем, так как если не знаешь - всегда можно изучить. Проблемы были с сфот скилами, причем если первый кейс еще можно было идентифицировать, то второй - когда идет сознательный саботаж, практически нет.
Вывод такой: крайне внимательно мониторить по началу, и если что не так - тут же давать задачу "разобраться". Если раз "не то", два "не то" - смысла дальше идти с таким вожаком стаи нет.
На собесе можно отсеять тех, кто либо технологически не шарит, либо еще не набрался, как и чего говорить. Конечно бывает, что сразу ловишь понимание, что с таким человеком в одной лодке не очень хочется, но лично у меня опыта как так провести собес чтобы это почувствовать нет.
Возможно на следующий проект попробую как-то в эту сторону копнуть
Toisinajattelija
18.06.2024 18:28+1Этап 1. Проверка на вменяемость.
1.1. Проверка у нарколога.
1.2. Проверка у психиатра.
1.3. Проверка у сексопатолога.
1.4. Проверка у психолога.
Сдача всех необходимых анализов строго обязательна. Крайне желательно, чтобы решение вынес консилиум независимых врачей. Если есть проблемы или сомнения, то лучше такого типа не брать.
Keeper10
18.06.2024 18:28Предлагаю применить этот этап к российским политикам. Интересно, какой процент завалится на одной из проверок.
Blil
18.06.2024 18:28+1Интересный подход к найму. Не проще ли рассказать, как процесс ограгизован у вас и спросить про способы оптимизации? Если, вы описываете методику и вопросы, то следовало бы дать ориентиры на правильную реакцию претендента и ответы, которые вы ожидаете получить от кандидата. Лично мне, нравится задавать вопрос про проблемы с которыми сталкивался кандидат. В ответе я ожидаю услышать про реальные сложности и способы которыми их решали. Следом я задаю вопрос, про причины этих проблем и хочу получить хотя бы намёк, на команду и руководителя. И в завершение, какие выводы сделали и какие меры приняли для исключения подобных ситуаций в будущем. В моем понимании, руководитель умеет не только диаграммой Ганта пользоваться, но и имеет адекватную реакцию на непредвиденные ситации.
StanKhis
18.06.2024 18:28Во многом согласен, но сама формулировка "ничего не делает руками" сильно напрягает.
Контроль - одна из важнейших функций руководителя! Например, если в интеграционных проектах он не способен верифицировать спеку и диаграмму последовательности UML от аналитика/архитектора (нижний и средний уровень руководства) или понять отчёт QA (читать ПМИ, отчёты, это если руководитель уровнем повыше), то грошь цена такому руководителю. А это сразу говорит о неких необходимых компетенциях в части (уметь делать руками), хотя бы на верхнем или абстрактном уровне. И это легко проверить.
За одно всплывут факты по практическим кейсам, хороший руководитель не упустит возможности похвастаться своим опытом.
TimoshkinVlad
Гм. Т.е. вы ищете того, кто с нуля создаст команду, за 5 минут сформирует план проекта, оценит сроки, ресурсы?
А про усреднённый код, это классно. Скажите мне, сколько нужно ресурсов, что бы передать сломавшийся станок из производства в ремонтное подразделение? А зачем нужно передавать? А кто будет участвовать? А сколько это кода усредненого разработчика?
Я никогда не найду специалиста, который мне за 5 минут ответит на такой вопрос. Уж лучше спросите, сколько шариков от тенниса влезает в суперджет) Ну или по пмбоку прогоняйте. Про ценности можно и про то, как они становятся выгодой)
Trihlorid Автор
Не "создаст команду", а примерно прикинет, кто в этой команде должен быть. И если вы не можете определить приблизительные сроки проекта в рамках вашей зоны ответственности, то какой от такого руководителя прок? Важно щеки надувать за большие деньги?
Если вы передавали станок из производства в ремонт, то сможете сказать, сколько времени это заняло, не так ли?
OldRetailer
А какой станок? Многотонный встраиваемый или переносной фрезер?