Senior Frontend: разбор реального собеседования и путь до эксперта

Мы изучили два материала — запись реального технического собеседования на Senior Frontend позицию с вилкой до 400 тысяч рублей и авторский разбор карьерного пути в IT в 2025 году. Первый — конкретика: что спрашивают, как отвечать, где проваливаются даже опытные кандидаты. Второй — шире: сколько вообще учиться, что такое «сеньор» на самом деле и почему система грейдов не работает так, как принято думать.

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

▶ 05:34

Главный вывод: технические знания — необходимое условие, но не достаточное. Рынок изменился, требования к минимальному уровню выросли, а традиционная система Junior / Middle / Senior всё хуже описывает реальные компетенции.

Что реально спрашивают на Senior Frontend: карта тем

Разберём по блокам. Собеседование охватывало широкий спектр — от базового JavaScript до архитектурных решений в React. Никакой воды, только темы с конкретными вопросами.

JavaScript-ядро: без этого дальше не идут

Первый блок — основы языка. Типы данных, замыкания, прототипы, this, Promise, event loop. Это не «лёгкая разминка» — именно здесь кандидаты чаще всего спотыкаются на деталях.

Конкретные вопросы, которые звучали:

• Перечислите примитивные типы данных в JavaScript. Правильный ответ: null, undefined, boolean, number, string, symbol, bigint. Функции и массивы — не отдельные типы, они объекты. Но typeof для функции вернёт строку "function" — это историческая особенность языка, а не логика. Для проверки массива — только Array.isArray.

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

• Как работает this? Зависит от типа функции. Стрелочные функции берут this из лексического окружения — туда, где они объявлены. Обычные функции (function declaration, function expression) — из контекста вызова. Явно задать контекст можно через bind, call, apply. Интервьюер почти всегда уточняет: «А в стрелочной функции?» — будьте готовы.

• Promise: три состояния (pending, fulfilled, rejected), принимает функцию с resolve и reject. Ключевой нюанс: даже если Promise уже выполнен, его колбэк — микрозадача. Он выполнится после синхронного кода. Классический вопрос на event loop: «В каком порядке выполнятся синхронный alert и alert внутри уже resolved Promise?» Ответ: сначала синхронный.

TypeScript: типы против интерфейсов

Вопрос задавался прямо: «Когда вы используете type, а когда interface?»

Практическая разница: - Интерфейсы предпочтительны для описания объектов. Поддерживают extends для наследования и implements для классов. - Типы (type) поддерживают объединение через &, удобны для примитивов, union-типов, conditional types.

Главное правило — консистентность внутри проекта. Если команда использует интерфейсы, не надо вводить типы в половине файлов. Интервьюер это слышит и оценивает.

CSS: позиционирование и практическая задача

Теория — пять значений position: static, relative, absolute, fixed, sticky. Но теория без практики не считается.

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

.icon-wrapper {
  position: relative;
}

.badge {
  position: absolute;
  top: 0;
  right: 0;
}

Родитель — relative, бейдж — absolute. Без relative на родителе бейдж уйдёт к ближайшему позиционированному предку или к body. Это типичная задача на понимание контекста позиционирования, а не на знание синтаксиса.

React: хуки, ре-рендеры, оптимизация

Блок про React — самый объёмный. Разберём по пунктам то, что реально спрашивалось.

Хуки: - useState — управление состоянием, вызывает ре-рендер при изменении - useRef — доступ к DOM-элементу, изменение значения не вызывает ре-рендер - useEffect — замена методов жизненного цикла (componentDidMount, componentDidUpdate, componentWillUnmount) - useMemo — мемоизация вычислений, предотвращает лишние пересчёты - useCallback — мемоизация функций, особенно при передаче вниз по дереву - memo — оборачивает компонент, предотвращает ре-рендер при неизменившихся props

Практический кейс с useCallback: есть функция удаления элемента из списка, она передаётся в дочерний компонент. Без useCallback при каждом ре-рендере родителя создаётся новая ссылка на функцию — React сравнивает props по ссылкам, видит «новую» функцию и перерисовывает дочерний компонент без необходимости. useCallback фиксирует ссылку.

▶ 33:04

Ре-рендер: происходит при изменении props или state. React сравнивает props по ссылкам — это важно понимать для оптимизации.

Redux: архитектура изнутри

Интервьюер расспрашивал не «умеете ли вы использовать Redux», а «понимаете ли вы, как он устроен». Разница принципиальная.

Архитектура Redux: - Store — единственный источник истины, хранит всё состояние приложения - Reducer — чистая функция: принимает предыдущий state и action, возвращает новый state. Никаких мутаций, никаких побочных эффектов - Action — объект с полем type, описывает что произошло - Action creator — функция, создающая action - Middleware — слой между dispatch и reducer. Используется для side effects

Redux-Saga как middleware: отслеживает конкретные типы action через watcher-функции. Если action совпадает — выполняется saga (например, запрос к серверу). Если нет — action проходит напрямую в reducer. Данные текут в одном направлении.

Context API vs Redux: Redux написан поверх Context API. Context подходит для простых случаев — не нужны дополнительные библиотеки. Минусы Context в больших приложениях: сложно масштабировать, лишние ре-рендеры всех подписанных компонентов при каждом обновлении.

Сетевые технологии и хранение данных

SSE vs WebSocket: - SSE (Server-Sent Events) — однонаправленный поток: только от сервера к клиенту. Практический пример — котировки в реальном времени, где фронтенд только получает данные, ничего не отправляя обратно - WebSocket — двунаправленный обмен. Нужен, когда клиент тоже должен отправлять данные в реальном времени

▶ 10:08

Хранение данных в браузере — четыре варианта: - localStorage — постоянное хранение, сохраняется после закрытия вкладки - sessionStorage — только в рамках сессии, удаляется при закрытии вкладки - IndexedDB — для больших объёмов данных (массивы из 100+ объектов и более) - cookies — передаются с каждым HTTP-запросом, используются для аутентификации

Копирование объектов: spread-оператор копирует только на один уровень вложенности. Для глубокого копирования — JSON.stringify/JSON.parse (с ограничениями: не работает с функциями, undefined, циклическими ссылками) или специализированные библиотеки.

Сколько учиться: честный ответ без мотивационной воды

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

Система грейдов сломана

70% вакансий с названием «Senior разработчик» на рынке требуют опыт от 3 до 6 лет. 15% — от 1 до 3 лет. Ещё 15% — более 6 лет. Это данные с hh.ru. Сеньор в одной компании может соответствовать мидлу в другой. Название позиции не говорит ничего о реальных компетенциях.

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

Парадокс: чтобы получить работу, нужен опыт. Чтобы получить опыт — нужна работа. Это не новость, но в 2025 году он стал острее.

Новая система оценки: проекты, а не стаж

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

Предлагается такая шкала:

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

Почему курсы не работают так, как обещают

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

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

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

Практический раздел: что делать прямо сейчас

Если вы готовитесь к Senior Frontend собеседованию

Список тем для повторения — разбит по блокам:

JavaScript-core: - [ ] Примитивные типы данных и их особенности (typeof null === 'object', typeof function === 'function') - [ ] Замыкания — определение + пример из реального кода - [ ] Прототипное наследование, цепочка прототипов, __proto__ - [ ] this в разных типах функций, bind/call/apply - [ ] Promise: три состояния, микрозадачи, порядок выполнения - [ ] Event loop: синхронный код → микрозадачи → макрозадачи

TypeScript: - [ ] type vs interface: когда что использовать - [ ] Сужение типов в условных ветках

CSS: - [ ] Все значения position и как они взаимодействуют - [ ] Специфичность селекторов - [ ] Практические задачи на позиционирование (бейдж, тултип, модалка)

React: - [ ] Разница между useRef и useState (ре-рендер vs нет) - [ ] useCallback — зачем нужен, когда без него плохо - [ ] useMemo — мемоизация вычислений - [ ] memo — когда оборачивать компонент - [ ] Как React сравнивает props

Управление состоянием: - [ ] Redux: store, reducer (чистая функция!), action, middleware - [ ] Redux-Saga: watcher-функции, как отслеживает action-типы - [ ] Context API: плюсы, минусы, когда хватает, когда нет

▶ 03:29

Архитектура и паттерны: - [ ] SOLID — все пять принципов с примерами применительно к frontend - [ ] SSE vs WebSocket: когда что использовать - [ ] REST API: принципы, методы, кэширование - [ ] Паттерны: Singleton, Observer, Decorator, Render Props

Производительность: - [ ] Виртуализация списков: зачем, как работает - [ ] React DevTools Profiler: что показывает - [ ] Chrome DevTools Performance: как читать результаты

Для каждой темы: не просто прочитать определение, а уметь объяснить простыми словами и привести пример из реального проекта. Интервьюер почти всегда спрашивает: «А вы с этим работали?»

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

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

Если вы только входите в IT или оцениваете свой прогресс

1. Выберите направление — не «программирование вообще», а конкретно: frontend, backend, мобильная разработка. Размытый выбор размывает и план обучения.

▶ 04:02

1. Составьте роадмап до начала учёбы. При самостоятельном обучении без структурированного плана до 40% времени уходит на поиск того, что вообще нужно учить. Это не преувеличение — это реальные потери.

2. Учитесь ежедневно. Минимум 4–5 часов в день. Занятия раз в неделю не дают результата — мозг не успевает закрепить материал.

3. Сделайте первый полноценный проект — не учебный пример, а реальный: с интерфейсом, логикой, в открытом доступе. Именно он идёт на собеседование, а не список пройденных курсов.

4. Готовьтесь к алгоритмическим собеседованиям параллельно — они обязательная часть технического интервью в большинстве компаний.

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

Что мы заметили: где материалы сходятся и где расходятся

Точки пересечения

Оба материала независимо приходят к одному выводу: название позиции ничего не гарантирует. В разобранном собеседовании кандидат претендовал на Senior-уровень и получил положительный фидбек — но оффер оказался ниже ожиданий. Второй материал подкрепляет это статистикой: 70% вакансий «Senior» требуют опыт от 3 до 6 лет, но реальные компетенции внутри этого диапазона разнятся кардинально.

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

Где подходы расходятся

Подход А (из разбора собеседования) — технический, детальный. Акцент на глубине знания конкретных инструментов: понимать Redux изнутри, знать разницу между useMemo и useCallback на уровне механики, уметь объяснить event loop с примером кода. Это взгляд со стороны технического интервью: важно не только «умею использовать», но и «понимаю, как это работает».

Подход Б (карьерный разбор) — более широкий. Здесь акцент на системе оценки через результат: сколько проектов реализовано, насколько они разнообразны, есть ли опыт командной работы. Технические знания подразумеваются, но не являются единственным критерием.

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

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

Наблюдение по рынку

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

Итог

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

▶ 02:32

Карьерный путь в IT в 2025 году — это не спринт на три месяца и не марафон на десять лет. Это ближе к ремеслу: год на базу, три года на уверенный уровень, шесть-восемь — на экспертизу, которую замечают за пределами одной компании. Единственное, что точно не работает — учиться нерегулярно и ждать, что название позиции в резюме само по себе что-то изменит. Начните с роадмапа, сделайте реальный проект, идите на собеседование — и используйте разбор выше как чек-лист, а не как гарантию.