Хабр, привет! На связи Костя Линев и Женя Заварзин, мы разработчики в КРОК (а Женя еще и ресурс-менеджер). 

В 2020 году мы придумали формат внутренних экзаменов для .NET-разработчиков (взамен программ сертификаций от Microsoft). Придумали исключительно в образовательных целях, а заодно немного раскачали коллег и создали пространство для безопасного общения и обмена опытом, который подойдет всем – и разговорчивым разработчикам, которым не хватает митапов и рабочих чатиков, и не очень-то разговорчивым, которые на эти самые митапы ходить стесняются. 

Формат внутренних экзаменов прижился – сейчас его проводят во всех группах разработчиков, не только .NET. Сдают его преимущественно стажеры и младшие, а более опытные коллеги – наставляют молодые умы. В посте рассказываем, как дошли до жизни такой и что там под капотом у экзаменов. Рассказываем не только сами – внутри есть комменты от ребят, которые уже прошли через такой опыт.

Откуда вообще пришла идея

Когда-то давно я (Костя) пришел в КРОК стажером. На тот момент в компании была традиция: чтобы закончить стажировку .NET-разработчику, надо было сдать сертификационный экзамен от Microsoft. За счет компании само собой. В моем случае, поскольку я тогда плохо знал базы данных, таким экзаменом оказался TS: Microsoft SQL Server™ 2005 - Implementation and Maintenance, каковой я успешно сдал и остался в компании на многие годы. И экзамены сдавал с тех пор тоже много раз. Частично потому, что мой тогдашний руководитель коварно не сказал мне, что вообще-то по традиции одного было достаточно. Частично – чтобы себя почелленджить, доказать себе и руководителю что освоил что-то новое. Да и бумажки красивые за них давали, на заказчиков впечатление производило. Со временем сдача экзамена стала уже не такой обязательной для стажеров, но тем не менее экзамены по разным причинам постоянно сдавались. В целом у КРОК с программой MCP (Microsoft Certified Professional) сложились давние и продуктивные связи.

И вот наступает 2020-й год. К этому времени я уже какое-то время был руководителем той самой группы .NET-разработчиков, в которую когда-то приходил стажером. И да, мы все еще периодически сдавали экзамены MCP.

Не могу сказать, что экзамены от Microsoft были в точности тем «что доктор прописал» для группы. Экзамен представляет собой автоматизированный тест, который сдается под камерами, в тестовом центре. Вокруг него тщательно создается впечатление серьезности события. Но состав вопросов меняется редко, вариантов ответов у каждого вопроса немного (обычно четыре), способы жульничать на таких испытаниях отлично известны всем, кто учился в школе. Соответственно, как гарант наличия знаний экзамен работал плохо.

С содержанием тоже не все было хорошо. Какие-то темы очень нравились авторам вопросов из Microsoft, но были для нас совершенно неактуальны, какие-то наоборот едва освещались в экзамене. Например, долгое время чтобы считаться сертифицированным разработчиком под T-SQL надо было узнать все на свете про развертывание и администрирование SQL Server, хотя в реальной работе разработчики крайне редко разворачивают кластеры. Но ты шел и пол экзамена отвечал, как правильно настроить репликацию в каком-нибудь экзотическом случае. Иногда вендор и вовсе включал в экзамен вопросы, откровенно призванные привлечь внимание к какой-то новой функции, которую ему сейчас хотелось продвигать.

Впрочем, было и хорошее. Каким бы он ни был, экзамен тем не менее мотивировал в полном объеме изучить возможности той или иной технологии вендора. Собственно, та же самая особенность – то, что у вендора другое представление о важности тех или иных тем, чем у нас, часто работала на расширение кругозора при подготовке к экзамену. У меня лично был случай, когда я, готовясь к экзамену вычитал о наличии у все того же SQL Server’а функции, которая очень сильно облегчила нам жизнь в проекте, в котором я в то время работал как разработчик. Для любопытных читателей поясню, что это был момент появления AlwaysOn. Мы собирались вручную настраивать readonly-репликацию, как это было принято раньше. Но в итоге обошлись самой минимальной конфигурацией этого самого AlwaysOn, на настройку которой мы не потратили практически ничего.

В общем вопросы к ним были, но экзамены существовали и какую-то ощутимую пользу приносили. И вот Microsoft объявляет о том, что сворачивает практически все интересные нам тематики сертификации. Из разработки у них фактически остался только Azure, тема специфичная и к нашему бизнесу имеющая довольно опосредованное отношение. Я, конечно, расстроился – все-таки теряем пусть и не самую критическую и не самую любимую, но заметную часть программы развития наших ребят. Так что я позвал Женю, который как раз подключался к руководству разросшейся группой, и мы стали думать, а чего теперь с этим делать.

Очевидный вариант – выбросить всю историю с экзаменами и измерять развитие разработчиков исключительно по отзывам на их работу в проектах. Вариант на самом деле неплохой – изобретать ничего не надо. Вроде как даже можно объявить эту отмену доблестью – теперь только реальная работа влияет у нас на рост сотрудников, никаких там искусственных тестов.

Однако были и другие соображения

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

Не то чтобы мы погрязли в бюрократии и предлагаем оффер на новую должность/проект только после закрытия галочки «сдал экзамен». Но экзамен был удобным и понятным форматом, с которого запускался процесс. 

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

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

Второй вариант: «Ну, мы подумаем, что-нибудь когда-нибудь найдем, а пока читай интернет и жди». Это звучит уже не как план развития, а как вежливое предложение пойти куда подальше, даже если ты очень даже за, то чтобы человек учился и продвигал в компании интересный ему стек.

2. Экзамены, при всех их недостатках, выделяли среди молодцов еще и тех, кто готов тратить время и силы на собственное развитие.

Руководитель отдельной проектной команды как правило сильно заинтересован в сохранении команды. Поэтому если программист не косячит откровенно, то он неизменно получает сияющий отзыв на свою работу. В лучшем случае с какими-то мягкими советами «над чем поработать». И вот в компании имеется 40-50 круглых молодцов-разработчиков, которые все заслуживают самого лучшего, их всех немедленно надо повышать и все такое. Как при этом этих самых молодцов друг с другом сравнивать и делить между ними ограниченный бюджет? Непонятно.

3. В тот период мы задумались, как активизировать обмен знаниями, да и просто обыкновенное личное общение среди разработчиков.

Тот случай, когда понятно, что всем будет лучше, если у каждого отдельного сотрудника будет куча знакомых, которые занимаются похожими технологиями, у которых можно спросить совета, а то и просто поболтать за жизнь. Гильдий тогда у нас еще не появилось, в чатике сообщества мы в основном общались на отвлеченные темы, успехами и фейлами не делились, а специфика проектного бизнеса такова, что ребята работают в командах проекта и с «соседями» пересекалась редко. Тогда еще начался ковидный карантин. 

Собрать несколько десятков программистов в комнате реальной или виртуальной и сказать «общайтесь» – идея скверная. Программист человек увлеченный, подавляющее большинство скажет: «зачем вы мешаете мне работать». И в общем-то будет прав. Само собой мы додумались до очевидной идеи устраивать внутренние митапы в разных форматах. История классная, но это развлечение не для всех. Обычно они превращаются в клуб для некоторой части чуть более общительных разработчиков, которым прикольно качать навыки публичных выступлений. Хотелось предложить формат, который импонировал бы тем самым прагматикам, которые хотят, чтобы им «не мешали работать».

И вот мысли о нехватке поводов для разработчиков компании собраться вместе и поговорить о профессии + необходимости что-то делать с экзаменами в нашей голове объединились в идею: а давайте сделаем из экзамена социальное событие для нашего коллектива разработчиков. Чтобы экзамен больше не был получением сомнительной правдивости бумажки у бездушного компьютера, который вроде как представляет далекого заокеанского вендора, а превратился в событие, на котором разработчик может получить от всего нашего сообщества одобрение своих навыков и знаний. Что называется «людей посмотреть и себя показать». И тогда получится что собираемся мы уже не «просто поговорить ради поговорить», а помочь коллеге совершить новый шаг в профессиональном развитии. Уже звучит как благородное начинание.

Логика экзамена

Дисклеймер 1: основная цель – это не провести экзаменовку, а научить ребят тому, что им пригодится в жизни в коммерческой разработке. 

Дисклеймер 2: экзамен почти сразу вышел за рамки стека .NET, поэтому не удивляйтесь, если дальше по тексту встретите упоминания других тем и технологий.

Следуя этой идее, экзамен-копию вендорского делать не стали – в том плане, что тесты, квизы и другие вещи с выбором вариантов ответов нам не подходили. Решили задачу радикально – придумали формат без формата, когда нет единого для всех плана, что будет на экзамене, кроме понимания состава – экзаменуемый, оппонент и ментор.

Что это за люди?

• Экзаменуемый – тут все понятно, коллега, который хочет прокачать скилл владения технологией (чаще всего стажер или джун, или коллега, который переходит на новый стек);

• Оппонент – матерый сотрудник, старший или ведущий разработчик, который экзамен принимает (и придумывает, в каком виде он будет его принимать);

• Ментор  – еще один матерый коллега, который наставляет экзаменуемого и помогает «не соскочить».

Экзамен у нас всегда публичный – приглашаем всех коллег, кому интересно, побыть зрителем. Все, конечно, в дружественной манере, без нерва, трясущихся пальцев и валящих вопросов (но вопросы они могут задавать). Не публичная порка, в общем :)

Управляемый хаос решили сделать намеренно – во-первых, хотелось не напоминать вендорский экзамен (напоминаем, что экзамен по нашей задумке – событие социальное). Кто-то любит устраивать собеседование, кто-то – классическое тестирование, а кому-то – лайвкодинг подавай. А во-вторых, мы в этом видели еще и возможность прокачать у опытных сотрудников организаторские скиллы и наставничество. Условно, если ты сейчас middle , но хочешь стать старшим или ведущим, тебе нужно уметь работать с командой, передавать знания. Экзамен – хорошее пространство, чтобы потренироваться. 

Один из интересных форматов, который родился – демо-приложения. Старший разработчик захотел выучить Vue, но сдавать экзамен в виде собеседования, учить эту всю теорию для таких опытных ребят не очень интересно, поэтому в тройке мы посидели, подумали и предложили идею сделать какое-нибудь демо-приложение на выбранной технологии. И под руку попался небольшой старый legacy-проект, где была большая логика backend и небольшая логика на фронте, которая была написана на чем-то очень древнем. В итоге сошлись на том, что фронт он перепишет на Vue, а заодно и подтянет бэк. И сдавать такой экзамен куда интереснее, сразу можно закидать вопросами – а вот тут почему такие компоненты, а там почему такую логику навесил? 

Процессно все выглядит так: 

• коллега договаривается с ресурс-менеджером, что хочет сдать экзамен; 

• мы кидаем «клич» в чатике – ищем и оппонента, и ментора; «квот» и ограничений у нас нет – можно по несколько раз быть в одной роли, или попробовать другую;

• оппонент придумывает, как хочет провести экзамен, какие будут вопросы, сколько времени ориентировочно займет подготовка;

• ментор встречается с экзаменуемым, обсуждают план подготовки, какие-то важные точки прогресса, договариваются о шагах и следующих встречах; 

• когда ментор уверен, что его подопечный – молодец и готов, он пишет оппоненту, мол мы готовы, давайте дату выбирать; 

• оппонент вспоминает свой коварный план проведения экзамена и начинает подготовку + решает оргмоменты (договориться с командой обучения, всем написать, проинформировать и другие детали);

• собственно – сам экзамен.

Жестких временных рамок у экзаменов тоже нет – можно готовиться и изучать тему и 2 месяца, и полгода. Идеально сдать его в период между мониторингами. «Когда-нибудь сдать было бы здорово» – такое не прокатывает. У менторов есть что-то вроде графика пингов, чтобы держать коллег в тонусе :)

Что важно про ментора. Нет задачи превращать его в преподавателя, который индивидуально читает лекции и объясняет материал «от и до». Он скорее навигатор – подсказывает и направляет, советует источники (книги, статьи, видео), подключается по сложным темам, которые никак не даются. И трекает прогресс – что-то вроде мини-экзамена по теме, на котором можно понять, над чем еще стоит поработать. 

Опыт, косяки и как все начиналось

Запуск идеи мы приурочили к летнему мониторингу (это полугодовое ревью, где подводим итоги работы сотрудника, делимся обратной связью и строим планы на будущее). Собственно, у стажеров и джунов спрашивали, как им идея сдать такой экзамен, а опытным ребятам предлагали попробовать себя в роли ментора и оппонента. 

К нашей радости (и немного удивлению), формат восприняли на ура – особенно мы удивились, когда поняли, что и у прошаренных ребят был запрос на сдачу экзамена по технологиям, которые они не успели изучить, или давно не использовали. Например, старший backend-разработчик захотел сдать React и JS, еще были коллеги, которые захотели почелленджить себя в паттернах и проектировании. Мы вообще-то не планировали, так как тема нетривиальная, для запуска пилота точно не годится. Но в итоге челлендж приняли и получили 2 экзамена для старших разработчиков и мидлов, которые хотят стать старшими. Получилось очень кстати, так как в матрице компетенций департамента появился пункт о том, что старший разработчик должен уметь проектировать и строить архитектуру небольшого проекта или отдельных частей крупного. Пройденный экзамен прибавлял очков уверенности, что задача будет сотруднику по силам. 

А вот с какими багами столкнулись.

1. 2+ часа в зуме – это перебор

Первый экзамен был сразу огненным и, кстати, не по .NET, а JS и Vue. И оппонент, и экзаменуемый были очень круто подготовлены – первый активно задавал вопросы, и так, и эдак пытался подловить, а второй уверенно их отбивал. Но экзамен шел два с лишним часа и под конец устали все. Если первый час все были вовлечены и подкидывали вопросы в чатик, то под конец остались только самые стойкие, а лично мы уже потеряли начало и конец. Плюс, что проверили весь объем материала и довольно подробно про него поговорили, но точно можно было этого достичь меньшими потерями. 

Сейчас установили максимум в 1,5 часа, а в идеале уложиться в 1 час. Это круто повлияло на вопросы от оппонента и из зала – уровень сложности сразу синхронизируется с уровнем экзаменуемого. Если он отвечает уверенно, то легкие вопросы сразу перескакиваем, переходим к более сложным, и не топчемся на месте «лишь бы спросить».

2. Оценивали результаты однобоко (сдал/не сдал)

Первые 5 или около того экзаменов принимались в формате сдал/ не сдал. И уже где-то на 2-3 экзамене мы начали сомневаться в своем методе оценки – упустили главную задачу подсветить человеку уровень знаний, и ушли в сторону универских зачетов.  

Докрутили так: сдал/ не сдал оставили, но насытили комментариями. Например, если большую часть материала коллега знает уверенно, то результат – сдал, но вместе с ним он получает список пунктов, над которыми нужно еще поработать. Пересдач у нас нет – здесь доверяем ментору, что он вместе со своим подопечным заберет эти темы как домашку.

3. Давали обратную связь только экзаменуемому, но забывали про всю команду

Результат экзамена – общий на всю команду, зависит не только от того, насколько разработчик молодец и готовился. Очевидно, но подумали мы об этом не сразу  и фокусировались только на подробной обратной связи экзаменуемому – что знает хорошо, какие точки роста.

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

Что думают участники экзаменов 

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

Слава Шенгур, старший разработчик

Сдавал экзамен по паттернам проектирования

Я сам был инициатором сдачи экзамена, давно хотелось закрыть эту тему для себя. В университете такого курса не было, а когда сам начал работать, то понял, что совершил много ошибок, изобретал велосипеды там, где это было совсем не нужно. А если делал правильно, но даже не подозревал, что у этого, условно, есть официальное название :)

Сертификаций официальных по этой теме нет, так как это все-таки база. Мне было важно разобраться и получить обратную связь и чтобы погоняли как следует. У Microsoft сертификации очень обширные, а еще я не люблю формат тестов. Мне важно живое общение. В этом плане мне повезло и с ментором, и с оппонентом – Леша (ментор) помогал мне копать в глубину, мы с ним раз 5 встречались за подготовку. А перед экзаменом провели «репетицию». А у Миши (оппонент) получилось сделать очень интересный формат: это были не просто ответы на вопросы, а разбор тем с разных сторон – где-то теоретически ответить, где-то из реальных кейсов найти ответ, где-то прям руками поделать. 

Минус этого формата для меня в том, что сложно состыковать все стороны, должны сойтись звезды. Но я и сдавал одним из первых, когда все только вставало на рельсы. Но плюс, который все перекрывает – коммуникация с ментором. Реально начинаешь ближе общаться с коллегами и видеть их профессионализм, перенимать опыт. Я вот вроде бы Лешу знал, но за время подготовки наше общение стало другим. 

Миша Прокопьев, ведущий разработчик

Был оппонентом у Славы на экзамене по паттернам проектирования

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

Всем, судя по высказываниям, было офигительно интересно. Никто не скучал. Слава практически на все вопросы отлично ответил. В такой тематике можно просить код написать, но я сосредоточился немножко на другом. Главное понять: понимает ли экзаменуемый эти самые паттерны объектно-ориентированного программирования? Как понимает? Способен ли один отличить от другого? Способен ли, если стоит конкретная задача, выбрать правильный паттерн и описать его (в чем его преимущества и недостатки)? Поэтому именно в таком формате я провёл экзамен, чтобы выяснить вот эти основные моменты: понимание, умение распознавать в коде и умение применить на практике, если стоит определенный сценарий и нужно выбрать паттерн, который тут подойдет идеально. Чтобы велосипеды не изобретать, а использовать уже хорошо проверенные временем подходы. 

Пока готовился, и сам освежил все в памяти – очень бодрит. 

Итоги и выводы

Итого, получается, что экзамены мы успешно заместили. В процессе, правда, пропали внушительные бумажки от вендоров, которые нравились заказчикам, но мы не очень переживаем. Все равно все более-менее грамотные специалисты, в том числе у заказчиков, знали, что бумажка-то на самом деле ничего не гарантирует.

Зато появилось ощущение, что образовательная функция экзамена теперь заслуживает заметно большего доверия. Это действительно мероприятие, после которого ты узнаешь что-то новое и, в общем-то, не самый дурной способ замотивировать себя выучить новую технологию. Тут тебе помогут, поддержат, подскажут, какие знания потом в бою пригодятся, и результаты твоих усилий проверят достаточно строго. А поскольку мы экзамены еще и записывать начали, у нас внезапно образовался каталог вполне приличных роликов, где за час-два по самым разным темам можно получить неплохой обзор технологии даже с некоторыми подводными камнями. Я, например, недавно осваивал Vue.js и с очень большим интересом посмотрел видео нашего экзамена по Vue. Оно оказалось на удивление познавательным.

Еще одна вещь, которая изменилась к лучшему – набор тем. Мы теперь не зависим от воли вендоров и состояния рынка, если у нас есть хотя бы два специалиста, которые знают вопрос, мы можем провести по нему экзамен. Для нашей группы это важно: так исторически сложилось, что мы занимаемся не только .Net’ом, но и огромной кучей разной степени смежности технологий. Раньше в компании была шутка, что нашу группу надо переименовать в «группу разработчиков не Java». Потом мы начали заниматься и Java тоже.

Новый формат экзамена весьма позитивным образом сказался на наличии поводов пообщаться. Мероприятие пользуется стабильным успехом. И самое главное, никто не приходит из-под палки. Нет ощущения казенного сборища по разнарядке. Приходят потому, что интересно. И это мало того, что хорошо для компании, еще и очень приятно для нас как для организаторов.

Наконец, мы стали получать гораздо больше информации об успехах сотрудников, чем раньше. Мы все еще успешно выделяем тех, кто хочет учиться, среди своего «множества молодцов», но теперь мы еще и видим тех, кто готов учить и вкладываться в развитие команды и окружающих. А это же чрезвычайно важное качество, которое очень трудно фиксировать и измерять. Теперь у нас про каждого сеньора есть история «был наставником у этого», «проводил экзамен вот на эту тему». И человеку есть чем похвастаться и для нас ситуация намного более прозрачная.

А еще важно, что связи учитель-ученик, они не только у нас на бумаге остаются. После экзамена часто оказывается, что ментор (а иногда и оппонент) помогает своему бывшему протеже уже с какими-то рабочими вопросами. Просто так, по старой памяти. И получается, что формальная процедура порождает весьма неформальный человеческий контакт, которого в нашей индустрии часто очень не хватает.

В общем, наверное, мы хотим этой статьей сказать, что, начав, мы просто хотели как-то выкрутиться, чтобы не потерять те немногие полезные эффекты, которые мы получали от вендорских экзаменов. Но неожиданно для себя получили формат внутренних мероприятий, который нам нравится гораздо больше, чем мы от него ожидали. Получилась не просто замена, а какой-то новый и, кажется, позитивный элемент жизни компании. Чему мы очень рады и хотели этой радостью поделиться. 

А жизнь экзаменов продолжается – идею подхватили ребята-джависты, возможно, в одном из следующих постов покажем, как это работает у них.