Как-то здесь написали, что пет-проекты — это всё, что нужно, чтобы стать мидлом. В реальности всё чуть сложнее, поэтому пришлось встать с дивана и написать этот пост. Мидл действительно должен знать и уметь больше, чем джун. Конкретного критерия при этом нет, в одной компании ваши знания и умение работать с React будут достаточными для мидл-уровня, в другой их оценят на уровень джуна. В любом случае это самая простая часть, которая может в немалой степени быть прокачана своими проектами. Но есть другая сторона, которая намного более важная, так как прокачать ее самостоятельно не получится. Сюда входят: >> Риски и ошибки, связанные с обслуживанием приложения, которым пользуются в реальном времени Пет-проекты не несут никаких рисков. Упал сайт? Просто перезапустили. Случайно стерли базу данных? Ничего страшного. Нужно обновиться? Остановили сайт. Всё это невозможно в реальной среде, где есть настоящие пользователи. Остановка сервиса может повлечь за собой потери миллионов, уничтожение инфраструктуры — потери всего бизнеса. Здесь нужно думать о бэкапах, о том, как новые изменения отразятся на старых пользователях. Помимо прочего, реальные сервисы — это вопросы, связанные с безопасностью, нагрузкой, масштабированием, отказоустойчивостью, логами, ошибками в продакшене. Представьте себе ситуацию, пользователь наткнулся на серьезный баг, который приводит к появлению страницы 500. Как вы об этом узнаете? В этот момент сразу можно понять, новичок перед вами или нет, так как новичок даже не задумывался над такими вопросами. Опытный разработчик знает о том, как отслеживают ошибки, и команда узнает об этом через системы мониторинга и алертинга. Как говорится: «Не ронял прод, не мидл». >> Процессы разработки. Сюда входит всё, начиная от того, как совместно работать в git до выкатки в продакшен. В реальной разработке обязательно присутствует процесс непрерывной интеграции, этап тестирования на стейджинге. Сам процесс выкладки сайта на продакшен представляет из себя целую историю, которую вот так на пет-проекте не реализуешь. Про git стоит сказать отдельно. Для собеседующих это один из самых простых способов понять, насколько программист в теме. Умение с закрытыми глазами оперировать ветками, черрипикать и выполнять другие задачи в гите очень сильно коррелирует с его продакшен-опытом. В разных компаниях уровень этих процессов разный. То есть может получиться так, что джуниор попал в компанию с низкой культурой и за год не научился правильным процессам. Дальше он придет в другое место, где на собеседовании станет понятно, что он слаб в этом вопросе. В любом случае, на пет-проектах получить такой опыт не удастся. >> Взаимодействие с другими членами команды: программистами, тестировщиками, администраторами. Здесь то же самое. Пет-проект — это работа в одного. Ни с кем не надо советоваться и согласовывать технические моменты. Можно в любой момент что-то переписать, перейти на другой стиль кодирования, выкатить без проверки. Естественно, нет никакого код-ревью. В команде нужно уметь договариваться, совместно искать архитектурные решения, идти на компромисс. В этой части всегда присутствует элемент спора, а иногда конфликта. Все это помогает прокачать софт-скиллы и стать частью корабля. Кстати, на эту тему есть хорошая книга от Роберта Мартина, называется «Идеальный программист»: https://ru.hexlet.io/pages/recommended-books >> Взаимодействие с заказчиками, это могут быть как внешние люди, так и внутренние заказчики, например, продакт- и проджект-менеджеры. Только тут программист начинает понимать всю сущность бытия. Оказывается, идеального ТЗ не бывает. Никто не знает, как оно должно работать, есть только хотелки. Нужно уметь превратить их в техническое описание, нужно увидеть потенциальные проблемы, донести их до заказчика, подумать над решением. Нужно уметь отстаивать свою позицию, упрощать и предлагать более оптимальные решения, нужно погружаться в предметную область и бизнес. Нужно уметь оценивать, ставить сроки и исполнять их. На всё это накладываются инструменты проектного менеджмента, такие как jira или trello.