


Совет «бери задачи сложнее» не всегда помогает вырасти: сложность может увеличиться, а самостоятельность остаться прежней. Для движения от Junior к Middle нужен более конкретный план. На Mentoring.digital разберём, как выбрать навык, потренировать его на работе и собрать основания для разговора о развитии. Гарантированного срока повышения здесь нет.
Сначала выясните ожидания команды. Что должен делать Middle в вашей роли: уточнять условия, вести небольшое изменение целиком, замечать зависимости или самостоятельно проверять результат? Название уровня без таких примеров мало помогает.
Если есть матрица компетенций, обсудите её на конкретных задачах. Если её нет, попросите руководителя описать работу, которую считают подходящей. Не нужно собирать универсальный перечень всех технологий из разных вакансий.
Отделите рост навыка от решения о должности. Даже заметный прогресс не означает автоматического повышения в любой организации. Важно понимать процесс оценки и то, какие подтверждения он использует.
Возьмите несколько недавних задач и отметьте, где требовалось больше всего сопровождения. Возможно, код вы пишете уверенно, но поздно замечаете неясные требования. Или решение готово, а проверки приходится придумывать коллеге.
Представим учебный пример: разработчик добавляет поиск в список заказов, но забывает согласовать поведение при пустом результате. Это вымышленная ситуация для плана развития, не оценка конкретного сотрудника.
В таком случае цель может звучать так: «Перед реализацией самостоятельно описывать основные состояния и вопросы к условию». Для проверки клиентской части подойдёт наставник по Frontend. Уточните, что хотите работать именно над выбранным пробелом.
Выберите посильную задачу, в которой можно проявить нужное действие. До начала договоритесь, что подготовите самостоятельно и на каком этапе получите обратную связь.
Это пример учебной договорённости, а не проверенная программа повышения. Для серверных задач содержание будет иным: например, ограничения входных данных и связанные операции. Его можно обсудить с Backend-ментором.
Сначала выясните смысл замечания. Если reviewer не понимает часть решения, подумайте, можно ли сделать понятнее сам код. Объяснение только в переписке не всегда помогает будущему читателю.
Если не согласны с предложением, обсудите ограничения и альтернативы. Не превращайте замечание к реализации в общую оценку своих способностей. Разговор должен помогать выбрать решение по техническим основаниям.
После правки попробуйте объяснить, почему она нужна и где ещё применим принцип. С наставником по Java можно разобрать такой пример в соответствующем стеке. Простое выполнение всех указаний не равно освоению навыка.
Выберите другую ситуацию, где нужен тот же принцип. Если теперь самостоятельно замечаете состояния, готовите вопросы и проверки, это наблюдаемый прогресс. Если затруднение повторилось, уточните причину вместо перехода к новому списку курсов.
Сохраняйте краткие записи без закрытых данных: исходная трудность, действие, обратная связь и результат повторения. Не добавляйте выдуманные показатели ускорения. Можно показать конкретное изменение поведения и границы самостоятельности.
Развитие не требует скрывать незнание. Более содержательная помощь начинается с понятного вопроса и собственных наблюдений, а не с попытки решить всё в одиночку любой ценой.
Сопоставьте собранные примеры с первоначальными ожиданиями. Какие действия стали самостоятельными? Где ещё нужно сопровождение? Какие задачи команда готова доверить дальше? На этой основе пересмотрите план с руководителем.
Если рассматриваете внешние вакансии, с ментором по собеседованиям можно подготовить рассказ о проделанной работе. Опирайтесь на факты, а не на обещание статуса. Полезный итог плана: понятная ответственность, которую вы уже можете принимать и проверять.