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

Технические навыки

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

Базы данных 

Сложно представить бэкенд-разработчика без знания баз данных. Но какие именно нужны и насколько глубоко в них погружаться?

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

Кроме этого есть нереляционные базы данных. Нужно понимать, чем они отличаются от реляционных и друг от друга. Потому что легко перейти с Postgres на ClickHouse не получится. Нужно стремиться к пониманию — для чего они такие разнообразные, почему их так много.

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

«От Middle Python Developer ожидают уверенных знаний одной из баз данных изнутри — принципы, по которым построена, почему именно так мы взаимодействуем с ней в Python.

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

Ещё мидл должен уметь проектировать базы данных, то есть понимать, как в конкретной задаче нужно сложить данные в базу. Знать, что кроме SQL баз данных существуют ещё NoSQL, как плюс — иметь опыт работы с одной из них».

«Бэкендеру мидлу важно уметь работать с реляционными и нереляционными базами данных — в зависимости от того, какие применяются в компании. Реляционные очень важны и используются чаще. Если человек учился в университете, там ему давали специальный курс о них. Если не учился, можно самостоятельно пройти любой курс по базам данных, например SQL Academy, это будет один из лучших потраченных месяцев для развития карьеры».

Фреймворки и библиотеки

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

«От Middle Python Developer требуют знания принципов асинхронного программирования и одного из фреймворков — Django или FastAPI. Особенного упора на библиотеки нет, они зависят от места работы. Хорошо, когда мидл-разработчик знает два любых фреймворка на Python, а ещё лучше, если один из них на другом языке. Это даёт ему насмотренность, которой нет у джуна. Из фреймворков сейчас популярны FastAPI и Django, реже Sanic и Flask. Из библиотек — pydantic, которая помогает переводить данные в типизированные Python-объекты. Мы используем её на курсе, в ней много полезного, но чаще всего её применяют для сериализации данных.

«Для Python популярны Django, FastAPI. На практике обычно во всех компаниях этот стек сужают. Не бывает такого, что один микросервис работает на Django, второй на Flask, а третий на FastAPI. Всё стараются подвести под общий знаменатель. Если вы можете Django использовать с PostgreSQL, самостоятельно править миграции и деплоить Django-проект на ваш сервер, это уже широкие знания. Они не сводятся к знакомству с двумя фреймворками по отдельности.

Не обязательно бросаться изучать всё. Я программировал и на Python, и на C++, везде своя атмосфера. Если речь идёт о повышении уровня от стажера до джуниора, нужно минимально стремиться всё охватить. Лучше выбрать один стек и сделать что-то практичное на нём.

Если вы растёте от джуниора до мидла, то можете справиться с нестандартными задачами в этом фреймворке. Например, не просто решить задачу по шаблону, но и настроить фоновую обработку задач или соединить с Kafka.

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

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

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

Работа с Git 

Мидлу предстоит самостоятельно обслуживать репозиторий проекта, а делать это нужно с помощью Git. 

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

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

Алгоритмы

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

«Знание алгоритмов отличает мидла от джуна. Бывают задачи, в которых без алгоритмов не обойтись. А бывают проекты, где алгоритмическая сложность не так сильна — например, в интерфейсе, если это UI, фронтенд.

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

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

Инструменты разработки и инженерные практики

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

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

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

Также стоит освоить утилиты для дебаггинга, точки остановок. Часто люди, даже те, кто занимается программированием несколько лет, ими не пользуются. Они просто пишут: «print» или запускают проект и смотрят, что получилось».

«Ещё один важный технический навык: понимать принципы контейнеризации приложений. Почти везде сейчас применяются облачные технологии, поэтому надо уметь работать с Docker. Понимать, что такое service/deployment/pod в рамках Kubernetes. Но базовые концепции сводятся к изложенным в Twelve-Factor App».

Качество кода

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

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

Есть определённые правила, которых нужно придерживаться:

• Название переменной должно быть именем существительным. 

• Название переменной должно пояснять, что в ней находится. Запрещены названия из одной буквы, а также: temp, val, var, result и все подобные.

• Константа пишется большими буквами.

• Название функции — глагол в повелительном наклонении. 

• Если функция возвращает True/False, она должна начинаться со слов is, can, does. Например, is_black(color), does_fail(process).

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

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

Понимание бизнес-потребностей

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

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

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

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

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

Хочу переписать систему. А зачем? Она стала слишком сложной, надо упростить. А зачем? Чтобы легче поддерживать. А зачем? Можно будет её быстрее развивать. А зачем? Чтобы добавить функционал, который просят пользователи. А зачем? Чтобы они были довольны и принесли больше денег».

Знание английского языка

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

«Очень часто документация и ответы на вопросы в интернете, на Stack Overflow не переведены на русский язык. Если искать на английском, можно найти ощутимо больше полезной информации.

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

Гибкие навыки

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

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

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

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

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

Другой важный навык по-английски называется problem solving. Это значит — быть готовым к решению неожиданных проблем. Всё работало и вдруг упало, сломалось. Нужно решить вопрос, с которым ещё не сталкивались. Мидл не может поднять лапки и сказать: «Извините, я в этом не разбираюсь». Необходимо хотя бы поучаствовать в решении проблемы».

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

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

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

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

Хорошая практика, когда человек пытается поставить себя на место того, кому хочет задать вопрос. Допустим, джун не может работать, потому что у него не настроено окружение разработчика. Перед тем как спросить, он пытается понять: как этот человек может ответить на этот вопрос? Вполне возможно, что старший коллега тоже не помнит, у него может быть другое окружение, или он сам настраивал его 10 лет назад. Какие запросы он будет искать в гугле или внутренней вики компании? А может, сразу самому такое же поискать? Так и вопрос может отпасть. А могут появиться новые вопросы, на которые уже ответы не получается найти. Тогда уже надо спрашивать, причём с конкретным списком шагов: что попробовал, что уже получилось, а что нет.

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

Умение общаться — объяснять и спрашивать 

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

«От джуна мы ожидаем, что он будет с горящими глазами слушать и слышать, пытаться разобраться и говорить о проблемах, а не замалчивать их и уходить в себя. Мидла же видим полноценным игроком в команде. Он умеет аргументированно спорить, имеет мужество настоять на своём там, где это нужно, и не будет продолжать спор, если о чём-то уже договорились.

Здорово, когда разработчик общается не токсично и умеет находить общий язык, причём не только с программистами, но и с коллегами на других ролях: product owner, скрам-мастер, проджект-менеджер. Способен взаимодействовать с ними напрямую, когда это необходимо, а не через тимлида и других разработчиков. А ещё понимает, как сообщить о технических проблемах, формулирует свои мысли понятно и точно, не слишком вдаваясь в конкретику».

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

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

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

Новички до сих пор себя чувствуют как в университете, когда им оставляют комментарии на ревью, — будто это преподаватель поставил оценку. Если комментариев много, значит, получили тройку. Они расстраиваются и начинают отстаивать свой код: «Нет, так тоже можно было сделать. Почему вы мне написали 10 комментариев? Я книжку прочитал, такой вариант тоже работает».

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

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

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

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

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

Чем отличаются грейды в России и за рубежом

Требования к мидлам в российских и западных компаниях кардинально не отличаются — скорее различия будут зависеть от специфики компании и её стека.

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

Если сравнивать систему грейдов в России и за рубежом, стек технологий будет отличаться. Например, Python используется в США фулстек-разработчиками. А в Европе — для решения ML-задач. Есть отличия по фреймворкам, библиотекам, используемым базам данных.

В России в сопоставимых по размеру компаниях требования к грейду такие же, как в Европе и США, или даже чуть выше. На собеседованиях мы спрашиваем и джунов, и мидлов, как писать простые вещи на Python. Для позиции мидла обычно есть блок про алгоритмы. Иногда дают возможность показать знание алгоритмов в какой-то другой секции. Ещё наниматели проверяют знание баз данных и индексов: и SQL, и NoSQL баз данных. Опыт работы с очередями — дополнительный плюс. Есть интересная корреляция: скорее всего, разработчик не будет хорошо знать SQL, если не интересуется другими NoSQL базами данных.

Кроме того, есть систем дизайн интервью. Не обязательно быть суперкрутым архитектором, надо постараться задать все нужные вопросы. Если задача продуктовая, например «спроектируй сокращатель ссылок», на этом интервью нужно ограничить эту задачу и добиться того, чтобы получилось решение. От кандидата не ожидают, что он покажет себя архитектором решений и спроектирует дизайн приложения, которое встроится в общую систему. Достаточно подумать о других частях системы, а сам модуль спроектировать на хорошем уровне».

Как стать мидлом

Повысить грейд можно внутри компании или пройдя интервью на вакансию мидл-разработчика у нового работодателя. Получить нужную практику можно на своей работе или с помощью пет-проектов и участия в Open Source. 

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

А если вы ещё не знаете, как должен работать мидл, нужно это изучить: посмотреть видео с разбором собеседований и понять, почему отвечают именно так. В разных компаниях вопросы различаются. Например, у Amazon есть 14 leadership principles, и там очень любят про них спрашивать. Если хотите попасть в эту компанию, их надо изучить. Можно посмотреть публичные интервью в желаемую компанию или в похожие на неё по проектам и стеку, почитать статьи об опыте собеседований других разработчиков.

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

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

Хорошо, если работа, где можно расти, уже есть. А если нет? Часто рекомендуют делать свои проекты и выкладывать на GitHub. Но я сомневаюсь, что это идеальный способ. Он не даст получить опыт работы в команде, код ревью и общения, только опыт разработки.

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

Лучше присоединиться к опенсорс-проектам. На GitHub можно найти интересные проекты и зайти в раздел Issues — запросы. Чтобы присоединиться к проекту, смотрим, какие там есть проблемы, и пытаемся их решить в pull request. Это не всегда сложно, иногда нужно просто исправить документацию или починить небольшой баг.

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

Будет большой соблазн посмотреть на список Issues и решить, что ничего не получится. Но нужно себя перебороть, ведь на работе тоже будет непонятно, но делать её придётся.

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

«Я советую всем бэкендерам читать книги Роберта Мартина «Чистый код»,«Чистая архитектура», а про гибкие навыки — «Идеальный программист».

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

Полезно читать материалы конференций по своему стеку. Сильно помогает расширить навыки участие в контестах, решение задач и головоломок. Так вы выходите за пределы привычного набора задач. Ведь устроившись джуном, часто приходится на Django дописывать контроллеры и модели. В результате Python представляется однобоко. Если попасть в соседний проект, где работают с Data Science, Python будет выглядеть совсем иначе: цифры, модели, запросы непонятно куда — легко потеряться. Привычка решать задачки и знать основы языка поможет в таких ситуациях.

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

Как мы определяем, мидл этот соискатель или джун? Смотрим на гибкие навыки. А ещё у нас есть набор задач по ООП. Если человек много с этой технологией работал — он мидл, мидл плюс или синьор, и задачи щёлкаются как орешки за 10—15 минут. Если он не помнит, но при этом размышляет вслух, это плюс. Иногда бывает, что человек считает, что можно придумать ответы на ходу. Но это минус: хочется просто услышать честный ответ, что вы не знаете или забыли.

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

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

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

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

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

Пет-проекты могут помочь научиться аналитической деятельности. Даже если пока у продукта нет пользователей, разработчик сам становится тем, кто всё придумывает. И в ответ на свои требования пытается установить ограничения. Поэтому рекомендую делать пет-проекты, близкие к сфере, куда хочется пойти работать. Устроиться на работу не поможет создание технической библиотеки, которая нужна только вам. Лучше придумать продукт, который будет чем-то напоминать реальные ????

Заключение

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

Что предпринять, чтоб лучше освоить технологии и стать мидлом:

• Читать книги про инструменты, где используется много технологий/алгоритмов — например, про базы данных. 

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

• Подготовиться к систем дизайн интервью — для этого прочесть  «Высоконагруженные приложения. Программирование, масштабирование, поддержка» Мартина Клеппмана. Также можем  порекомендовать книги и блог Мартина Фаулера. И Twelve-Factor App. Другие источники могут быть взаимоисключающими или не такими конкретными, как эти.

• Подготовиться к собеседованию на позицию Python-разработчика, прочитав ченджлоги этого языка. 

• Следить за комьюнити Python. Довольно частый вопрос на интервью: «Что появилось в новой версии Python?» В логах много информации — часть понятна и джунам, часть — лишь опытным разработчикам, и часть — только создателям языка ???? Судя по тому, как соискатель отвечает на этот вопрос, можно понять его уровень.

• Практиковаться! Учитесь решать любой вопрос самостоятельно.