Есть довольно болезненная история, через которую проходит много начинающих разработчиков.
Рассмотрим вопрос на примере погружения человека в веб-разработку. Человек месяцами учит теорию по ней. Курсы, ролики, статьи, пет-проекты, HTML, CSS, JavaScript, PHP, базы данных, фреймворки, Git, REST API и прочие радости жизни.
Потом приходит на собеседование и думает: ну всё, junior+ мне обеспечен, а глядишь и на middle возьмут.
А ему говорят:
"Мы готовы рассмотреть вас на junior-позицию" (а то и на стажировку только).
И где-то в этот момент внутри человека тихо ломается табуретка.
Потому что как так? Теория же выучена. Синтаксис понятен. CRUD делал. Авторизацию делал. ToDo-лист, возможно, делал уже столько раз, что при виде слова "task" начинает дергаться глаз.
Но тут есть неприятный нюанс.
В разработке важно не только уметь разговаривать на PHP, JavaScript, Python или любом другом языке. Важно понимать, что происходит в реальном проекте. А это уже не совсем про теорию.
1. Теория — это словарь, а не профессия
Теория нужна. Без неё никуда. Если человек не понимает, что такое HTTP, база данных, транзакция, Promise, middleware, индекс, валидация, авторизация и деплой, то ему будет тяжело. И его коллегам тоже.
Но сама по себе теория — это словарь.
Ты знаешь слова. Понимаешь определения. Можешь ответить на вопрос, чем POST отличается от GET, зачем нужны индексы в базе и почему хранить пароль открытым текстом — это идея уровня "а давайте сразу подожжем серверную".
Это хорошо. Но профессия начинается там, где нужно не просто знать правильный ответ, а понять, какой ответ уместен в конкретной ситуации.
Например:
- когда достаточно обычного REST API, а когда GraphQL действительно имеет смысл;
- когда можно оставить монолит, а когда пора резать систему на сервисы;
- когда Redux помогает, а когда он просто делает маленький React-проект тяжелее;
- когда "сделать красиво" сейчас означает через месяц получить боль, слезы и техдолг.
Вот это уже не из учебника вытаскивается. Это приходит через насмотренность и опыт.
2. Знать язык — не значит уметь разрабатывать
Очень частая ловушка: человек выучил JavaScript или PHP и думает, что теперь он веб-разработчик. Технически он уже может что-то писать. Но разработка — это не только писать код.
Разработка — это когда тебе дают задачу, описанную в стиле "ну там надо, чтобы оно работало нормально", и ты должен понять:
- что именно нужно сделать;
- какие данные нужны;
- какие есть ограничения;
- где это может сломаться;
- как это повлияет на текущий код;
- что спросить у менеджера, клиента или тимлида, пока ещё не поздно.
И вот тут начинающий разработчик часто проседает. Он может написать функцию, сверстать страницу, подключить библиотеку и даже сделать рабочую фичу.
Но когда появляется задача с мутными требованиями, старым кодом, странной базой, дедлайном, чужими решениями и фразой "там вроде всё просто", теория начинает немного потеть.
В курсах обычно всё просто и понятно: вот задача, вот структура проекта, вот правильный способ. В реальной разработке всё веселее.
Там может быть проект, где половина логики живет в компонентах, другая половина в сервисах, третья половина в базе, а четвертая половина вообще в голове у человека, который уволился два года назад.
3. Что такое насмотренность
Насмотренность — это когда ты уже видел разные проекты и начинаешь узнавать типовые ситуации.
Не потому что ты гений. А потому что уже наступал на грабли сам или видел, как наступают другие.
Ты видишь задачу "добавить одно поле" и понимаешь, что оно может потянуть миграцию базы, правку API, валидацию на фронте, админку, права доступа, экспорт в Excel и пару багов в старом коде.
Ты слышишь "давайте быстро сделаем временно" и уже представляешь, как это временно будет жить в проекте до его полной переделки лет через 5.
Ты видишь "надо просто прикрутить оплату" и понимаешь, что там будут статусы, ошибки, вебхуки, отмены, безопасность, логи и разбор полетов в стиле "а почему деньги списались, а заказ не создался".
Ты открываешь чужой код и не просто думаешь "фу, кто это писал", а пытаешься понять, почему оно стало таким. Может, сроки горели. Может, требования менялись. Может, команда уже третья. Может, там была причина, которую из кода не видно.
Вот это и есть насмотренность. Она не делает человека автоматически senior, но сильно отличает разработчика, который просто знает теорию, от человека, который готов к самостоятельному решению реальных коммерческих задач.
4. Почему на собеседовании это быстро видно
На собеседовании могут спросить теорию. И это нормально. Но часто гораздо интереснее не то, знает ли человек определение, а как он рассуждает.
Например, спрашивают:
"Как бы вы сделали авторизацию?"
Один человек начинает перечислять JWT, refresh token, cookie, localStorage, OAuth и ещё пару терминов для веса.
Другой сначала уточняет:
- что за приложение;
- кто пользователи;
- есть ли роли;
- что уже есть в проекте.
И вот второй человек может знать меньше красивых слов. Но звучит он взрослее, потому что мыслит не только инструментами, а задачей.
То же самое с базой, архитектурой, очередями, кешем, фреймворками и вообще чем угодно. Можно знать, что такое Redis. А можно понимать, нужен ли Redis в конкретном месте или вы просто ставите ещё одну штуку, которую потом кто-то будет чинить в пятницу вечером.
Собеседование не всегда идеально это проверяет. Там тоже хватает странных вопросов, вкусовщины и лотереи. Но если кандидат отвечает только заученными формулировками, без примеров, trade-off и понимания последствий — его часто и видят как junior.
5. Junior — это не оскорбление
Тут важно не психануть. Позиция junior не означает, что человек тупой, бесполезный или зря учился.
Junior — это не "ты ничего не знаешь". Junior — это чаще "ты ещё не показал, что можешь стабильно решать рабочие задачи в реальном проекте без постоянного присмотра".
Можно знать много теории и всё равно быть junior по уровню самостоятельности. Можно хорошо отвечать на вопросы, но теряться в реальной задаче. Можно сделать красивый пет-проект, но не понимать, как жить с чужим кодом и чужими ограничениями в коммерческом проекте.
И это нормально. Проблема начинается, когда человек воспринимает junior-позицию как плевок в душу. Хотя по факту это может быть просто честная оценка: база есть, потенциал есть, но коммерческой насмотренности пока мало.
6. Что прокачивать кроме теории
Если хочется быстрее выйти из состояния "я всё выучил, но меня всё равно видят junior", надо перестать собирать только термины. Нужно собирать опыт, похожий на реальную работу.
Не просто "сделал ToDo на Vue js", а хотя бы:
- авторизация с ролями;
- админка;
- работа с ошибками;
- загрузка файлов;
- интеграция со сторонним API;
- фильтры, сортировки, пагинация;
- деплой;
- README, чтобы другой человек понял, как это поднять;
- несколько правок после того, как проект уже "готов".
Особенно полезно брать свои старые проекты и не начинать новый с нуля, а дорабатывать старый. Это ближе к реальности.
В работе редко приходит ангел и говорит: "Вот тебе чистый проект, пиши как хочешь".
Чаще приходит легаси, где уже есть решения, зависимости, странности и места, в которые лучше не заходить без каски, страховки и письменного разрешения от всех живых и мертвых участников проекта.
Умение не просто написать с нуля, а аккуратно встроиться в существующую систему — очень важный навык.
7. Главная мысль
Если вы выучили теорию веб-разработки, но на собеседовании вам предлагают junior-позицию — это не обязательно провал.
Скорее всего, вам не хватает не знаний как таковых, а опыта применения этих знаний в реальных, кривых, живых условиях.
Теория отвечает на вопрос "как это называется". Практика — "как это сделать". А опыт и насмотренность — "а надо ли это вообще делать именно так".
И вот за последний пункт в разработке платят сильно больше.
Подписывайтесь на SkylinnTime — https://dzen.ru/skylinntime. Здесь будем говорить про IT, разработку и игровую индустрию без сказок про лёгкие деньги, но и без лишнего нытья. Пишет практикующий Senior Fullstack web developer и teamlead, который всё это видит не только со стороны красивых вакансий.