Довольно очевидно, что junior-разработчику и тимлиду требуется сильно различающийся набор навыков. И если в случае hard skills всё уже миллион раз проанализировано и посчитано, то о необходимом наборе soft skills в зависимости от должности мы можем только понимать на уровне ощущений и здравого смысла.
Более того, в нашей индустрии не принято говорить после собеседования, что кандидату отказано из-за его уровня soft skills, хотя мы даже не пытаемся конкретизировать, что конкретно в нём нас не устраивает. Вы наверняка слышали или сами употребляли фразы вроде «просто человек странный», «почему-то не нравится» или «чувствуем, что он не вольется в команду». Но почему? Что на самом деле с ним не так?
Я решил провести собственное исследование гибких навыков и сегодня хочу поделиться результатами. Расскажу, какие навыки важны на каждом из уровней разработчика — от джуниора до руководителя. А также, как их можно проверить на собеседовании и эффективно развить внутри компании. По ссылке можно посмотреть видео моего выступления об этом на TeamLead 2021.
Исследование soft skills
Начнем с того, какие soft skills на каком уровне нужны. Еще до начала карантина при поддержке кадровой компании New.HR я запустил свой очередной опрос по soft skills. В нём я предложил собственную классификацию из 40 гибких навыков и задал вопрос: «Начиная с какого уровня данный soft skill становится критически важным?» Для каждого софт скилла нужно было выбрать, кому он нужен — от junior, middle и senior-разработчика до тимлида и руководителя. Или не требуется никому.
Благодаря распространению опроса в тимлидских чатах мне удалось собрать 467 ответов, при этом ответили всего 4% junior-разработчиков, а в основном это были senior и выше (72%). В результате сложилась картина, чего программисты ожидают на уровнях ниже, чем они сами находятся. Для простоты я решил интерпретировать полученные голоса с помощью формул, где для каждого навыка «нормализовал» между собой отданные голоса за разные уровни:
junior_importance = junior - middle - senior - teamlead - no_need;
middle_importance = junior - middle - senior - teamlead - no_need;
senior_importance = junior - middle - senior - teamlead - no_need;
teamlead_importance = junior - middle - senior - teamlead - no_need.
где:
junior — количество голосов, что данный навык нужен начиная с уровня junior;
middle — количество голосов, что данный навык нужен начиная с уровня middle;
senior — количество голосов, что данный навык нужен начиная с уровня senior;
teamlead — количество голосов, что данный навык нужен начиная с тимлида;
no_need — количество голосов, что данный навык не нужен ни на одном этапе развития разработчика.
Каждая формула применяется для голосов за каждый из гибких навыков и представляет собой отдельный график.
Нагляднее можете увидеть в таблице ниже. По сути для расчета важности навыка для какого-то уровня мы берем все голоса для данного уровня и уровней ниже «с плюсом», а для уровней выше — «с минусом». Уровень «навык не нужен» считаем максимальным.
Например, если мы считаем важность для middle, то всё, что левее — middle и junior — берем в формуле со знаком плюс, а все, что правее — со знаком минус.
Junior-разработчик
Рассмотрим первый получившийся график для уровня junior для всех гибких навыков.
Каждая точка на графике — это один из soft skills, для удобства они отсортированы по возрастанию — чем больше значение, тем важнее навык для данного уровня. Теперь, чтобы взять какие-то из этих точек как «требуемые навыки для джуниоров», я анализировал график справа налево и искал резкий перепад в значениях.
Первый перепад после третьего навыка дал бы нам слишком мало требуемых навыков, поэтому берем следующий, более резкий перепад (132 - 39 = 93 пункта). Он отсекает 8 софт скиллов, которые мы и будем считать важнейшими для junior-разработчика:
Все гибкие навыки я разделил на 4 группы: навыки личной эффективности (на схеме — голубые), коммуникаций (белые), мышления (зеленые) и лидерские (фиолетовые). На картинке ниже мы можем увидеть, что в основном для джуниор-разработчика важны навыки личной эффективности, а также базовые навыки мышления и коммуникации:
И это кажется вполне логичным, что на данном уровне важны навыки, которые направлены на усиление его эффективности и компенсирование хард скиллов при отсутствии оных. Это те навыки, которые позволяют быть достойным винтиком в команде, ускоряют восприятие новых знаний и обучение им. По сути идеальной моделью junior-разработчика оказывается «губка», которая максимально быстро впитывает информацию вокруг себя и ассимилируется с командой на основе этого.
Middle-разработчик
Теперь составим аналогичный график для уровня middle по соответствующей формуле. Те 8 гибких навыков, что мы причислили к junior-уровню, здесь не рассматриваем.
С получившимся графиком ниже проводим аналогичные действия: ищем первый резкий перепад справа налево (121 - 30 = 91 пункт) и считаем важными для middle-разработчика те 15 навыков, которые находятся справа от перепада.
Если рассматривать получившуюся группу навыков относительно разбиения на группы, то мы можем увидеть, что на middle-уровне все еще доминируют навыки личной эффективности, но при этом впервые появляются навыки лидерства.
При этом навыки личной эффективности, которые оказываются важными для middle- разработчика, уже направлены не на то, чтобы максимально быстро влиться в команду (как для джуна), а чтобы разработчик мог эффективно работать в одиночку. Более того, так как теперь разработчик является самостоятельной боевой единицей, команда хочет полагаться на него и слушать его мнение, поэтому становятся важны навыки вроде критического мышления, обратной связи и ответственности.
Senior-разработчик
Аналогичным образом строим график для senior-уровня для оставшихся 18 навыков.
Здесь резкий перепад фиксирует те 8 навыков, которые будем считать критически важными для senior-разработчика.
Навыки личной эффективности наконец уходят на второй план, уступая навыкам коммуникации и лидерства.
Опять же, это абсолютно соответствует нашим ожиданиям. Например, от старшего разработчика требуется многозадачность, так как его уже довольно часто могут переключать между проектами или ставить на несколько одновременно. Вдобавок к этому, senior-разработчики как правило становятся менторами и получают в падаваны одного или даже нескольких разработчиков уровнем ниже. Поэтому для них становятся ключевыми такие навыки, как наставничество, эмоциональный интеллект и постановка задач.
TeamLead
Наконец, рассмотрим последний график для тимлида для оставшихся 10 навыков.
Изначально я не планировал здесь искать резкие перепады, так как не было цели дополнительно отсекать какую-то группу навыков. Но перепад получился настолько явным (186 - 45 = 141 пункт), что я решил для начала выделить группу из 8 навыков справа от линии перепада как ключевые для тимлида:
При разбиении на группы видим, что в основном для тимлида важны лидерские навыки и навыки коммуникации, которые направлены на эффективное управление другими людьми. Похоже на правду.
Любопытно, что опрошенные обозначили важными навыки, связанные с выступлениями и общением на конференциях, только для уровня тимлида. Хотя в реальной жизни многие разработчики начинают выступать уже на middle-уровне, и это вполне успешно формирует им личный бренд, помогающий им развивать карьеру.
Руководитель
Оставшиеся 2 навыка будем считать важными для руководителей выше уровня тимлида — для руководителей отделов, технических директоров и т.д.
Важно отметить, что в данном месте я также не совсем согласен с теми, кто проходил опрос. Управлять мотивацией своих сотрудников и руководить ими соответственно особенностям их личности важно уже на уровне тимлида. Но здесь стоит вспомнить, как мы задавали вопрос. Вероятно, данные навыки не считаются «критически важными» для тимлида, и он вполне может быть успешен без их применения.
«Не понимаю, что за навык»
Чтобы повысить релевантность результатов, я добавил этот дополнительный вариант ответа на вопрос про важность каждого навыка, так как не хотел, чтобы люди выбирали случайный ответ, портя выборку, если не понимали, о чем я их спрашиваю. И я решил отдельно посмотреть, какие навыки лидируют по таким ответам.
Результат меня удивил. Конечно, какие-то результаты можно было списать на погрешность того, что частично опрос проходили джуны и мидлы. Они действительно могли никогда не слышать о ситуационном руководстве (3 место). Но в лидерах оказались рефлексия и эмоциональный интеллект, хотя мне казалось, что в период бума популярности психологов в IT эти понятия давно у всех на слуху.
Как проверить Soft Skills на собеседовании
Теперь у нас есть полноценная картина: какие навыки на каком уровне важны. Но как выявить, что они есть у человека напротив вас?
Мы будем рассматривать некое типовое собеседование, состоящее из 3 этапов: HR-скрининга, технического собеседования и беседы с тимлидом/командой. Важно отметить, что на мой взгляд не существует единственно верного алгоритма проведения собеседования, всегда стоит индивидуально подстраиваться под конкретного кандидата.
Например, у меня была история, когда я стандартно собеседовал человека по Python примерно 50 минут, оставив в конце 10-15 минут на вопросы. Но когда мы перешли к секции вопросов кандидата, он достал листочек с 22 вопросами. Мне импонировал этот кандидат, к тому же в тот день это была последняя встреча у меня в календаре, и я уже никуда не спешил. В итоге мы с ним еще час просидели, пока я отвечал на очень разные вопросы. Начиная с того, какое у меня хобби, и заканчивая тем, как я вижу роль devops в компании.
Эта история закончилась позитивно, потому что этот человек, во-первых, принял оффер и вышел ко мне на работу, а во-вторых, спустя неделю я от HR узнал, что он написал статью на Хабре по итогам того, как он в десятки компаний ходил на собеседования и везде задавал те самые 22 вопроса. Узнав об этом, я не смог не спросить у него, почему он в итоге выбрал нашу компанию, и получил честный ответ: «Ты не соврал мне нигде, спокойно отвечал про минусы и плюсы компании, не пытался сбежать и ни разу меня не послал». Так что старайтесь быть более гибкими, всё-таки в нашей сфере работают люди с людьми, несмотря на все автоматизации и процессы.
Проверяем джуна
Вернемся к нашим навыкам, начнем с уровня junior. Как их проверить?
На одном из прошлых мест работы мне по наследству от предыдущего руководителя досталась интересная задачка про мышку и Землю. Представим Землю как идеально ровную окружность, вокруг неё расположено кольцо, тоже идеально ровное. Известно, что разница длин окружностей Земли и кольца равна одному метру. Вопрос: сможет ли пролезть мышка между Землей и данным кольцом?
Когда я спросил — зачем эта задача, то получил ответ, что она неплохо разбавляет атмосферу в конце собеседований перед вопросами. Я подумал — почему бы и нет, но спустя время увидел в ней новый смысл.
Возьмем все наши навыки, которые нужны для junior-разработчика. При внимательном рассмотрении оказывается, что довольно банальная задачка из курса математики 5-го класса может проверить сразу три навыка:
Поиск и анализ информации — я говорил человеку, что он может пользоваться всем, чем угодно, и спокойно найти формулу длины окружности, если он ее не помнит.
Логическое мышление — пусть в данном случае это не совсем логическая задача, так как она считается в общем виде. Но человеку еще нужно прийти к этому, а также преодолеть внутренний шаблон, что мышка по идее не должна пролезть.
Управление эмоциями. Самое смешное, что как раз из-за внутреннего шаблона выше примерно 10% людей мне с пеной у рта доказывали, что нет, мышка не пролезет. Даже начинали кричать на меня прямо на собеседовании, ибо как я смею такие простые задачи давать. Даже было такое, что люди пытались уйти с собеседования в этот момент.
Поэтому подобные задачи, как мне кажется, вполне могут быть полезны на собеседовании, но только в качестве вишенки на торте, не нужно строить на них целое интервью. Также важно отметить, что задачка про мышку - это просто пример из жизни, я не советую конкретно её, берите то, что вам по душе.
Почти все оставшееся навыки для джуниора можно проверить на техническом собеседовании. Например, адаптируемость — можно дать кандидату задачу с одними условиями, а потом в процессе решения их менять: «А если тут будет так? А так?» Становится понятно, насколько быстро человек может переключить контекст. И это еще до того, как вы его приняли на испытательный срок, перевели пару раз из команды в команду и поняли, насколько быстро он станет полноценной боевой единицей на новом проекте или на новом месте.
Навык открытость новому хорошо проверяется через вопросы: как человек воспринимает новые фреймворки, конференции и вообще новую информацию в своей сфере. Если человек отвечает, что он недавно про что-то читал, можно с ним поддержать разговор на эту тему. И быстро становится понятно, что ему интересно, к чему и как он относится, насколько он консервативен в своих взглядах на разработку.
Очень интересная ситуация с навыком восприятие критики. Для меня более ценен тот, кто сначала решил задачу неправильно, но когда вы ему сказали об этом и предложили попробовать ещё раз, быстро всё переделал. Часто встречаются кандидаты, которые расстраиваются, уходят в отрицание и говорят: «Не знаю, давайте дальше пойдем, я устал, у меня еще 14 собеседований сегодня». Плюсом к этому, вы еще можете увидеть, насколько человек умеет думать.
В свою очередь, навык умение слушать проверяется на основе HR-скрининга. Я могу задать вопрос на основе того, что HR рассказывал до меня на собеседовании. И будет понятно, например, насколько человек заинтересован в том, что вы ему рассказываете о компании.
Итак, мы проверили почти все скиллы:
Осталось последнее — командная работа. Очевидно, что с нашими таймингами проверить этот навык на собеседовании почти невозможно — человек приходит и уходит один. Коллеги из других сфер подсказали мне, что есть командные кейсы, когда приходит сразу 5 человек на собеседование и им дается задача, которую нужно решить за 30-90 минут совместно и испытать решение на другой команде. Звучит отлично, но на это банально нет времени. Этот навык проще проверить на испытательном сроке.
Теперь перейдем к middle-скиллам.
Проверяем мидла
Очевидно, что чем сложнее становятся навыки, тем сложнее их проверить банальными вопросами. Поэтому большинство из них я проверяю на третьем собеседовании с лидом или на развернутом собеседовании с HR. Конечно, многие навыки лучше проверяются на испытательном сроке, но мы пока касаемся только собеседования.
Например, самостоятельность. Поговорите по-честному с человеком, какой уровень надзора ему нужен и как он взаимодействовал с командой на прошлой работе. Тайм-менеджмент. Как распределяется рабочее время у сотрудника? Как вы ставите приоритеты, от чего это зависит? Какие задачи решаете сначала, какие потом?
Управление собственным развитием. Как и что развивали на прошлом месте работы? Помогло ли это как-то? Куда это привело?
Инициативность. Что предлагали, что из решений было внедрено? Что оптимизировали по своей воле? Предлагали ли более системные подходы? Участвовали ли в кросс-функциональных проектах? Это помогает понять, насколько человек инициативен по своей натуре и как это может вам помочь.
Рефлексию, о которой мы уже говорили, проверить довольно просто. Начните с того, что попросите человека назвать свои сильные и слабые стороны, но обязательно не останавливайтесь на этом и спросите в глубину: почему тот или иной навык он считает своей сильной/слабой стороной. Как раз ответ на уточняющий вопрос и покажет, насколько человек умеет базово рефлексировать.
Мы закрыли еще несколько пунктов, теперь перейдем к тем навыкам, которые мы проверяем не напрямую, а косвенно:
Управление стрессом. Надеюсь, что в 2021 году уже никто не проводит стресс-интервью. Но можно собрать фидбэк от людей, как они увидели восприятие человеком стресса (сначала HR, потом технические специалисты, дальше вы сами), всё сопоставить и у вас сложится какая-то картина.
Критическое мышление. Иногда я специально даю человеку задачу с неверными изначальными условиями. Важно не пробовать такое с джуниор-разработчиками, так как они спокойно будут решать подобную задачу до победного и расстраиваться, что у них не получается. Но при этом многие кандидаты уровня middle могут, спустя довольно быстрое время, не закапываясь в задачу на 20 минут, спокойно сказать, что не сходится. Или даже от противного доказать, что система неразрешима.
Письменное общение, обратная связь. После того как человек прошел все этапы интервью, я иногда пишу ему лично в любом мессенджере. И спрашиваю, как ему вообще — понравилось, не понравилось, что он вынес или нет. Даже по переписке в Telegram можно понять, как человек умеет донести свою мысль. Очевидно, это не про «Заранее спасибо» и «Добрый день, коллеги». К тому же заодно можно проверить навык предоставления обратной связи, спросив про то, что кандидат думает про рекрутера и коллег, которые проводили собеседования до вас.
Важно отметить, что люди всё равно нередко дают социально ожидаемые ответы, и нам как тимлидам они явно не помогают принять решение по кандидату. Люди говорят, что они всё знают, всё умеют, всем интересуются и слушают все подкасты. Но как с этим бороться? Как мы уже рассматривали на примере с открытостью новому и рефлексией, это довольно легко разбивается уточняющими вопросами. Если копнуть чуть вглубь, станет понятно, что человек вам соврал, потому что это выгоднее для его ценника, который он потом вам выставит.
Осталось несколько навыков, которые так легко не проверить за ограниченное время.
Их нужно проверять какими-то подробными кейсами. Например, как человек когда-то повёл себя в ситуации, когда от него требовалось взять ответственность на себя. Или что бы он накреативил в каких-то обстоятельствах.
Похожая ситуация с навыками на уровне senior и выше, поэтому я пока решил на этом остановиться и раскрыть это глубоко в отдельном докладе.
Как развивать soft skills внутри компании
Развитие гибких навыков нельзя рассматривать атомарно и отдельно, потому что они цепляются друг за друга. Исходя их этого, если, развивая один навык, мы косвенно развиваем другие, логично будет составить некую пирамиду развития навыков и посмотреть, как мы можем идти по ней снизу вверх.
Как я говорил, все навыки разбиты на 4 группы: личная эффективность, мышление, коммуникации и лидерские навыки. Затем я разбил их еще по столбцам, которые назвал стримами или ролями. В результате у меня получилась схема развития навыков. По вертикали уровни от junior до chief, по горизонтали — роли. Мы идём слева снизу и направо наверх. Роли расположены в том порядке, в котором их логичнее осваивать. Все навыки одного столбца, очевидно, влияют один на другой снизу вверх, а связи между навыками в разных столбцах я обозначил дополнительными стрелками.
На схеме можно увидеть, что например, для управления собственным развитием нужны рефлексия и восприятие критики — они как правило повлияют на развитие целевого навыка положительным образом. Развить многозадачность поможет импрув планирования и тайм-менеджмента. Чтобы прокачать ведение переговоров, есть нетворкинг. И так далее.
Эта схема оказывается очень наглядной и позволяет довольно просто показать сотруднику, какие навыки требуется развить для его роста на следующий уровень. Многие используют матрицы компетенций и PDP (Personal Development Plan). Все они также прекрасно вписываются в эту схему.
Я на ее основе делаю индивидуальный план развития для человека. Если я понимаю, что ему не хватает какого-то навыка, то на схеме ему легко показать, что нужно для получения этого навыка. Можно построить путь по схеме и прикинуть, как последовательно добраться до нужного.
Важно, что я ни в коем случае не хочу, чтобы подобный подход пытались натянуть на всех разработчиков. Многие разработчики не хотят развиваться, и требование развивать ещё и софт скиллы будет встречено скорее с антипатией. Поэтому пользуйтесь данной схемой скорее как интересным инструментом для тех, у кого есть запрос на карьерный рост.
Выводы
Благодаря опросу, мы теперь четко понимаем, чего ждать на разных уровнях развития разработчика — от junior-уровня до руководителя.
На низких уровнях (junior и middle) понятно, как проверить наличие навыков на собеседованиях.
Легко выявляется стеклянный потолок разработчиков и то, чего им не хватает, чтобы пробиться сквозь него и подняться на уровень выше.
Разработчикам легче объяснить, куда нужно качаться. Если вы хотите стать лидом, то на схеме можете много интересного для себя найти.
И пусть многим кажется очевидным: чтобы расти по карьерной лестнице разработчика, без прокачки soft skills не обойтись. Но почему-то в разработке это далеко не всем видится таким образом. Всё ещё устойчиво мнение, что для успешной карьеры нужно просто писать код лучше. Очень надеюсь, что мы в итоге придем к инженерной культуре, в которой всё, что я рассказал, будет абсолютно понятным и очевидным.
16 и 17 сентября в Санкт-Петербурге пройдёт конференция Saint TeamLead Conf 2021. Расписание и билеты.
