Как стать мидл программистом

Как перейти с джуниор позиции на мидл: личный опыт

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

Два года я работал в одной конторе на позиции джуна, но роста там особо не было. Надеялся, что скоро закончу магистратуру, и меня повысят до милда. Но этого не произошло. К слову, бакалавриат я закончил в СПбГУТ им. М.А. Бонч-Бруевича, факультет инфокоммуникационных сетей и систем, но знаний, которые можно непосредственно применять в современной продуктовой разработке, к сожалению, не получил. В программировании на Java я самоучка, и технический бэкграунд мне сильно в этом помог. Java изучал на практике, вникая в документацию и смотря ролики на ютубе.

Почему я ушел с предыдущей работы

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

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

Поиск новой работы

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

Собеседовался в EPAM и Luxoft. Эйчары максимально старались завлечь, рассказывая про крутые офисы, движуху внутри компании, ДМС и всякие “плюшки” в виде оплаты спорта и конференций. Но в итоге, так и не смогли ничего предложить по работе, потому что у меня не было опыта работы со Spring.

На первых собеседованиях я “набивал руку”, потому что общение с эйчарами было для меня в новинку. После каждого интервью я чувствовал себя все увереннее. Но основная проблема возникала на этапе тех. собеседования, где меня заваливали на каверзных теоретических вопросах, на которые я не мог четко ответить из-за слабой теоретической базы. Но даже после неудачных попыток, я выписывал все вопросы и задачи, с которыми не справился, и начинал заучивать. После 100500 собеседований на позицию джун+, мидл, результат был примерно одинаковый — готовы взять только на джуна с маленькой зп.

Новая работа

Сдаваться я не собирался, поэтому продолжал проходить собесы. Благо дистанционка, и можно было проходить хоть по 5 собеседований в день. И удача, после второй сессии тех. собеседования меня позвали сразу 2 компании — МТС и Цифровые Привычки.

Казалось бы, между МТС и неизвестной компанией выбор очевиден, но все оказалось не так просто. Цифровые Привычки к тому моменту успели выиграть несколько тендеров Сбера на 400 миллионов рублей и начали активно расти. Я думаю, все понимают, что вкатиться в айти компанию на стадии активного роста = получать достойную зп, так как из-за дефицита Java-разработчиков на рынке компания готова хорошо платить, когда у нее есть крупные проекты, на которые требуется больше сотрудников. Мое решение в пользу ЦП было также подкреплено бесплатным обучением по Java, которое в дальнейшем помогло в работе на проекте.

Чек-лист Middle Java Developer

Данный чек-лист основан на моем личном опыте в разработке, опыте прохождения технических собеседований и тех знаниях, которые я получил на обучении. В нем будут те ключевые навыки, которые помогли мне получить должность мидл разработчика. Условно разделю их на hard и soft skills.

Hard skills

Понимание технологического стека проекта, на который ты собеседуешься.
Нужно действительно разбираться в наборе инструментов, которые применяют в работе на проектах, а также важно четко ответить на теоретические вопросы о конкретном применении того или иного инструмента на тех. собеседовании. Например, в моем случае было важно знать JavaSE, JavaEE (JAX-RS, JAX-WS, JMS), Spring framework (Core), SQL, Maven, GIT, XML/XSD.

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

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

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

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

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

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

Soft skills

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

Умение работать в команде.
Этот навык сильно помогает, потому что как я писал выше, работать с чужим кодом не всегда бывает легко, и нужно быть готовым постоянно общаться с коллегами, задавать вопросы, а также самому давать разъяснения, если это нужно. Также здорово, если ты можешь донести свои мысли и идеи до команды так, чтобы их поняли все.

Способность оценить трудозатраты.
Этот навык поможет избежать невыполнимых обещаний, после которых тебе придется работать по 20 часов в день, чтобы сдать проект в срок, который ты сам озвучивал.

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

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

Также ниже прикрепляю ресурсы, которые помогли мне при подготовке к собеседованиям на Middle Java Developer.

Ресурсы для подготовки к собеседованию

Сайты, где можно найти самые часто задаваемые вопросы на собеседованиях:

Чаты в телеграмме, где можно обсудить разные темы с другими разработчиками и порешать задачи:

Разбор вопросов на интервью
Java задачи
Java задачи с собеседований
Docker
Spring Boot & Spring Data JPA (англоязычный чат)

Ютуб:

Тут можно посмотреть, как проходят интервью
Подборка лекций Евгения Борисова («Спринг-потрошитель») с конференций
Видеолекции по Spring

Где можно тренироваться решать задачи:

LeetCode
Codeforces
Тренировки по SQL запросам
Тренировки по Git запросам

/dev/energy

Сайт о том, как стать программистом и как с этим жить потом

Как развиваться Junior разработчику? Карьерный путь в IT

Меня не может не радовать то, как сильно вырос онлайн в разделе Как стать программистом, поэтому я решил написать свежую статью именно в этот раздел моего блога, чтобы закрепить успех. Поговорим о том, как происходит рост от Junior ввысь/вглубь мира IT.

Абсолютное большинство приходящих в сферу IT соискателей не стремятся оставаться на позиции младшего разработчика всю свою жизнь. Их цель — как минимум вырасти до стабильного, сильного разработчика уровня middle/senior. А кто-то пойдёт выше. И именно этот процесс хотелось бы обсудить в рамках статьи. Я постараюсь приводить примеры, основанные на своём опыте и опыте моих студентов.

Trainee

В современной индустрии IT с её перенасыщенным рынком понимание между Стажёром (Trainee) и Младшим программистом (Junior) смазалось. И многи часто путают эти два понятия, что неправильно.

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

Чаще всего после курсов «с нуля» выпускники становятся именно стажёрами, так как у них по сути нет коммерческого опыта. В лучшем случае они могут стать Junior-ами (но об этом ниже).

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

Чаще всего стажировки либо не оплачиваются вовсе (что, кстати, не совсем согласуется с ТК РФ), либо оплачиваются по минимальной границе. Но в текущей ситуации на рынке я бы рекомендовал обращать внимание на любые стажировки крупных компаний вне зависимости от финансовых условий — внимание стоит уделять условиям последующего найма и того, какие преференции даёт стажировка для кандидата.

В роли стажёра Вы

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

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

Обязательно узнайте при поступлении на стажировку, как описываются и фиксируются условия успешного её завершения, а также какие знания и навыки Вы получите.

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

Junior

В условиях насыщенного рынка получение позиции Junior — это уже весомый успех. Он говорит о том, что в общей массе новичков Вы смогли выделиться. Эту картину надо не только сохранить, но и улучшить. В течение испытательного срока, который в нашей необъятной Родине длится обычно три месяца, Вам нужно будет сосредоточиться на следующих вещах (кстати, как и в позиции Trainee)

1. Изучение процесса разработки в команде. Много общайтесь со старшими коллегами и узнавайте, как принято писать код, тестировать и отлаживать его, а также — как доставлять его на Production. Здесь Вы не только узнаете, как не попасть под раздачу во время Code Review, но и обнаружите множество новых для себя вещей, с которыми Вы ещё не успели познакомиться. Не переживайте — это нормально. Скорее всего, Вам предстоит узнать о таких вещах, как Git-Flow, Docker, CI, DI и прочие модные слова. Спросите у своих наставников о том, что лучше почитать/посмотреть на интересующую Вас тему, могут ли они рассказать Вам об этих вещах.
2. Изучение нового и неизвестного. Узнать слова — только начало. Нужно изучать. Не бросайтесь на всё подряд. У Вас быстро сформируется список «пробелов». Приоритезируйте его вместе с коллегами и идите по шагам, убирая пункт за пунктом тогда, когда станете разбираться в них и применять на практике.
3. Делайте больше. Додумывайте. Как бы ни хотелось надеяться на то, что ТЗ будут идеальными, а заказчики — лояльными, всегда и в каждой задаче будет оставаться место для небольшого подвига. Как говорил Колосс из вселенной Marvel: «Только несколько мгновений в жизни решают, герой ты или нет». Также и в задачах — добавление некоего небольшого, но полезного функционала увеличит ценность продукта и поднимет Вас в глазах пользователей.

Ориентируйтесь на ценность, а не на код. Да-да, код сам по себе никому не нужен и не стоит ровно ничего. Он полезен тогда и только тогда, когда логика, следующая ему, создаёт функциональную ценность для пользователей. Поэтому думайте в первую очередь ценностями пользователей, как бы ни хотелось в первую очередь сделать красивую архитектуру и создать ещё пару тысяч классов. Это не отменяет качества кода, но делает его нужным, а не «опять айтишники обновления выкатили :(«.
Общайтесь. Именно из общения Вы узнаете, что представляет ценность. С кем это обсуждать? С владельцами продуктов (Product owners), аналитиками, конечными пользователями. Именно они расскажут о том, «что болит», и дадут Вам пищу для роста и размышлений.
Пишите хороший код. Я специально употребил здесь максимально пространную фразу. В каждой команде свои стандарты кода, поэтому понятие «хороший код» будет варьироваться от команды к команде. Поэтому спрашивайте, общайтесь и учитесь. Именно этого от Вас ждут как от Junior-разработчика.

Моя практика показывает, что в позиции Junior специалист обычно растёт от полугода до года. Конечно, этот срок может меняться в разумных рамках, но если после года работы Вы всё ещё не чувствуете себя «в своей тарелке», стоит задуматься о качестве Вашего роста. За это время в процессе активной работы сотрудник не менее активно растёт, начинает изучать фундаментальные понятия в программировании, такие как алгоритмы, оценки сложности, обеспечение работы под высокими нагрузками, устройство выбранного языка программирования и прочее. К концу этого периода уже можно смотреть в сторону позиции Middle.

Если Вы решили изучать язык PHP, то можете взять за основу мой курс для самостоятельного изучения, который найдёте по ссылкам ниже. Он совершенно бесплатный и создан для того, чтобы помочь сделать первые шаги!

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

Как понять, что я готов к позиции Middle?

Не ждите, что Ваш шеф радостно ворвётся в Ваш open-space с тортом и шампанским и поздравит с повышением. Конечно, многие серьёзные компании проводят one-2-one встречи, следят за ростом сотрудников, но зачастую многие грешат тем, что исходят из принципа достаточности: человек работает, вот и славно. Зачем платить больше?

Если Ваш руководитель не общается с Вами на тему роста, то нужно активно рефлексировать и анализировать свои навыки. Ответьте себе на вопросы:

Сколько задач я довёл до Production за последние 3 месяца?
Какова их ценность?
Сколько багов было в них? Почему произошли эти баги?
Какие были нарекания к продукту, который я выпускал?
Сколько задач релизят старшие коллеги? (Этот вопрос совершенно нормально задать самим коллегам, чтобы понимать уровень собственной производительности, если не окажется доступа к статистике таск-трекера команды)

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

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

В самом хорошем случае в компании есть практика one-2-one встреч. Это практика, при которой руководитель встречается с подчиненными один на один в закрытом формате и обсуждает все вопросы, связанные с рабочим процессом, без купюр. Оба могут говорить о том, что беспокоит, что радует, задавать вопросы. В таком случае рост обычно происходит гораздо проще и естественнее, так как на встрече всегда можно

Узнать, какие знания надо подтянуть?
Попросить дать фидбэк по работе
Обозначить желание расти и обсудить условия роста
Обговорить сроки роста, что немаловажно, если Вы не хотите питаться «завтраками»

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

Вот я Middle. Что дальше?

Как ни странно, дальше рост очень похож за тем лишь исключением, что качественно меняются набираемые знания. Нужно уделять больше времени смежным системам (таким как ELK-стек, Docker, Kubernetes, кластеризация и скалирование), пониманию построения архитектур. Стоит написать что-то своё прямо с нуля, без фреймворков. Вне работы, но это будет крайне полезно для понимания принципов работы выбранного стека.

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

Дальнейший рост довольно интересен. За позицией Senior открывается несколько путей развития:

Технический. Вы продолжаете прокачивать технические навыки (hard skills). В таком случае Вы обычно вырастаете до уровня Architect или Technical Leader. Вторая позиция подразумевает большего общения с людьми, чем первая, поэтому выбирать Вам, исходя из того, насколько хочется активного взаимодействия с окружающими.
Организационный. Часть разработчиков с ростом чувствуют свою тягу к построению процессов и уходят в менеджмент. Так, например, крайне востребованы Scrum мастера и Agile коучи, которых довольно мало на рынке. Поэтому люди с подобными знаниями и техническим бэкграундом будут очень сильно востребованы на рынке.
Менеджерский. И снова про организацию процессов, но уже с точки зрения роста в чистый классический менеджмент. Такие Senior-ы обычно вырастают в Team Leader-ов, затем в Head of Development, а потом в CTO (Технический директор). Здесь нужны очень хорошие навыки организатора, желание строить процессы и отстутсвие боязни общения с бизнесом, коего будет очень и очень много.

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

Кстати, про рост в роли Team Leader-а есть отличное выступление с конференции, которое Вы можете посмотреть ниже

Резюме aka TL;DR

Учитесь и систематизируйте знания
Делайте это постоянно
Чётко понимайте, зачем хотите расти
Делайте чуточку больше и лучше, чем от Вас ждут
Понимайте сроки и условия роста

Надеюсь, что мои скромные рекомендации будут для Вас полезны!

Как джуну перейти на мидл-позицию и оценить свою квалификацию

Ура, вы устроились на первую работу в IT. Но чтобы зарплата выросла до 300K в наносекунду, надо вначале перейти из джунов в мидлы.

Иллюстрация: Artroomstudio / Freepik / Annie для Skillbox Media

Редакция «Код» Skillbox Media

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

Максим Калик

iOS Engineer в Triumph Lab.

Ссылки

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

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

Поэтому есть несколько распространённых вопросов, по которым чаще всего оценивают претендента на повышение:

Сложность задач. Какие задачи решает джуниор-разработчик? Создаёт ли новую функциональность?
Качество кода. Как часто после код-ревью или тестирования джуну приходится дорабатывать решение?
Скорость выполнения. Какое количество задач джун закрывает за спринт?
Бизнес-модель. Может ли специалист ответить на вопросы развития и цели бизнеса?
Коммуникация. Принимает ли участие в обсуждении проблем с коллегами и предлагает ли варианты их решения?

Также работодателю важно понять ещё несколько важных нюансов:

Продолжает ли будущий мидл-специалист учиться.
Есть ли у него стремление сделать больше, чем от него ждут прямо сейчас.
Как много джун задаёт вопросов (если относительно немного, значит, джуниор уже что-то понимает в продукте и процессах). Хотя лично я считаю, что вопросы у разработчика должны быть всегда. Questions are good.

В момент промоушена есть достаточно полезная практика — письменно проанализировать и дать ответы на три вопроса:

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

Вообще, вы в любой момент можете пройтись по этим критериям и понять, какой у вас уровень. Я рекомендую начать оценивать себя ещё в первый месяц работы. Если, скажем, через месяц вы зафиксируете рост по первому и третьему пунктам — это уже хороший признак.

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

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

Читайте также:

Топ-8 книг для начинающих разработчиков
Тест: угадайте, где эзотерические языки программирования, а где — нет
Фронтенд или бэкенд — в чём различия и что выбрать

Что прокачать джуниор разработчику, чтобы стать мидлом за год

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

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

Роман Моисеев, менеджер продукта на программе «Мидл Python-разработчик» в Яндекс.Практикуме, рассказывает, над чем стоит работать, если вы джуниор, который хочет стать мидлом.

Роман Моисеев
менеджер продукта на программе «Мидл Python-разработчик» в Яндекс.Практикуме

Четыре грейда джуниор-разработчика

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

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

Первый — стажёр. Это ещё не полноценный джуниор-разработчик, скорее его MVP. На этом уровне человек знает основы языка программирования, его не нужно учить синтаксису. Однако применять этот язык программирования для решения реальных задач он ещё не умеет. Чтобы дать ему задачу в работу, её нужно расписать по шагам: «сделай A, B и С, возьми такую технологию и используй вот эту вот функцию».

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

Второй — джун-новичок. Первая стадия развития джуна: первый оффер на фултайм, первый рабочий месяц и первые боевые задачи. Такой разработчик обладает достаточным набором теоретических (академических) знаний, чтобы делать простые задачи без супердетального описания. Он знает, как работать с документацией и найти в ней ответ на свой вопрос.

Тем не менее процесс коммерческой разработки он знает скорее теоретически, поэтому ошибается на разных этапах написания кода. Он часто приходит к старшим коллегам и говорит: «У меня что-то поломалось. Не могу это сделать. Помоги!» И это нормально.

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

Третий — средний джун. Уже прошёл испытательный срок, освоился в компании и процессах командной разработки. Например, знает, какие agile-ритуалы используют в команде и почему. Теперь ему можно давать задачу и не контролировать её выполнение в рамках одного рабочего дня.

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

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

В качестве отправной точки для роста за год я буду рассматривать джуна-новичка. По двум причинам:

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

Эволюция сложности задач

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

Разогреть в сковороде немного подсолнечного масла.
Разбить и бросить в неё два яйца.
Немного посолить.
Подождать 3 минуты.
Яичница готова!

Если вдруг стажёр разобьёт яйца, и скорлупа попадёт на сковородку, сениор объяснит, что так делать нельзя.

По мере роста уровня разработчика растёт уровень самостоятельности. Мидлу уже достаточно сказать: «Нужно сделать яичницу». Он уточнит, какой вид яичницы нужен, например, нужно ли добавить сыр и помидоры, найдёт все ингредиенты и приготовит вкусный завтрак.

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

Кто такой мидл

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

Чисто сениорских задач в разработке мало. Большинство компаний решает достаточно стандартные задачи. И вот с этими задачами мидл должен уметь справляться самостоятельно. Для этого нужен достаточный опыт и накопленный багаж совершённых ошибок.

Hard skills мидла

Перед тем, как перейти непосредственно к списку требований, обозначу три важные вещи:

Здесь не будет конкретных технологий, которые нужно изучить. Во-первых, требования к технологиям в разных компаниях очень сильно отличаются. Во-вторых, если главный критерий мидл разработчика — «самостоятельность в решении своих задач», полезнее всего выделить фундаментальные вещи, которые помогут к этой самостоятельности прийти.
Это не список «сделай 10 конкретных шагов и стань мидлом». К сожалению, такого волшебного пути нет. У каждого разработчика он свой. Советую читать требования ниже так: «Чем больше галочек я набрал, тем более вероятно, что я мидл».
Вы можете переработать этот список в свой чек-лист действий для роста до позиции мидла. Для этого вам понадобятся навыки приоритизации и декомпозиции цели. Небольшой спойлер: это и есть важные навыки мидл-разработчика.

Какие качества ждут от мидл-разработчика

Понимание используемых технологий

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

16 вопросов мидлу: что должен знать Middle-разработчик

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

Почему подходит для решения поставленной задачи?
Как работают индексы в ?
Почему они работают именно так?

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

Прохождение и проведение code-review

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

Как влюбить в себя своего код-ревьюера: правила подготовки к code review

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

Проведение код-ревью, напротив, — во многом техническая задача. Умение разобраться в чужом коде распадается на два навыка: понять общую структуру программы и увидеть места, где решение можно сделать более оптимальным, лаконичным и красивым. А ещё код-ревью — это отличная возможность поделиться своим опытом.

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

Умение декомпозировать задачи

У начинающих разработчиков часто есть желание начать писать код сразу, как они получат задачу. Мидл должен сначала остановиться и подумать, как он будет выполнять задачу: разбить её на несколько последовательных этапов и ответить на вопрос, почему он сделал именно такой план. Обычно на написание кода у мидла уходит больше времени, чем у джуна.

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

Насмотренность

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

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

Понимание алгоритмов и области их применения

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

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

Умение писать скучный код

Задумайтесь, насколько код, который вы пишете, будет понятен человеку, который видит его впервые. Помогут ли ему ваши нестандартные решения? Мидл всегда выберет простое решение, вместо того чтобы выпендриться.

Soft skills мидла

Что такое мягкие навыки в разработке? Самый простой ответ: все навыки, которые нужны в работе, но не связаны напрямую с написанием кода. Опасность такой формулировки в том, что можно подумать, будто софты — это что-то вторичное и не очень важное. На самом деле это не так.

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

Какие мягкие навыки ждут от мидл-разработчика

Самостоятельность

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

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

Умение видеть проблему бизнеса в технической задаче

Мидл должен понимать, что его главная задача ― не просто писать код. Разработчику платят за техническое решение бизнес-задачи.

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

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

Увлечённость разработкой

Покажите будущему тимлиду, что разработка вас драйвит. Объясните, почему вы делали проекты и задачи, которые записаны у вас в резюме. Даже тривиальные и обыденные вещи можно раскрыть через призму выводов и полученного опыта, а не с позиции «я просто писал код на Django на последней работе».

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

Саммари и заключение

Единого понимания грейдов разработчиков в индустрии нет, и это нормально: разные команды выдвигают разные требования в зависимости от своих задач.
Главный критерий роста разработчика — ответственность и сложность задач, которые он может решить самостоятельно.
Мидл должен быть самостоятельным разработчиком и решать большинство падающих на него задач без помощи старших разработчиков.
Фундаментальные навыки вроде умения разобраться с новым инструментом часто важнее, чем опыт работы с конкретной технологией.
Сейчас век командной разработки, поэтому софты не менее важны, чем харды.

Следите за новыми постами по любимым темам

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