Егор Емельянов пишет:

Грейд разработчика != звание

В последнее время часто собеседую ребят, которые начинали работать в ИТ в 2020-2022 годах и замечаю, что грейд они получили, как очередное звание в армии или полиции

Ребята уровня мидл не знают сложность получения элемента по ключу в Map, путаются в сигнатуре функции reduce, изобретают новые свойства в верстке.

И я решил задавать вопрос: «как ты стал мидлом?». Чаще всего звучал ответ: «я проработал в компании n-лет/m-месяцев и дорос до мидла», где n в диапазоне от 1 до 2, а m от 6 до 8. «А была ли аттестация, ревью выполняемых задач и производительности?» - спрашивал я и чаще всего слышал ответ: «нет, просто говорили, что я стал лучше работать». А потом соискатель добавляет: «я хочу стать сеньором в будущем». «Как думаешь, что для этого нужно? Есть план?» - спрашиваю я и слышу в ответ: «Поработать еще несколько месяцев/лет».

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

Чем это грустно? 1. у талантливых с виду ребят 2-5 лет работы прошли так, что они не смогли дорасти до уровня среднего специалиста 2. они менторят джунов, хотя сами еще не стали достаточно самостоятельными, что усложняет джунам развитие 3. ребята, которые больше вкладываются в свои знания и рост не получают новый грейд, просто потому что прошло мало времени

В итоге складывается довольно сложная ситуация для сотрудника и компании, приводящая к проигрышу обеих сторон.

Что с этим можно сделать?

Начать смотреть на навыки и скиллы разработчика, вместо его рабочего стажа.

Джун, миддл и сеньор могут различаться от компании к компании. У меня на собеседованиях были сеньоры, которые для нашего проекта были на уровне мидл+, а также мидлы, которые давали мидл+ или сеньор-.

И лучше всего привязываться к интересующим компанию и команду навыкам.

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

При определении самих качеств и характеристик можно опираться на тех сотрудников, кого вы считаете подходящими для того или иного грейда. Изучите их сильные стороны и положите в основу системы грейдов.

А дальше проведите аттестацию/перфоманс ревью, раздайте грейды и составьте планы развития, чтобы помочь вашим сотрудникам вырасти и соответствовать грейду не только на бумаге.