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

1. Unit-тесты

Польза на работе: ⭐☆☆☆☆ (1/5)

В большинстве проектов unit-тесты либо отсутствуют, либо пишутся «для галочки».

Для реально полезных тестов нужно знать тонны теории (граничные случаи, mock-объекты), но джунам это почти не пригодится.

ИИ уже умеет писать базовые тесты.

Спрашивают на собеседованиях: ☆☆☆☆☆ (0/5)

За мои 100+ собеседований — unit-тесты спрашивали 2 раза, и то формально.

Что делать вместо:

Потратьте 2 часа на написание 10 тестов в пет-проекте и посмотрите видео (UlbiTV Тестирование JavaScript от А до Я) про тестирование — этого хватит для понимания основ.

2. Алгоритмы и «глубокий» JavaScript

Польза на работе: ⭐☆☆☆☆ (1/5)

Базовое понимание (например, O(n^2) vs O(n)) полезно, но:

• 99% задач решаются встроенными методами JS (filter, map, Set).

• Углубление в алгоритмы мешает решению бизнес-задач (джуны часто «оптимизируют» то, что работает и так).

Спрашивают на собеседованиях: ⭐⭐⭐⭐⭐☆ (4/5)

Вот тут уже грустно, они нужны для прохождения собеседований, спасибо Гуглу и Яндексу, теперь у нас каждый джун должен уметь написать свою sort и filter, как будто взять готовый из JS — это стыдно. В последнее время вроде есть тренд на собеседования без жести, но у крупных компаний этого тренда явно нет. Так что учить их нужно, но только в рамках подготовки к собеседованиям.

Что делать:

• Учите ровно столько, сколько нужно для прохождения собеседований.

• Тренируйтесь на codewars или leetcode (но без фанатизма).

3. CI/CD и Docker

Польза на работе: ☆☆☆☆☆ (0/5)

• Я не знаю junior-разработчиков, которым пришлось бы настраивать что-то в docker или править пайплайны CI/CD — этим занимаются DevOps или тимлиды.

• Современные хостинги (Vercel, Netlify) автоматизируют деплой в 1 клик. (Для пет-проектов)

Спрашивают на собеседованиях: ⭐☆☆☆☆ (1/5)

• Вопросы в духе: «Что такое CI/CD?»

Что делать вместо:

Освойте базовый Git до автоматизма:

git rebase vs git merge — когда что использовать (и почему rebase опасен в общих ветках).

Как решать конфликты без паники (алгоритм: git pull → правки → git add → git commit).

Простые команды для ежедневной работы.

Разберитесь, как работает сборка проекта:

Что делает npm run build в вашем проекте?

Куда смотреть, если сборка падает?

Ошибки в консоли (чаще всего — синтаксис или зависимости).

Научитесь работать с npm-пакетами:

Как читать package.json (ключевые поля: dependencies, scripts).

Почему npm install может сломаться.

4. Английский язык

Польза на работе: ⭐⭐☆☆☆ (2/5)

ChatGPT/YandexBrowser переводят за секунды.

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

Спрашивают на собеседованиях: ⭐☆☆☆☆ (1/5)

HR иногда спрашивают: «Технический английский?» (Технический = умею гуглить на английском, уровня А2 будет более чем).

Что делать вместо:

• Учите технические термины.

• Тренируйтесь читать ошибки в консоли.

5. Linux и терминал

Польза на работе: ⭐☆☆☆☆ (1/5)

VS Code/WebStorm делают 99% работы за вас. А если случится что-то, что не может решить IDE, эту проблему решит ИИ и гугл.

Спрашивают на собеседованиях: ☆☆☆☆☆ (0/5)

Я не слышал ни одного вопроса по Linux, просто не нужен для работы, фронтенд не зависит от ОС, на которой его разрабатывают, так что в одной команде могут спокойно (почти) жить Windows, Linux и Mac. В общих списках вопросов и разнообразных мок-собеседованиях таких вопросов нет.

Что делать вместо:

• Освойте Chrome DevTools.

• Учите базовую безопасность (CORS, HTTPS, XSS).

6. Чистый код

Польза на работе: ⭐⭐☆☆☆ (2/5)

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

Решил бизнес-задачу (код ужасен или близок к этому) → Рефакторинг под правила проекта (код читаемый, но с проблемами) → Ревью кода (если есть время, правим, если нет, в бэклог)

Все пишут ужасный код, и это нормально, не старайтесь научиться сразу писать хорошо, это долго и сложно, и не всегда эффективно. Не убивайтесь об SOLID и ему подобных, чтобы быть хорошим разработчиком, достаточно DRY, YAGNI, Избегайте преждевременной оптимизации и KISS.

Спрашивают на собеседованиях: ⭐☆☆☆☆ (1/5)

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

Что делать вместо:

• Осваиваешь DRY, YAGNI, Избегайте преждевременной оптимизации и KISS.

• Изучаешь, как правильно писать в твоем стеке технологий.

7. Паттерны проектирования

Польза на работе: ⭐☆☆☆☆ (1/5)

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

Спрашивают на собеседованиях: ☆☆☆☆☆ (0/5)

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

Что делать вместо:

• Учите композицию компонентов.

• Разберитесь, когда нужен Redux, а когда хватит useState

Немного примеров:

1. Разработчик, который изучал основы языка параллельно паттернам и чистому коду, через полтора года изучения в таком формате у нас случился пет-проект, и оказалось, что все проблемы, которые возникают, он старается решать через сложные, правильные и оптимизированные решения, по итогу простой экран с формой был сделан очень круто, масштабируемый, оптимизированный и технически красивый, но очень долго, две недели по 2–4 часа в день, в то время как сделать такую задачу «просто» можно было за 2 часа и еще часа 4 на рефакторинг. С одной стороны, его решение хорошее, но избыточно и долгое.

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

Итог: Как начинающему фронтендеру не потерять год на бесполезные навыки

Главный парадокс входа во фронтенд: 50% того, что учат джуны, не пригодится им на первой работе. Алгоритмы, unit-тесты, паттерны — всё это важно, но не для старта карьеры.

Что запомнить:

1. Фокус на реальных задачах

   • Легаси-код, гугление ошибок и работа в команде дадут вам больше, чем знание SOLID.

   • Учите то, что спрашивают на собеседованиях (алгоритмы — да, но без фанатизма).

2. ИИ — ваш помощник

   • Не тратьте месяцы на то, что ChatGPT делает за 5 минут (например, unit-тесты).

   • Но не доверяйте слепо — учитесь проверять его решения. (vibe coding = зло)

3. Главные навыки 2025

   • Умение писать и читать код на вашем стеке (язык, фреймворки, библиотеки)

   • Понимание производительности (почему тормозит интерфейс?).

   • Коммуникация (как объяснить проблему менеджеру).

4. Небольшой чек-лист

   1. Верстка — умение сверстать простую страницу, множество сайтов в помощь.

   2. Базовый JavaScript (работа с DOM, ES6+) — можешь решать задачи на Codewars/Leetcode без необходимости гуглить стандартные методы языка.

   3. Основы фреймворка (React/Vue) — можешь сделать небольшое приложение САМОСТОЯТЕЛЬНО! (Гуглить можно, но не заставлять нейросеть писать за тебя): ToDo list, трекер, менеджер финансов, что угодно, где вам придется использовать основные механизмы вашего фреймворка.

   4. Основы state manager'а — базовые знания одного state manager'а и понимания концепций управления стейтом (можешь интегрировать его в свое приложения).

   5. Основы Git — git pull, git commit, git push. Решение мерж-конфликтов.

   6. TypeScript — основы типизации.

5. Полезные ссылки

   Первая часть Roadmap:https://habr.com/ru/articles/800579/

   Вторая часть Roadmap:https://habr.com/ru/articles/802047/

   Telegram канал: https://t.me/frontend_nomagic