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

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

Значение this определяется тем, как вызвана функция. При обычном вызове — глобальный объект или undefined в строгом режиме; у метода — объект перед точкой; у конструктора — новый объект; в стрелочных функциях this берется из внешнего лексического окружения и не переопределяется. Привязку задаю через call и apply, если вызов разовый, и через bind, если нужен постоянный контекст. Еще применяю сохранение ссылки на this в переменную — например, в обработчиках событий, где контекст теряется. В коде чаще всего помогают именно bind для колбэков и стрелочные функции внутри классов.

• Перечислены все правила, а не только call и bind
• Есть практический пример: обработчики событий и колбэки
• Показана разница между разовой и постоянной привязкой

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

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

Замыкание — это когда функция сохраняет доступ к переменным из области видимости, где она создана, даже после того как внешняя функция завершилась. Использую постоянно: например, мне приходилось делать debounce для поиска по каталогу — счетчик таймера живет в замыкании и не попадает в глобальную область. В другом проекте на замыканиях строился приватный счетчик показов для аналитики: снаружи состояние не изменить, а внутри функции оно сохраняется между вызовами. Это уменьшило объем кода примерно на 20% по сравнению с вариантом через класс.

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

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

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

У каждого объекта есть скрытая ссылка на прототип. При вызове obj.method() движок сначала ищет метод в самом объекте, не находит — идет по ссылке в прототип, потом выше, пока не дойдет до конца цепочки; если метода нет нигде, будет ошибка. Свойства из прототипа читаются, но присваивание создает собственное свойство объекта и не меняет прототип. Проверить связь можно через hasOwnProperty и Object.getPrototypeOf. На практике это помогает объяснять баги с наследованием и не дублировать методы в памяти: методы класса лежат в прототипе и общие для всех экземпляров.

• Пошагово описан поиск по цепочке прототипов
• Отмечена разница между чтением и присваиванием
• Есть связь с практикой: баги наследования и экономия памяти

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

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

Для себя я держу простое правило: == сравнивает значения с неявным приведением типов, а === — сначала типы, потом значения. Ловушки как раз в приведении: пустая строка и ноль считаются равными, null и undefined равны только между собой, массив при сравнении с числом превращается в строку, а NaN не равен даже самостоятельно себе. Поэтому в рабочем коде я почти всегда пишу ===, а == оставляю только для проверки на null или undefined одной строкой. При чистке нестрогих сравнений в старом модуле — около сорока мест — тестовых падений стало меньше примерно на треть, и ревью пошло быстрее.

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

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

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

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

• Точные термины: область видимости и temporal dead zone
• Есть практический вывод про выбор const и let
• Пример из опыта с измеримым результатом

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

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

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

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

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

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

Call stack — это стек вызовов: движок выполняет синхронный код строго по одному кадру. Когда стек пустеет, event loop сначала разбирает очередь микрозадач — промисы, queueMicrotask, — и только потом берёт одну макрозадачу: таймеры, события, ввод-вывод. После каждой макрозадачи микрозадачи снова вычерпываются до конца, поэтому бесконечная цепочка промисов может заморозить интерфейс. Для себя я держу правило: тяжёлые вычисления не кладу в синхронный поток, а дроблю или выношу в воркер — так на одном проекте удалось снизить просадки интерфейса при рендере больших списков примерно на четверть.

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

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

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

Порядок будет a, b, c. Первым идёт синхронный console.log('a') — он в call stack. Затем стек пустеет, и event loop вычерпывает очередь микрозадач: колбэк then у промиса попадает именно туда, поэтому 'b' логируется вторым. setTimeout создаёт макрозадачу, а они выполняются только на следующих итерациях цикла, после того как микрозадачи опустошены до конца. Поэтому 'c' окажется последним. На практике это значит, что гарантировать порядок надёжнее микрозадачами, а не таймерами: при разборе одного инцидента мы нашли два места, где на это опирались, и после правки тесты стали стабильнее.

• Дан верный порядок a, b, c
• Объяснена причина, а не только ответ
• Добавлен практический вывод про таймеры

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

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

По сути async/await — это синтаксический сахар над промисами, поведение то же, отличается читаемость и обработка ошибок. Промисы удобны для коротких цепочек, для параллельных сценариев через Promise.all и когда результат передаётся дальше как значение. Async/await выбираю, когда логика ветвится, есть циклы и последовательные шаги с проверками: тогда try/catch читается линейно и отладка проще. В одном проекте рефакторинг цепочки из пяти then на async/await дал сокращение функции примерно на треть и убрал пару ошибок с потерей контекста this. Смешивать не запрещено: внутри async-функции спокойно возвращаю Promise.all.

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

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

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

Параллельно запускаю через Promise.all, если нужны все результаты и падение любого означает провал всей операции. Если часть данных не критична, беру Promise.allSettled — он всегда возвращает статусы, и дальше фильтрую rejected, показываю то, что загрузилось, а упавшие запрашиваю повторно с ограничением по числу попыток. Ещё вариант — обернуть каждый запрос в catch и вернуть null, тогда Promise.all не отклонится. В одном сервисе на карточке товара было пять независимых блоков: после перехода на allSettled и точечные ретраи доля пустых экранов снизилась примерно вдвое, при этом время загрузки не выросло.

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

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

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

Отмена делается через AbortController: создаю контроллер, передаю его signal в fetch и вызываю abort на нужном событии. Запрос завершается ошибкой с именем AbortError, её важно отличать от реальных сбоев и не показывать пользователю сообщение об ошибке. Нужно это в поиске с вводом текста — при новом символе отменяю предыдущий запрос, чтобы ответы не пришли в неправильном порядке; при размонтировании компонента или переходе на другую страницу; при таймауте через AbortSignal.timeout. В интерфейсе с живым поиском такая отмена убрала гонки результатов и заметно снизила число лишних обращений к серверу.

• Назван точный механизм отмены и тип ошибки
• Перечислены три реальных сценария применения
• Отмечен эффект на нагрузку и стабильность

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

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

Чаще всего — деструктуризация, параметры по умолчанию, шаблонные строки, стрелочные функции, операторы spread и rest, optional chaining и nullish coalescing, методы массивов map, filter, reduce, а также const и let вместо var. Это про читаемость и меньше ошибок: деструктуризация убирает длинные обращения к полям, optional chaining спасает от падения на вложенных данных, spread даёт иммутабельные обновления состояния. В проекте с таблицей на несколько тысяч строк отказ от мутаций в пользу spread и методов массивов заметно упростил поиск багов: пара спорных мест перестала воспроизводиться вообще.

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

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

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

В одном из проектов на React и Node.js мне приходилось оптимизировать размер бандла. Моя задача — ускорить загрузку и убрать неиспользуемый код. Я перевожу библиотеки и часть кода на ES-модули: у них статическая структура импортов и экспортов, поэтому сборщик видит зависимости ещё до выполнения. CommonJS с require динамический: вызов может быть внутри условия, экспорт формируется в рантайме, и надёжно удалить лишнее не получается. Статический анализ ESM и флаг sideEffects дают tree shaking. В результате удалось сократить бандл почти на 30 процентов, а время загрузки — на секунду.

• Чётко объясняет разницу между статическими и динамическими модулями
• Показывает понимание tree shaking и sideEffects
• Подкрепляет ответ конкретным результатом: минус 30% бандла

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

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

Map хранит ключи любого типа, а не только строки, сохраняет порядок вставки и даёт готовые size, has, delete; объект удобнее для простых структур и сериализации в JSON. В одном проекте переход на Map для агрегации по числовым идентификаторам заметно ускорил пересчёт списка на 12 000 позиций и убрал лишние преобразования ключей. Set выбираю, когда важен факт наличия, а не порядок и не повторы: собрать уникальные значения, проверить, что элемент уже в выборке, отфильтровать дубли. Массив остаётся для упорядоченных данных, где нужны индексы и методы вроде map и filter.

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

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

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

Смысл в том, что обработчик вешается один раз на общий контейнер, а конкретный элемент определяется через event.target и ближайший родитель closest. Событие всплывает от цели вверх, поэтому один слушатель закрывает сотни элементов и экономит память. Применяю там, где разметка динамическая: строки таблицы, карточки, пункты меню, которые постоянно добавляются и удаляются. Переход со слушателя на каждую строку на делегирование в списке на несколько тысяч строк заметно снизил потребление памяти и упростил удаление узлов. Не использую подход для событий без всплытия и там, где нужна строгая изоляция логики.

• Объясняет механизм всплытия и поиск цели
• Приводит реальный выигрыш по памяти
• Честно называет границы применимости

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

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

Дебаунс вызывает функцию один раз после паузы в потоке событий, троттлинг — не чаще заданного интервала. Первый подходит для поиска по вводу, валидации формы, автосохранения черновика; второй — для скролла, resize и перетаскивания. Реализую через замыкание: в дебаунсе храню таймер и сбрасываю его через clearTimeout, в троттлинге — метку времени последнего вызова. На практике дебаунс в 300 миллисекунд на строке поиска сократил число запросов примерно в пять раз, а троттлинг на скролле убрал просадку кадров на длинных списках. Обычно пишу такие утилиты самостоятельно или беру готовые из lodash.

• Чётко разводит два понятия
• Перечисляет подходящие сценарии применения
• Подкрепляет ответ числом из практики

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

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

Выведется три раза 3. Причина в том, что var создаёт одну переменную на всю функцию, а колбэки читают её значение уже после завершения цикла, когда счётчик равен трём. Исправить можно несколькими способами. Заменить var на let — тогда на каждой итерации создаётся своя привязка и получим 0, 1, 2. Либо передать значение параметром в обёртку вокруг setTimeout, либо применить bind. Ещё вариант — forEach по массиву из трёх элементов: там у каждого колбэка свой аргумент. По умолчанию использую let, а var встречаю только в старом коде.

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

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

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

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

• Называет корень проблемы — гонку запросов
• Даёт понятное решение из трёх шагов
• Подтверждает эффект измеримым результатом

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

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

Кэш я рассматриваю как отдельный слой между UI и HTTP-клиентом. Ключ строю из метода, URL и нормализованных параметров, значение храню вместе с временем записи и TTL. При запросе проверяю возраст: если данные свежие — отдаю из памяти, если нет — иду в сеть, а на время полёта запроса кладу промис в карту, чтобы десять одинаковых вызовов не превратились в десять запросов. Для мутаций добавляю точечную инвалидацию по префиксу ключа, TTL задаю параметром, а не константой, и ограничиваю размер кэша вытеснением по LRU. Плюс поддерживаю условные запросы. В одном проекте такой слой снизил число обращений к API примерно на 60%.

• Показан конкретный план: ключ, TTL, дедупликация запросов
• Есть детали про инвалидацию и ограничение размера кэша
• Подтверждено измеримым результатом — минус 60% запросов

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

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

Самая тяжёлая история — гонка при быстрой смене фильтров в поиске. Пользователь меняет условие, старый запрос приходит позже нового, и список показывает устаревшие данные. Воспроизвести это стабильно долго не получалось: баг ловился примерно в 5% сессий. Я ввожу идентификатор запроса и отбрасываю ответы, не совпадающие с последним, проверяю отмену через контроллер и убираю утечку таймеров. Отдельно пишу тест с искусственной задержкой сервера. В результате жалобы на неверную выдачу прекратились, а тест остался в регрессии.

• Чётко назван класс бага — гонка асинхронных ответов
• Есть и починка, и защита: тест с задержкой сервера
• Цифра 5% сессий делает проблему ощутимой

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

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

Была ситуация с модулем расчёта отчётов на несколько тысяч строк: функции по триста строк, глобальные переменные, вложенные колбэки. Переписывать всё сразу смысла не имело. Мой подход — сначала покрыть тестами текущее поведение, потом вынести чистые расчёты в отдельные модули, заменить колбэки на async/await и убрать неявные глобальные зависимости. Изменения шли небольшими порциями и деплоились отдельно от новых фич. Через три недели модуль покрыт тестами, а время на доработку похожей функциональности сократилось примерно вдвое.

• Показан безопасный поэтапный подход вместо переписывания
• Упомянуты тесты как страховка при рефакторинге
• Есть конкретный результат по времени доработки

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

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

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

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

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

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

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

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

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