Вопросы на собеседовании Frontend-разработчика

Пример сильного ответа

var имеет функциональную область видимости, let и const — блочную. var всплывает и до присваивания даёт undefined; let и const тоже формально поднимаются, но до инициализации находятся в так называемой временной мёртвой зоне, и обращение к ним раньше объявления — ошибка. const запрещает переприсваивание, но объект или массив, на который ссылается переменная, менять можно. В команде на код-ревью мы держим правило: var не используем вообще, для неизменяемых значений — const, для счётчиков и накопления — let. После такой миграции вычистили около 120 объявлений и убрали класс ошибок из-за случайного всплытия.

• Определения точные и без воды
• Показано практическое следствие для команды
• Есть правило и измеримый результат

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Замыкание — это когда функция запоминает переменные из внешней области видимости и сохраняет к ним доступ даже после того, как внешняя функция завершилась. На практике функция-фильтр, реализованная через замыкание, держит внутри кэш ранее вычисленных результатов: на каталоге из 4 000 позиций пересчёт ускорился примерно вдвое. Второй случай — обработчики в цикле: там, где нужен снимок значения, применяется отдельная фабрика, чтобы каждое замыкание держало своё значение, а не одно общее. Это убирает баг с одинаковым индексом.

• Определение дано своими словами
• Два разных практических примера
• Есть эффект, а не только теория

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Event loop — это механизм, который позволяет одному потоку выполнять асинхронный код: сначала синхронный код в стеке, потом всё, что накопилось в очередях. Микрозадачи — это промисы, queueMicrotask, наблюдения за мутациями; макрозадачи — таймеры, события, сетевые ответы. Ключевое отличие: после каждой макрозадачи движок полностью опустошает очередь микрозадач и только потом берёт следующую макрозадачу и при необходимости перерисовывает кадр. Поэтому длинная цепочка промисов способна задержать отрисовку, а бесконечная рекурсия микрозадач блокирует страницу. Мне приходилось разбивать тяжёлый расчёт на порции через setTimeout: время отклика на список из 5 000 строк уменьшилось до десятых долей секунды.

• Верно описана последовательность очередей
• Отмечено влияние на отрисовку кадра
• Приведён реальный кейс оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Promise.all ждёт все промисы и падает сразу при первой ошибке — результат приходит массивом в том же порядке. allSettled тоже ждёт все, но не отклоняется: на каждый промис возвращает объект со статусом fulfilled или rejected, поэтому удобно, когда часть запросов может упасть, а остальные данные всё равно нужны. race отдаёт результат самого быстрого — и успех, и ошибку, поэтому обычно это таймауты и отмена. В одном проекте на дашборде было 12 параллельных запросов к разным сервисам, и через allSettled удалось показать интерфейс даже при двух недоступных источниках, а не пустой экран.

• Чётко разведены три метода и их сценарии
• Есть реальный пример с числом и результатом
• Показано понимание обработки частичных ошибок

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Interface описывает форму объекта и умеет расширяться через extends, а также поддерживает declaration merging — одинаковые интерфейсы в разных файлах объединяются, что удобно для типизации сторонних библиотек. Type — это алиас для любого типа: объединения, кортежи, условные и mapped-типы, примитивы. Поэтому союзы и вычисляемые типы — только через type, а публичные контракты компонентов и пропсов удобнее держать в interface. В моей практике на проекте с 60+ компонентами общий словарь пропсов и ответов API живёт в интерфейсах, а вариации вроде строковых литералов статуса — в type. Так код читается легче и правки не расходятся по файлам.

• Названы ключевые отличия, а не спор о вкусах
• Есть практическое правило выбора
• Подкреплено масштабом проекта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Дженерики — это параметры типа: функция или компонент описывается один раз и работает с любым типом, при этом связь между входом и выходом сохраняется, а не теряется в any. Классический пример — обёртка над запросом, которая принимает URL и возвращает Promise нужной модели, а также хук с типом данных списка. В моём коде есть компонент таблицы с дженериком по строке: колонки описываются один раз, а на выходе тип строки сохраняется, поэтому опечатка в поле ловится компилятором. На таблице в 15 колонок это убрало целый класс ошибок на ревью.

• Сначала суть, потом пример из практики
• Показан реальный выигрыш от типизации
• Нет абстрактных рассуждений без опоры

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Разница объяснена через суть, а не синтаксис
• Честно названы издержки мемоизации
• Есть пример обратного рефакторинга с числом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

React перерисовывает компонент, когда меняется его state или приходят новые пропсы, а также когда рендерится родитель — если только компонент не обёрнут в memo. Сравнение поверхностное, по ссылке, поэтому новые объекты и функции в пропсах ломают мемоизацию. Ключи в списках нужны, чтобы React сопоставлял элементы между рендерами и переиспользовал DOM, а не пересоздавал всё. Индекс как ключ ломается при вставке и сортировке: в списке из 500 задач с drag-and-drop переход на стабильные id убрал мигание и потерю фокуса в полях ввода.

• Механика рендера объяснена коротко и по делу
• Связь ключей с переиспользованием DOM
• Наглядный пример с числом и симптомом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Чаще всего мне приходилось сталкиваться с тремя вещами. Первая — неполный массив зависимостей: значение внутри эффекта остаётся устаревшим, и поведение расходится с ожиданиями. Вторая — объект, массив или функция прямо в зависимостях: они создаются заново на каждый рендер, и эффект зацикливается. Третья — эффект там, где достаточно вычисления при рендере или обработчика события. Ещё часто забывают про очистку подписок и таймеров. Помогает правило линтера о зависимостях, мемоизация через useCallback и useMemo, ref для нестабильных значений и функциональное обновление состояния. В одном проекте таких мест было около пятнадцати; после переработки лишние перерисовки при скролле ушли.

• Названы три конкретные ошибки, а не общие слова
• Есть инструменты решения, а не только диагноз
• Цифра из личного опыта подтверждает практику

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю с самого простого: локальный state, пока данные нужны одному экрану или ветке компонентов. Context беру для того, что меняется редко и нужно многим — тема, язык, текущий пользователь; для частых обновлений он неудобен, потому что тянет за собой всех потребителей. Redux Toolkit выбираю там, где большая команда, сложные асинхронные сценарии, нужны предсказуемость и инструменты отладки. Zustand — когда нужен лёгкий общий стор без церемоний, с точечными подписками на слайс. Критерии простые: частота обновлений, число потребителей, размер команды, требования к отладке и кешированию. В проекте с четырьмя командами и примерно сорока экранами общий стор на Redux Toolkit заметно упростил сопровождение.

• Ясный принцип движения от простого к сложному
• Названы критерии выбора, а не вкусовщина
• Упоминание отладки и кеша говорит о зрелости

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

SSR рендерит страницу на каждый запрос: свежие и персональные данные, но выше нагрузка на сервер и время ответа. SSG собирает готовый HTML заранее: максимально быстро, удобно кешировать на CDN, подходит для контента, который меняется нечасто. CSR отдаёт каркас и рисует всё в браузере: уместно для личных кабинетов и виджетов, где поисковая выдача не важна. Выбор делаю по странице: статьи и каталог — статика с периодической регенерацией, карточка товара с ценой под пользователя — серверный рендер, кабинет — клиентский. На практике это гибрид: серверные компоненты для данных, клиентские для интерактивности. Перевод каталога на статику дал падение нагрузки примерно на 60%.

• Каждый подход объяснён через компромисс
• Решение принимается по странице, а не глобально
• Цифра про нагрузку делает ответ предметным

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Controlled — когда значение живёт в состоянии, а поле отдаёт изменения через обработчик. Это даёт предсказуемость: мгновенная валидация, зависимые поля, маски, блокировка кнопки отправки. Минус — рендер на каждый символ, что заметно на больших формах. Uncontrolled — когда значение читается через ref, а начальное задаётся атрибутом: меньше рендеров, проще интеграция с файловыми полями и сторонними библиотеками. На практике часто гибрид: библиотека форм держит поля неконтролируемыми и подписывает на изменения только нужные части. В форме на тридцать полей такой переход убрал задержку ввода примерно на треть.

• Сравнение идёт по предсказуемости и производительности
• Упомянут гибридный подход из реальной практики
• Метрика из своего опыта усиливает ответ

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Flexbox — одномерная раскладка: элементы выстраиваются вдоль одной оси, а размеры часто определяет содержимое. Это мой инструмент для навигации, тулбаров, рядов карточек, выравнивания и распределения свободного места. Grid — двумерная сетка: строки и колонки задаются заранее, есть именованные области и автоплейсмент, поэтому одинаковые по высоте строки получаются без хаков. Grid беру для каркаса страницы, галерей и дашбордов, flex — внутри компонентов. В дашборде с восемнадцатью виджетами такой подход сократил разметку и стили примерно на четверть, а адаптив собрался через auto-fit и minmax без лишних медиазапросов.

• Чётко разделены одномерная и двумерная раскладка
• Есть практическое правило комбинирования инструментов
• Пример с цифрами и адаптивом звучит убедительно

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Специфичность — это вес селектора: инлайн-стили и идентификаторы перебивают классы, классы — теги, а при равном весе побеждает правило ниже в файле. Мне ближе держать специфичность низкой: один класс на компонент, вложенность не глубже двух уровней, для обнуления веса — :where(), плюс каскадные слои, чтобы порядок подключения не решал всё. !important ломает эту логику: он переворачивает каскад, и перебить стиль потом можно только ещё одним !important. Это тревожный сигнал, что архитектура CSS поплыла. На одном проекте получилось убрать около сорока таких правил и сократить таблицу стилей примерно на 15 процентов.

• Показано понимание каскада, а не заучивание весов
• Объяснено, почему !important мешает поддержке кода
• Ответ подкреплён личным измеримым результатом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

По умолчанию я работаю mobile-first. Так проще: базовые стили — под узкий экран, а min-width медиазапросы дальше только добавляют, а не переопределяют. Это заставляет сначала расставить приоритеты в контенте, а не сжимать десктопную сетку. Для сложных админок, где основной сценарий — большой монитор, разумнее desktop-first, там логичнее max-width. Точки перелома выбираю по контенту, а не по популярным устройствам, и активно использую grid, clamp() для типографики и container queries. После перехода на mobile-first конверсия мобильной версии выросла примерно на 12 процентов, а правок под конкретные разрешения стало заметно меньше.

• Есть осознанный принцип выбора, а не привычка
• Учтён сценарий, где desktop-first действительно оправдан
• Результат подтверждён метрикой, а не словами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Core Web Vitals — это метрики опыта пользователя: LCP про скорость появления главного контента, CLS про визуальную стабильность, INP про отзывчивость на действия. Смотрю в первую очередь на полевые данные, лабораторные замеры использую как подсказку. По LCP: приоритетная загрузка главного изображения, отказ от ленивой загрузки выше первого экрана, самохостинг шрифтов, меньше блокирующих скриптов. По CLS: заданные размеры и aspect-ratio для картинок и баннеров, заранее отведённое место под динамику. По INP: дробление длинных задач, отложенная инициализация тяжёлых виджетов, разгрузка обработчиков ввода. На ключевой странице удалось снизить LCP примерно с четырёх секунд до двух, а INP — с 480 до 180 миллисекунд.

• Различает полевые и лабораторные измерения
• По каждой метрике названы конкретные приёмы
• Есть результат до и после с цифрами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю с измерений: смотрю размер бандла, что в него попало и что реально нужно на первом экране. Дальше код-сплиттинг по маршрутам и динамический импорт для тяжёлых виджетов — редакторов, графиков, карт. Ниже первого экрана изображения грузятся лениво, в современных форматах, с набором размеров под разную плотность экрана. Статика отдаётся через CDN с хешированными именами, чтобы кеш жил долго; критичный CSS инлайнится, некритичные скрипты откладываются, следующий маршрут подгружается заранее при наведении. На одном проекте бандл первой загрузки уменьшился примерно с 1,2 мегабайта до 380 килобайт, а время до интерактивности сократилось почти на треть.

• Начинает с измерений, а не с оптимизации вслепую
• Приёмы взяты из разных слоёв загрузки
• Цифры показывают эффект, а не намерение

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Доступность начинается с семантики: корректные теги, иерархия заголовков, label у каждого поля, alt у значимых изображений. Дальше — управление с клавиатуры: всё, что кликается, должно фокусироваться, фокус видимый, порядок обхода логичный. ARIA добавляю только там, где нативной семантики не хватает, потому что неверный ARIA хуже его отсутствия. Проверяю вручную — проход по интерфейсу только клавиатурой и скринридером, автоматические проверки в CI работают как быстрый фильтр. В дизайн-системе закладываю контраст и состояния фокуса прямо в компоненты. На одном продукте закрыли около шестидесяти замечаний по доступности, и большая часть — семантикой и фокусом, а не ARIA.

• Семантика поставлена выше ARIA
• Сочетаются ручная и автоматическая проверка
• Показан системный подход через дизайн-систему

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сначала я не трогаю код, а измеряю. Открываю Lighthouse и вкладку Performance, смотрю Network: где основное время — на ответ сервера, на загрузку бандла или на рендер. Параллельно смотрю RUM-метрики по реальным пользователям, потому что 8 секунд на моём ноутбуке и на среднем смартфоне — разные вещи. Дальше гипотезы: размер бандла, число запросов, кэширование, лишние ре-рендеры, блокирующие скрипты. На одном проекте после код-сплита и виртуализации длинного списка время до интерактивности упало с 7 до 2,5 секунд, а конверсия выросла на 12%. Оптимизировать вслепую смысла нет: сначала узкое место, потом изменение.

• Показан системный подход: сначала измерения, потом правки
• Есть конкретные цифры результата и влияние на бизнес
• Упомянуты реальные пользователи, а не только локальная машина

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Большой рефакторинг одним махом — верный способ положить продукт, поэтому мой план инкрементальный. Включаю allowJs и проверку типов, строгость наращиваю постепенно, чтобы сборка не падала. Дальше правило: новый код и всё, что правится, пишу на TypeScript — сначала общие типы, контракты API и утилиты, потом модули по одному. На проекте с командой из шести человек за пару месяцев доля TypeScript-файлов дошла до 60%, а ошибок типов в проде стало заметно меньше. Ещё ставлю проверку типов в CI, чтобы регресс не возвращался и план не оставался на бумаге.

• Показано понимание рисков массовой миграции
• Есть конкретные метрики: команда и доля файлов
• Отмечена автоматизация через CI, а не разовая акция

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Самый сложный случай — баг, который воспроизводился только у части пользователей и не ловился локально. В интернет-магазине заказы иногда дублировались: пользователь нажимал кнопку оплаты, запрос уходил дважды. Локально всё чисто, в логах — тишина. Мне помогают записи реальных сессий: я просматриваю сетевой водопад и вижу гонку между повторным рендером и отправкой запроса. Решение — блокировка кнопки по состоянию плюс идемпотентный ключ на бэкенде. Дубликаты упали примерно с 30 в неделю до нуля, а похожие гонки с тех пор находятся быстрее.

• Есть структура: симптом, диагностика, причина, фикс
• Конкретный измеримый результат в цифрах
• Показана работа с данными вместо догадок

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Бывает, что макет классный визуально, но дорогой в реализации и поддержке. В одном случае дизайнер настаивал на параллаксе и тяжёлых анимациях на длинной странице каталога: на слабых устройствах это давало просадку и заметные лаги при скролле. Я не спорю о вкусе — приношу данные: замеряю FPS и время рендера на среднем смартфоне, показываю, как это бьёт по метрикам. Дальше предлагаю альтернативу: анимация на CSS-трансформациях и лёгкий эффект на первом экране. В итоге выбрали компромисс, визуально почти неотличимый, а плавность выросла заметно.

• Конфликт решается аргументами и замерами, а не спором
• Предложена альтернатива, а не отказ
• Сохранены отношения с дизайнером и цель продукта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Слежу выборочно, иначе на это уходит всё время. Подписан на официальные release notes и RFC ключевых инструментов, читаю несколько профильных каналов и дайджестов, смотрю разборы конференций. Но главное — не тащить всё в прод сразу. Интересную технологию проверяю на пет-проекте или в отдельной ветке: смотрю на размер бандла, скорость сборки, кривую обучения и то, решает ли она нашу реальную боль. Если да — приношу команде короткое сравнение с планом миграции. Так за год осознанно перешли на сборщик с инкрементальной сборкой и сэкономили команде несколько часов в неделю.

• Показан критерий отбора, а не погоня за хайпом
• Есть проверка на практике и обсуждение в команде
• Приведён результат внедрения в часах экономии

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.