Презентация
серверов от Acer
До начала осталось:
Смотреть
Карьера
MetaLamp

Как карта развития помогает справляться со стихийными повышениями и неосознанной некомпетентностью

Меня зовут Сергей Черепанов. Я сооснователь и CTO команды разработчиков MetaLamp (Fullstack Development до 2021 года), с 2012 практикующий веб-разработчик. На старших курсах университета я заинтересовался кодом: начал что-то «пилить», брался за проекты на фрилансе «для опыта», а позже нашёл работу в стартапе Rizzoma. Постепенно вокруг сформировался «студенческий кружок» таких же энтузиастов, и у нас появлялись задачи с бюджетом, а не просто за опыт. К 2014 году этот «кружок» вырос в компанию с большими коммерческими проектами, в которой к 2016 году мы доросли до собственного стартапа курьерской доставки на 200 заказов в день.

Но как и в университете, так и сейчас, когда в нашей команде пять десятков разработчиков, основная проблема — это развитие. Как, куда и зачем двигаться разработчику — вот вопросы, на которые я ищу ответы с 2012 года. Сейчас расскажу, как нашёл ответ на этот вопрос в карте развития и чем она будет полезна вам.

Зачем вообще понадобилась карта?

Наша команда разработчиков — это фронтендеры и бэкендеры. Фронтенд на TypeScript и React, а бэкенд — на Haskell. Мы помогаем разрабатывать аналитические системы, платформы визуализации данных, финтех и martech-проекты. С 2014 года проекты постоянно усложняются. Если в 2014, условно, мы разрабатывали небольшой портал в команде из пары человек, то в 2016 уже занимались криптовалютными биржами командами по 7 разработчиков в течение года и больше.

Но здесь есть нюансы.

Оценка проектов

Все проекты мы оцениваем стандартно: прикидываем стек, архитектуру, разбиваем задачу на части и этапы, прогнозируем время на исполнение. Оценить лендинг — это одно (как говорится «вжух и в продакшн»), а оценить задачу «написать бэкенд для торговой площадки» — уже другое. Здесь нужно точно подобрать разработчиков с опытом и знаниями. А как понять, что знания есть?

  • Интуитивно: «Я помню, Лёха чем-то таким занимался?».
  • Провести One-on-One, чтобы понять, кто что осилит.

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

Вот было бы здорово, если бы был такой «эталонный» документ, где все разработчики «отсортированы» по знаниям, навыкам, технологиям, опыту и другим параметрам.

Неосознанная некомпетентность

Без понимания знаний команды мы страдали от неосознанной некомпетентности. Например, переводим миддла с проекта виджета аналитики на «UBER для курьеров», где ему нужны принципы SOLID. Но он почему-то регулярно их нарушает. Может просто не знает? Оказывается, да — о принципах SOLID он не слышал. Если бы он где-то что-то читал, то у него была бы иллюзия знаний. Здесь же нет даже иллюзии, а есть некомпетентность, которая не осознаётся.

Мы доверяем разработчику, но объективной оценки его знаний не проводили. Как понять, в каких областях он «хромает»? Можно через ревью или One-on-One. Но если мы проведем несколько десятков таких мероприятий с нашей командой, что уже долго, то в итоге у нас получится пара десятков документов с разбором знаний наших ребят. А если мы их потом изучим, то вычленим повторяющиеся вопросы. Опять получается, что нам нужна некая общая система для «ревью знаний».

Развитие разработчиков

«Ревью знаний» мы провели. Дальше мы можем повышать квалификацию разработчиков, чтобы они могли работать над проектами всё сложнее и масштабнее. Как это сделать?

  • Тянуть. Для прокачанных разработчиков мы предлагаем проекты со сложным фронтендом, например, криптовалютную биржу. Начинающим можем отдать unit-тесты несложных проектов, но потом его обязательно поставим на проект сложнее, чтобы рос.
  • Оставить на самотёк. Несмотря на то, что у нас никто никого не заставляет заниматься самообучением, сами ребята тоже хотят расти и браться за задачки посложнее.

Но это всё несистемно и мешает самим разработчикам, в первую очередь. Они не понимают траекторию развития, хватаются за всё подряд, глубоко не вникая. Как следствие, плодятся велосипеды. Для большинства проблем уже есть известные решения, паттерны, библиотеки, но вместо этого появляется ad-hoc для конкретной проблемы. Это лишняя работа (и оплата), которую в будущем придётся исправлять.

Если оставить развитие на самотёк, то знания будут приобретаться неравномерно. Обычно изучается только то, что связано с задачей (и то не всё). Многие темы, необходимые в целом для системного развития, останутся за бортом. Джуниор будет скакать по темам почти рандомно — это будет зависеть от задач на проекте. Задачи же, могут быть связаны с исправлением багов или поддержанием легаси (в основном). В итоге джун ещё не успев толком прокачаться, уже застревает в болоте, а вытащить на более сложные проекты его еще непросто, так как он пока не тянет. Замкнутый круг.

Опять же, нужна система оценки знаний, которая помогала бы систематизировать рост разработчиков.

Стихийные повышения

Это уже следствие неосознанной некомпетентности и отсутствия системы развития.

Как понять когда разработчику поднимать зарплату без точного понимания, что он может и не может? Это сложный вопрос, который создает локальные военные конфликты в коллективе. Иногда разработчики сами просят повышения, когда считают, что доросли. Но получается, кто громче просит — тот быстрее получает? Чаще всего, большинство не приходит с такими просьбами, а просто копит недовольство и чувство недооценённости, пока где-то не выстрелит.

Разработчикам хочется регулярного повышения зарплаты без разговоров с менеджерами и «выклянчивания» (а кому не хочется?). Поэтому в крупных компаниях есть грейды (уровни). Они предсказуемы: всегда понятно за что, когда и как можно получить повышение без разговоров с менеджером и «вытряхивания» из него новой зарплаты.

Эти 4 причины привели нас к идее создать систему оценки знаний разработчиков — карту развития. Получился некий «эталон», к которому можно «приложить» проект, чтобы понять, кто из наших ребят его «затащит».

Что такое карта развития и как устроена

Карта развития — это список грейдов и теоретических вопросов для них.

Грейды — уровни развития разработчика, от которых зависит должность, зарплата, уровень сложности задач, наличие менторства и свобода в решениях.

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

Карта разделена на бэкендеров и фронтендеров.

Shared — общие темы для бэкенда и фронтенда.

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

В каждом грейде содержится свой список навыков и знаний.

Если углубиться дальше, то увидим список вопросов.

Отвечая на них, разработчик учится, а потом «сдаёт» грейд (об этом чуть позже) и получает новую зарплату и «звезду» на погоны.

Для фронтенда сейчас 8 уровней, а для бэкенда — 4: три для джуниоров и один для миддла (сеньоров пока ещё нет).

Для каждого грейда есть список технических и нетехнических вопросов.

Технические

Начнем с Junior. В нашей компании джун — это самостоятельная «боевая единица». Он умеет решать локальные декомпозированные задачи, которые укладываются в принятые в проекте соглашения и архитектурные принципы. По нашей карте джун уверенно владеет вёрсткой, хорошо знает JS, React и unit-тесты.

Middle больше про концептуальные знания, а не конкретные инструменты. Например, в миддловских грейдах мало вопросов про JS, а про React и вовсе нет. Зато много про ООП, принципы SOLID, DDD, и архитектуру в целом.

В нашей команде Middle не просто исполнитель. Он понимает, какую бизнес-ценность приносит команде и продукту, поэтому может предложить своё решение с аргументацией. Чаще всего он умеет задавать вопросы не только «Как решать задачу?», но и другие, например, «Почему эта задача важна?».

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

Софт скилы

Карта у нас охватывает разные области знаний и компетенций. Например, в списке к изучению на Junior-3 у нас есть книга Барбары Минто о том, как структурировать текст.

Книга пригодится разработчикам, чтобы лаконично и сжато донести какую-то свою идею, например, на стендапе за 2 минуты.

Навыки коммуникации важны. Наше основное направление — это коммерческая разработка в команде. Поэтому важно уметь доносить свои идеи как технарям (причём не только технические ценности), так и остальной части команды, например, объяснять сложные технические термины простым языком.

Также у нас есть вопросы по схемам управления, которые мы используем, информация про планирование, управление своим временем, декомпозирование и приоритизирование задач.

Как карта работает

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

Повышения

Когда разработчик хочет перейти на следующую ступень, например, с Junior-1 на Junior-2, он:

  • готовит одну или несколько тем из грейда;
  • ищет 2-3 разработчиков, что уже сдавали эти темы;
  • просит принять грейд.

Грейды может принимать любой член команды, который сам уже перешёл на этот же грейд или выше. Это обеспечивает бесперебойную и успешную работу инструмента.

Процесс принятия. Все договариваются об удобном времени для интервью в Telegram, а интервью проводят чаще в офисе. Но у нас треть сотрудников на удалёнке, поэтому мы встречаемся и в Zoom.

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

Примечание. Интервьюеры стараются собеседовать беспристрастно, потому что если они примут интервью «для галочки», то это нарушит работу всей команды в целом.

Сдача темы занимает пару часов, а подготовка — пару недель. После сдачи сдающий получает много обратной связи: дополнительные вопросы, источники от миддлов, которые нужно изучать. Вопросы потом «кочуют» по другим интервью: когда разработчик сдал грейд, а потом принимает сам, то тоже может их вспомнить. После этого вопросы могут стать частью карты.

Практика сдачи грейдов помогает также и интервьюерам, потому что «повторение — мать учения». Я регулярно спрашиваю наших разработчиков, что полезного они вынесли из последних приёмов, в которых они участвовали (именно приём, а не сдача). В ответ слышу, что польза в том, что это помогает систематизировать свои знания: темы осознаются гораздо глубже и запоминаются надолго. После таких разговоров мне часто представляется новый формат экзаменов в универе, где не только преподаватель принимает у студентов билеты, но и студенты принимают их у преподавателя 😄

В среднем, переход на следующий грейд занимает несколько месяцев. Например, наш рекорд — 10 месяцев до middle–1 с нуля, и 4 месяца до junior-3. Когда разработчик сдаёт грейд, мы объявляем об этом всей команде. Это маленький праздник и повод для гордости, особенно, если грейд был сдан быстро.

Онбординг

Ещё до онбординга мы оцениваем кандидатов по карте и отправляем ссылку, чтобы они понимали, что требуется знать для трудоустройства. Это удобно:

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

Конечно, мы не требуем от новых разработчиков 100% знаний по всему грейду (который им присвоен). Пробелы заполняются в процессе адаптации и развития по карте.

Адаптация

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

Это создаёт атмосферу дружественного саморазвития, провоцирует разговоры в курилках и на обеде. Джуны у нас быстро кооперируются, обсуждают какие-то темы вместе, приходят и спрашивают у миддлов как они сдавали. Бывает, что бомбят на какие-то темы, но это здорово!

Преимущества и недостатки

Начнём с минусов.

Минусы

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

Примечание. У нас есть ещё проблема найма мидлов со стороны, потому что требования выше.

Распределение по грейдам субъективно. Это будет в любой карте, просто потому что в каждой компании свой стек. С этим придётся смириться.

Мало практики. Многие темы тяжело изучать, потому что мало практики. Но мы уже работаем над этим — экспериментируем с возможными решениями.

Плюсы

Для нас их больше.

Постоянные обновления. На GitHub карта постоянно развивается: она открыта, в неё можно добавлять дополнения. Когда разработчики изучают или сдают тему, они также могут через issue внести предложение или дополнительные вопросы. Карта дополняется также после интервью, на которых возникают «удачные» вопросы.

Культура. В нашей компании она основана на желании развиваться. Карта — маркёр желания.

Гибкость. В карте нет жестких правил, например, по срокам сдачи грейдов или количеству попыток. Но есть пара нюансов.

Ограничение есть для ребят, что выпускаются после нашей программы обучения. После учёбы они получают уровень junior-1 по нашей карте. Если они попадают к нам в команду, то мы обговариваем, что они должны в течение трёх месяцев (испытательный срок) обязательно сдать на junior-2.

Такое же ограничение действует, если мы берём на работу человека с «авансом». Например, даём ему уровень junior-3 с не очень уверенными знаниями. Также в течение испытательного он закрывает все пробелы по своим знаниям.

Подробности. Карта даёт довольно полное понимание о важных в нашей команде вещах, например, о разных нюансах TypeScript у фронтендеров или о расширениях компилятора Haskell у бэкендеров. Благодаря этому у нас есть собственная уверенность в силах разработчиков, сдавших грейды, ведь они подробно описаны.

Структура. Даёт чёткое определение тех знаний и компетенций, которые мы ждём от своей команды на разных уровнях.

Рекрутинг. Карта — дополнительный инструмент рекрутинга. Когда к нам приходят новые ребята (в том числе из нашей программы обучения), мы можем им сразу выдать максимально простой и понятный инструмент.

Для чего карта не подходит

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

Такая «страховка» сформировала систему открытости и ответственности. Плохая сдача интервью не повлияет на карьеру разработчика, но и не повод пропускать всех с сырыми знаниями, а самому человеку так и сидеть с ними.

Для замены One-on-One, Performance review или индивидуальных планов развития. Карта дополняет эти инструменты, как часть комплексной системы. Например, один из наших первых сотрудников, что перешел на удалёнку, «пинал» карту последние годы, но допинать до чего-то существенного не смог. Мы провели с ним One-on-One (также с одним из первых) и это помогло. Мы смогли обсудить проблемы, найти страхи и убедить просто начать.

Для чего подходит

Карта развития — это траектория, по которой нужно двигаться, чтобы стать круче.

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

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

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

Планы доработки инструмента

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

Перевести на английский. У нас есть планы выхода на интернациональный уровень аутсорса. Для этого мы уже кое-что делаем:

  • Формулируем (пытаемся) на английском вопросы от 2 Middle и выше.
  • Все новые вопросы в карте сразу пишем на английском.
  • Понемногу переводим старые темы на младших уровнях.

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

Текущая версия карты со всеми уровнями находится на GitHub в публичном доступе. Все изменения (вопросы, комментарии, дополнения) вносим через pull request или issue. Поэтому добавить своё дополнение может любой, даже джун.

Первый шаг к карте в вашей компании

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

Просто начните. Соберитесь с единомышленниками, найдите какие-то варианты карт, обсудите, и запустите самое простое MVP. Карту можно оформлять в любом документе, например, первую версию мы запустили на Rizzoma. Это некий аналог Google Docs — древовидный документ, который могут редактировать несколько человек: добавлять комментарии, исправления, ссылки.

Запустите первое демо. На MVP в Rizzoma мы потратили 50 часов: 2 уровня Junior (low и high) и 3 уровня Middle, 50 вопросов на каждый уровень. Сейчас в карту вложено уже 750 человеко-часов и только на уровне Junior больше 500 вопросов, довольно подробных. 50 часов — небольшая цена, чтобы понять, будет ли интересна команде идея карты развития, и будет ли она полезна вообще.

Запланируйте фичи. Добавьте в карту возможности обратной связи и Peer-to-Peer обучения. Например, у нас это реализовано через интервью. Когда разработчики сами проверяют знания у других разработчиков, сами что-то объясняют, рассказывают, это прокачивает их скиллы снова и снова.

Карта развития — полезный инструмент, который может помочь сделать систему максимально справедливой и минимально субъективной. Помните, что при работе с людьми стоит склоняться к false positive системе — тогда цена ошибки будет стремиться к нулю.

{ "author_name": "MetaLamp", "author_type": "self", "tags": [], "comments": 10, "likes": 24, "favorites": 108, "is_advertisement": false, "subsite_label": "hr", "id": 212949, "is_wide": false, "is_ugc": true, "date": "Thu, 25 Feb 2021 18:00:57 +0300", "is_special": false }
0
10 комментариев
Популярные
По порядку
Написать комментарий...
5

>>Наш Junior примерно равен среднестатистическому Middle-разработчику в какой-нибудь продуктовой компании (не сочтите за хвастовство).

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

Ответить
7

Есть грешок, мы немного похвастались, да))
Но в целом, есть компании, которые готовы взять на позицию мидла человека с меньше чем 6 месяцами опыта, есть даже компании, которые берут на позицию мидла совсем свежих выпускников онлайн курсов. Буквально. Мы хотели сказать, что ориентируемся не на такие компании, а на те, у кого выстраданные годами высокие требования к разработчикам, кто сами много вкладываются в развитие разработчиков и помогают им расти. У нас в итоге есть довольно чёткая граница между мидлом и джуном. Граница эта всегда субъективная и точно её каждая компания для себя проводит, но мы вот установили такую и пока с годами только видим подтверждение этому: https://github.com/fullstack-development/developers-roadmap

Можете просто на нашу карту саму посмотреть по тому же фронтенду: там на всех трех джуниорских грейдах нет каких-то космических вопросов, там всё довольно приземлённое, про конкретные технологии, с которыми сталкиваешься на каждом первом или втором проекте. У нас даже Event Loop на middle-1 идёт. Ну а про действительно сложные концептуальные темы, вроде паттернов, SOLID или DDD, точно только там встречаются. Собственно в этом и отличие между джуниорами и мидлами, которое мы в компании установили: джуниор может себе позволить владеть только конкретными инструментами, мидл уже разбирается в более абстрактных темах о том, как этими инструментами грамотно пользоваться, не разломав текущую архитектуру :)
Но бежать за компаниями, которые называют мидлами тех, кто даже про всплытие событий не знают или не понимают зачем Promise.resolve нужен, мы не планируем.

Ответить
2

Идея с картой компетенций хорошая. Но вопросы немного обескураживают.

Во-первых, есть просто странные вопросы, вроде "В чем разница между понятиями "язык" и "препроцессор"?", совсем непонятно что на него отвечать, препроцессор это инструмент, который в том числе может понимать некий макроязык. Или например "Особенности JavaScript.Почему язык считается событийным и неблокирующим?" Язык не может быть неблокирующим, физически, у вас есть рантайм (браузер, нода, deno), есть операционная система и nonblocking i/o, причем тут язык?

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

Ответить
3

Да, вопросы у нас ещё неидеальны, к сожалению, с этим трудно не согласиться :) И пример про язык и препроцессор прямо в точку, у нас у самих уже пару раз были холивары по этому вопросу. Мы все осознаем что формулировка кривая, пока просто не дошли руки красиво сформулировать. Просто конкретная проблема была со многими джуниорами, что они путали эти понятия, ставили их на одну ступеньку абстрактности, вот мы таким вопросом для себя закрыли момент, чтобы ребята в этом разбирались поглубже и не обходили стороной.
Мы над картой регулярно работаем, как говорили в статье — первая версия была на коленке собрана за пару дней, и потом в течение нескольких лет мы постоянно её дорабатывали. Но как и с любым IT проектом, от легаси мы и тут не ушли полностью :) Иногда бывают такие костыли, сейчас мы их закрываем тем, что при подготовке у нас в чатиках джуниоры явно сами иногда спрашивают “этот вопрос вообще про что” и мы поясняем. И такие костыли понемногу убираем: можете заценить у нас ишью и пулл-реквесты, всё в открытом доступе, можно понять динамику развития и уровень холиваров по некоторым темам.

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

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

Да, более того, мы сейчас уже начали к этому идти, но пока что делаем только первые шаги. Джуниорские темы на фронтенде мы некоторые уже так побили, например, про тестирование. Сейчас это начинаем делать с бекендерскими темами по Haskell. Кстати про SOLID холивары в открытом доступе в ПРе, мы на год почти удовольствие растянули 😭

В общем спасибо за правки, ишью и ПР по их мотивам уже запущены: https://github.com/fullstack-development/developers-roadmap/issues/289 и https://github.com/fullstack-development/developers-roadmap/pull/290

Ответить
4

Как зачем?) Чтоб платить меньше, очевидно, зато «какая у нас классная карта развития», вот годик-два позанимаешься и станешь мидлом!

Ответить

Комментарий удален

3

идея хорошая, но  мы, в компании Haulmont, даем звания за результат а не за теор. знания . 

Наличие матрицы знаний и навыков а так же  наличие тренинг центра очень важно вне сомнения. Это позволяет сотрудникам быстрее расти и получать знания на предприятии.

ПС
Это как в спорте разряды (и тем более  звание МС)  даются только за результаты.  
 

Ответить
2

На самом деле мы сейчас экспериментируем и думаем над тем, чтобы конкретные результаты имели серьёзный вес, даже больший, чем знания, но пока ещё в процессе. Ждите статью через несколько месяцев :)

Ответить
3

Классно! Философию подхода разделяю. Думать о развитии коллег внутри компании - очень достойно.

Да и тренд очень хороший, я с ним встречался в одной компании, будучи в роли фронтенд-разработчика. Именно с картой развития.

А ещё во всей сфере я хотел бы видеть такой подход в поиске коллег. Осознанный, удобный и полезный.

Чтобы всегда давали достойный фидбек кандидатам, особенно новичкам. И чтобы это было нормой.

Чтобы вопросы, задачи и процесс интервью были обдуманные.

Да много есть пожеланий, остановлюсь здесь 😁

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

Оставлю ссылку здесь - https://meet2code.com/

Ответить
1

Зашибись :)
Ссылку на гитхаб в конце вставьте чтобы не скролить

Ответить
0

Зумеры переизобрели "Единый тарифно-квалификационный справочник" и отраслевые экзамены.

Ответить

Комментарии

null