Собеседование frontend в 2026-м редко проваливается из-за «не назвал все CSS-свойства». Чаще ломается другое: человек знает React по курсу, но не может объяснить, почему список тормозит, куда девается состояние формы и что будет, если пользователь нажмёт «отправить» дважды. Нанимающий проверяет не энциклопедию фреймворка, а вероятность, что вы не сломаете кабинет на первом релизе.
Ниже — блоки, которые реально ставят на скрининге и техэкране, полные ответы, которые можно сказать вслух, и подготовка по вакансии, а не «по всему интернету». Общий каркас — вопросы на собеседовании. Самопрезентацию соберите отдельно, не внутри рассказа про замыкания. Смотреть, какой слот вам ближе, удобно по frontend-вакансиям.
Коротко:
- Готовьте глубоко стек из объявления: JS, CSS, один фреймворк. Не пять фреймворков «на всякий случай».
- Почти всегда спросят состояние, список, форму и что происходит при ошибке сети.
- Live coding проверяет ход мысли и простой рабочий путь, не идеальный архитектора.
- Один свой экран разберите до боли: данные, ререндер, доступность, что не сделали.
- Поведение и оценка объёма важны не меньше хуков: как вы режете скоуп и объясняете компромисс.
Как читать вакансию за 15 минут
Выпишите: фреймворк, TypeScript да/нет, кабинет или лендинги, дизайн-система, тесты, SSR/Next. Готовьте это. Если в вакансии React и формы, не тратьте неделю на Vue «вдруг спросят». Вторая проверка — объём: единственный фронт в стартапе и человек в команде с дизайн-системой — разные интервью.
Junior чаще ловят на HTML/CSS/JS и одном компоненте. Middle — на состоянии, производительности списка, доступности, работе с API. Senior — на границах: когда вынести в стейт-менеджер, как не убить бандл, как жить с легаси. Не готовьте senior-дизайн, если слот junior: вас услышат как человека не на ту роль.
Сверьтесь с тем, что уже лежит в frontend-резюме: если написали Next и GraphQL, будут копать. Если написали «адаптивная вёрстка» без факта — тоже спросят, и ответ развалится.
JavaScript: не определения, а сценарий
Спросят то, чем вы стреляете себе в ногу на практике: замыкание в цикле с обработчиком, this в колбэке, промис vs async, микротаски одной фразой, структурированное клонирование при postMessage — только если вакансия про это. Чаще: «что будет, если в обработчике await, а пользователь кликнул ещё раз».
Если обработчик async и нет защиты, второй клик запустит второй запрос, пока первый ещё в полёте. Я бы на кнопке сразу ставил disabled или флаг inFlight, а ответ первого запроса игнорировал бы, если уже ушли со экрана. Ошибку сети показываю рядом с формой, поля не сбрасываю: пользователь не должен набирать заново.
Про промисы на этом слоте мне важнее не «что такое event loop в учебнике», а порядок: сначала синхронно выставили состояние loading, потом fetch, потом setState по результату. Если setState после размонтирования — в новом React это уже не та боль, но я всё равно отменяю через AbortController, чтобы не долбить API зря.
Граница честно: тонкости очерёдности microtask/macrotask могу нарисовать на примере Promise.then и setTimeout, но на экране заказа я сначала закрываю двойной submit. Если копнёте в event loop — нарисую, не буду притворяться, что помню каждую спецификацию.
Почему это слышат как сильный ответ: есть пользовательский сценарий, есть отмена, есть граница знания. Нет лекции «замыкание это когда функция помнит лексическое окружение» без задачи.
CSS и вёрстка: кабинет, не лендинг с анимацией
В вакансиях на продукт спрашивают поток, флекс/грид, как не разъехать таблицу, как сделать фокус видимым, что будет на узком экране. Анимации и «сделайте как на Dribbble» — редкость, если вы не на маркетинг-сайт.
Типовой вопрос: «фильтры слева, таблица справа, на мобиле фильтры снизу. Как разложить?» Ответ — грид или флекс плюс что ломается при длинных данных, плюс overflow. Слабый ответ — «ну bootstrap». Сильный — где overflow, где sticky шапка таблицы, что с клавиатурой в фильтрах.
Десктоп: слева колонка фильтров фиксированной ширины, справа таблица с min-width и горизонтальным скроллом, если колонок много — не сжимаю цифры в кашу. Шапка таблицы sticky, чтобы при скролле строк не терять сортировку. Длинное название заказа — truncate с title, не ломаю высоту строки на три этажа без нужды. Мобил: фильтры уезжают в нижний лист или аккордеон, таблица становится карточками или тем же скроллом, не прячу обязательный столбец суммы.
Фокус: виден outline на фильтре и на строке, если строка кликабельна. Не вешаю click только на div. Если дизайнер принёс тень, которая перекрывает соседний контрол — это баг вёрстки, не «так в макете». Пустые данные: не прыгающий скелетон на 30 секунд, а явная пустая карточка и кнопка сброса фильтра.
React (или ваш фреймворк): состояние и список
Вопрос, который ставят постоянно: «список заказов, фильтр, детали справа. Где state?»
Фильтр и выбранный id — состояние экрана, не сервера. Список я бы держал как данные с сервера плюс статус loading/error, не как «массив, который сами мутируем в десяти местах». Детали — либо рядом, если уже пришли в списке, либо отдельный запрос по id, если в списке только шапка. Ключ в списке — стабильный id заказа, не индекс: иначе фильтр будет вспыхивать неправильными строками.
Лишний ререндер ловлю так: сначала смотрю, не поднял ли я слишком высоко состояние, из-за которого таблица перерисовывается на каждый символ в поиске. Поиск можно debounce, таблицу — мемоизировать строку, если профиль показал, что дорого. useMemo на всё подряд не ставлю: это шум, пока нет измерения.
Эффект с fetch кладу за зависимость от фильтра, не «в mount и забыли». Abort на смене фильтра, чтобы старый ответ не перетёр новый. Это тот баг, который я уже ловил в учебном кабинете: медленный запрос «все» прилетал после «оплаченные» и показывал не тот список.
Follow-up почти всегда: ключи, контролируемые инпуты, подъём состояния, контекст vs props. Готовьте одну фразу, зачем вам Redux/Zustand, если он в резюме: «много экранов делят корзину / черновик сложной формы». Если не делят — «не тащил бы».
Живой код: простой рабочий путь
Часто просят форму, список с фильтром, небольшой виджет. Не начинайте с архитектуры на 15 файлов. Сделайте работающее, проговорите ограничения, как на тесте. Ход мысли важнее идеальных абстракций — тот же навык, что в разборе live coding, только на фронте ещё видно, умеете ли вы не сломать ввод.
Я за 25 минут сделаю контролируемую форму: поля, ошибка под полем, submit disabled пока невалидно или уходит запрос. Список слева фильтрую по status на клиенте, если мок маленький; если скажете, что данных тысячи — скажу, что фильтр надо уносить на API, и оставлю TODO в комментарии, не буду притворяться, что клиентский filter это прод.
Стили — простой флекс, без борьбы с пикселем. Доступность: label связан с input, фокус виден, кнопку можно нажать с клавиатуры. Если не влезу в красивые пустые состояния — скажу вслух и оставлю текст «нет заказов».
Назовите, чего не успели. Названный компромисс — зрелость. Молчаливый костыль, который нашли за вас, — дыра.
Что не говорить — и чем заменить
Не «я знаю все фреймворки». Назовите один и границу. Не «у нас была микрофронтенд-архитектура», если вы верстали три экрана в монолите — скажите монолит и три экрана. Не «оптимизировал до 100 баллов Lighthouse», если не можете сказать, что мерили и на каком маршруте. Не спорьте с интервьюером, что CSS-in-JS «мёртв»: спросите, какой у них стек, и покажите, что умеете жить в нём.
Слабый ответ на «как ищете баг в проде»: «ну посмотрю в консоли». Сильный: какой пользователь, какой релиз, есть ли воспроизведение, сеть, флаг, откат. Даже на фронте инцидент — это гипотезы, не шаманство. Если не было прода — учебный: «фильтр показывал старые данные из-за гонки fetch, вот как поймал».
Про доступность не нужно читать WCAG наизусть. Нужно не строить кнопку из div без роли, не прятать ошибку только красным цветом, не ломать Tab. Если в команде нет дизайнера a11y, всё равно одна фраза про фокус отличает аккуратность. На CIS-слотах это спрашивают всё чаще в кабинетах для операторов: они работают с клавиатуры весь день.
Сеть, ошибки, доступность
Спросят: 401, 422, таймаут, пустой список vs ошибка сервера. Разные экраны. Не показывайте спиннер вечно. Не стирайте форму на 500. Для a11y: фокус, контраст, не прячьте ошибку только цветом. Если в вакансии нет слова accessibility, всё равно одна фраза про label и клавиатуру отличает вас от «верстальщика с курсов».
Поведение: оценка и конфликт с дизайном
Типовой behavioral: «дизайнер настаивает на анимации, из-за которой форма теряет фокус. Что сделаете?»
Не буду воевать вкусом в общем чате. Сначала воспроизведу: клавиатура, скринридер если есть, запись экрана. Потом коротко в задаче: «ломается фокус, это баг ввода, не вкус». Предложу компромисс — анимация на декоративном блоке, не на поле. Если дедлайн горит, выкатываю без анимации на форме и завожу тикет на потом. Эскалация к лиду — если спор блокирует релиз, не если нам не нравится цвет кнопки.
Готовьте ещё одну историю: резали скоуп, ошиблись в оценке, поймали баг на проде. Формат STAR, коротко. Сильные и слабые стороны не вшивайте сюда пачкой — это отдельные вопросы.
Две недели без распыления
- Дни 1–3. JS: промисы, двойной клик, AbortController. Один экран своего проекта — схема данных.
- Дни 4–6. React: список, ключи, форма, эффект с fetch. Проговорить вслух ответ про state.
- Дни 7–8. CSS кабинета: грид, overflow, фокус. Не анимации.
- Дни 9–11. Live: 40 минут на форму+список по таймеру, потом разбор, что отрезали.
- Дни 12–14. Mock-интервью: самопрезентация, один экран, вилка. Живой прогон — подготовка к интервью.
Частые вопросы
Спросят ли алгоритмы?
Иногда короткий кусок: уникальные значения, группировка, разворот списка. Редко полный leetcode, если вакансия про кабинет. Смотрите объявление. Не топите две недели в деревьях, если в вакансии React и Figma.
Нужен ли TypeScript на junior?
Если он в вакансии и в резюме — да, типы пропсов и ответа API. Если в вакансии JS — не изображайте архитектора дженериков. Честная граница сильнее.
Что, если не знаю Next, а он в шапке?
Скажите, что такое SSR/SSG своими словами и где вы живёте на клиенте. Не учите весь фреймворк за ночь. Либо не откликайтесь на слот, где Next — ядро.
Можно ли готовиться по чужим «200 вопросов frontend»?
Как список тем — да. Как заучивание ответов — нет. Интервьюер чуть сдвинет формулировку, и заученное сыпется. Готовьте свой экран.
Стоит ли нести тестовое с прошлого отбора?
Да, если нет NDA. Пометьте ограничения. Это живой разбор, сильнее абстрактного pet-проекта.
Нужно ли письмо к отклику, если интервью уже про стек?
Короткое — помогает попасть на скрининг. Шаблон: сопроводительное и короткая версия. На самом техэкране письмо уже не спасает.
Что сделать сейчас
Возьмите одну вакансию. Выпишите стек. Выберите один свой экран и напишите к нему ответ на полторы минуты: данные, баг, что отрезали. Прогоните форму с двойным submit вслух. Затем идите в каталог frontend-ролей уже с этим каркасом, а не с подборкой «все вопросы мира».