Разработчик должен хотеть себе падавана: как мы развиваем потенциал студентов
Привет, Хабр! Меня зовут Павел Варзаносов, расскажу о том, как мы в Simpl находим перспективных ребят и развиваем их потенциал. Начнем с небольшой предыстории.
Начало пути
В компанию я устроился разработчиком почти 5 лет назад. Работал над проектом по управлению инвестициями нефтегазовой компании. Тогда нагрузка на нем была непостоянной и задачи были преимущественно легкими. Попросил нагрузить меня еще одним проектом. Через 2–3 месяца понял, что совершил ошибку и не успеваю на обоих проектах, да и переключаться было тяжело.
В этот момент HR подогнали мне джуна и сказали, что он проходил у нас практику и он классный. Так у меня появился падаван (хоть и сам я не был джедаем). С задачами по проекту он часто справлялся самостоятельно, я лишь проводил ревью. На сложные задачи поначалу подключался я сам. Затем практикант их стал решать самостоятельно. Для падавана рост, для меня — меньше рутинной простой работы. Позже таким же образом у меня появился еще один падаван, и так я стал мастером над джунами.
Обретая смыслы
HR работали над увеличением узнаваемости нашей компании в вузах, а я искал возможности для гармоничного подключения практикантов и стажеров к разработчикам в проекты. Для себя в тот момент выделил несколько условий для подключения практикантов в команду:
Разработчик должен хотеть падавана, как минимум, быть не против.
У разработчика должны быть для падавана подходящие задачи. Есть проекты, в которых нет легких и коротких задач, как минимум в моменте.
Разработчик должен быть уровнем не ниже мидла.
Проработка методики
Постепенно выработал свою схему работы с практикантами. После университета любой джун столкнется с прохождением собеседований, поэтому к каждой должности у нас в компании, перед прохождением практики, проводится встреча — руководитель+HR+практикант. Она носит формальный характер. Так мы оцениваем мотивацию и возможные провалы в знаниях студентов, которые нужно изучить дополнительно во время прохождения практики. На собеседовании задаем технические вопросы, чтобы понять, какую базу имеет потенциальный стажер.
Вопросы базовые: например, чем абстрактный класс отличается от интерфейса, составление небольшого SQL-запроса по 2–3 табличкам. Если студент слабо отвечает на вопросы, то я понимаю, что всю практику он будет подтягивать эту теорию. И я не смогу его подключить к проекту, студент не получит практических навыков. В таком случае мы даем список теории к изучению, после которой он снова мог прийти к нам.
Если с теорией, как я ее называю, все хорошо, то мы брали на практику, на которой студент должен был спроектировать web API по выбранной им доменной области с простыми CRUD-операциями. Я проверял схемы баз данных и задавал вопросы и помогал с корректировками на этом этапе, чтобы по минимуму отвлекать разработчиков с проектов. На этом этапе остается большая часть студентов. Это то, что они успевают сделать. Только те, кому хочется развиваться в профессии, заканчивают этот этап раньше, чтобы попасть в реальную команду.
Как дела в команде?
В команде стажер или практикант закрепляется за разработчиком-наставником, разработчик сам определяет, какие задачи ставить. Студент на время практики или стажировки становится полноценным членом команды. Для джунов — это реальный опыт работы в команде, который не стыдно вписать в резюме, для нас же возможность посмотреть, как человек будет вести себя в команде.
Гуглить или нет, вот в чем вопрос
Позже я понял, что на собеседования с практикантами уходит слишком много и я составил обычный гугл-опросник, в который вставил все те вопросы, которые задавал на собеседовании. По ответам определял, брать на практику или нет. Сильно боялся вводить такой подход, потому что ответы можно загуглить. Оказалось, что часть студентов либо ленится гуглить, либо не может из нагугленного сформировать ответ на вопрос.
Решил для себя так: если ответил на вопрос — это хорошо в любом случае. Студент или знает ответ, или смог нагуглить, обработать информацию и сформировать ответ, что тоже является достаточно важным навыком для разработчика. Можно сказать, что процесс был выработан и мы по нему работаем уже примерно полтора года без существенных изменений.
3 качества идеального командного игрока
Руководители часто упоминают в своей практике книгу Патрика Ленсиони »3 качества идеального командного игрока». Меня она тоже не обошла стороной, и я стал накладывать опыт работы со студентами на модель из книги. Модель говорит о том, что хороший командный игрок создает ценность и нуждается в минимальном коучинге и менеджменте. Патрик считает, что идеальный член команды должен быть:
Скромным (Humble) — думает об общем благе, а не только о себе; цели команды важнее личных; вместо эго и статуса фокусируются на благополучии команды; признает заслуги команды; уверен в себе, рассказывает о своих навыках для пользы команды, но не хвастается ими. Этот навык мы проверяли, когда подключали студента к команде. Не проходили проверку на это качество студенты, которые решали рабочие задачи за счет других и присваивали достижения только себе (Представьте, такое было)
Голодным (Hungry) — усердным в работе, внутренне мотивированный, не бездельник, не нуждается в подталкивании; стремится к большему, а не довольствуется средним; заполняет пробелы в компетенциях команды, думает о следующих шагах и лучших способах достижения командного результата. Именно желание сделать больше и быстрее на 2 этапе, чтобы перейти в реальную команду для меня является признаком того, что студент имеет это качество.
Проницательный (People smart) — мудрый в общении с людьми, понимает динамику команды, эмоции и мотивы других, практикует EQ и ведет себя, соответственно, задает хорошие вопросы и слушает, тактично участвует в конструктивных спорах. В этом пункте уже я лично стараюсь определить это качество в общении 1:1.
Может быть восемь различных наборов навыков по этой модели. Мы ищем, чтобы как минимум два навыка были выражены сильно, а третий не уходил в минус. Скромный и голодный, но не проницательный (мудрый в общении) — «Случайный разрушитель» — может добиться внушительного результата, но испортить отношения в коллективе словами и действиями. Желает добра, поэтому воспринимает корректирующую обратную связь. Совет, если вы такой: относитесь ко всему позитивнее; слушайте других, чтобы понять, общайтесь с людьми.
Голодный и проницательный, но не скромный — «Искусный политик» — амбициозный и работящий, знает, как показать добрые намерения, заботясь о собственной выгоде. Члены команды увидят манипуляции не сразу. Совет, если вы такой: старайтесь заботиться не только о себе, чаще говорите «спасибо».
Вместо вывода
Рекомендую почитать книгу Ленсиони про идеального командного игрока. Наложите эту модель на себя, посмотрите, где и что вы можете изменить в вашей работе. Изменения в работе, которые влияют на результат команды, точно не останутся незамеченными. Вывод для стажеров: делайте больше и показывайте в своей работе готовность становиться лучше и быстро расти, впитывайте знания и навыки от наставников.
Вывод для наставников: вкладывайтесь в своих практикантов и стажеров. Каждый из вас найдет свой смысл в этом. Это и уменьшение типовых задач, которые вы передадите падавану, и, так сказать, отдача дани тем, кто помогал вам, и выстраивание отношений, ведь ваш падаван в будущем может помочь.
