Какие библиотеки часто используешь

Не отвечайте на этот вопрос как на инвентаризацию package.json. Сильнее звучит ответ, где вы показываете свой набор инструментов и объясняете, зачем каждый из них появлялся в проекте.

Удобная структура такая: категория, библиотека, задача, ограничение. Например, для форм я использовал React Hook Form, потому что он хорошо работает с неконтролируемыми полями и снижает лишние рендеры. Но схему валидации и сообщения об ошибках нужно согласовывать с backend-контрактом. Иначе пользователь увидит разные правила на клиенте и сервере.

Так вы показываете не только знакомство с названиями. Вы показываете, что умеете принимать технические решения.

Начните с 4-6 категорий, которые реально встречались в вашем опыте. Не называйте все библиотеки, которые вы видели в статьях или документации. Если опыта с инструментом мало, лучше сказать это прямо и связать его с похожей задачей.

Пример ответа, который можно адаптировать:

Чаще всего я работал с React и экосистемой вокруг него. Для запросов использовал fetch или Axios. Для сложного состояния брал Redux Toolkit. Для серверного состояния использовал TanStack Query. Для форм работал с React Hook Form. Для тестов использовал Jest, Vitest, React Testing Library и иногда Playwright. В выборе смотрю не только на удобство API, но и на поддержку, размер, TypeScript, SSR и то, насколько инструмент понятен команде.

Замените список на свой. Если вы не использовали TanStack Query, Zustand или Playwright, не добавляйте их только ради впечатления.

Хорошо, если ваш ответ покрывает разные части frontend-разработки. Но в каждой части важно показать практический смысл.

Например, про HTTP не ограничивайтесь фразой про Axios. Добавьте, как обрабатываете ошибки, отмену запроса, повторную загрузку, авторизацию, одинаковый формат ответа и устаревшие ответы при быстром переключении фильтров или страниц. Про тесты скажите, какие сценарии проверяли, а не только название раннера.

Если называете UI-kit, markdown-рендерер или библиотеку для rich text, добавьте проверку безопасности и доступности. Нельзя бездумно отключать экранирование или прокидывать внешний HTML в интерфейс. Это может привести к XSS и краже токенов из доступного клиенту окружения.

На интервью опасно звучит позиция, что вы всегда берете один и тот же инструмент. В реальном проекте выбор зависит от команды, архитектуры, требований к скорости, SSR, доступности, безопасности клиентских данных, тестов и будущей поддержки.

Пример плохого ответа:

Я всегда ставлю Axios, Redux и styled-components, потому что мне так удобнее.

Что здесь не так: вы не показываете критерии. Интервьюер может спросить, зачем Redux для простой формы или зачем отдельный HTTP-клиент, если в проекте уже есть обертка над fetch. Такой подход ведет к лишнему bundle, лишним рендерам, разным правилам обработки ошибок и более дорогим обновлениям. Безопаснее сказать, что у вас есть привычные инструменты, но вы выбираете их под задачу и правила команды.

Если вы упоминаете fetch или Axios, полезно знать базовую ловушку обработки ошибок. fetch не считает HTTP-статусы 400 и 500 ошибкой промиса. Ошибкой будет, например, сетевая проблема.

// Плохо: 404 или 500 попадут в обычный путь выполнения.
const response = await fetch("/api/profile");
const data = await response.json();

Что сломается в UI: компонент может показать пустой профиль как успешную загрузку, оставить старые данные после ошибки или не перевести экран в error state. Если пользователь быстро сменит страницу или фильтр, старый ответ может перетереть новые данные.

Более безопасный вариант:

const response = await fetch("/api/profile");

if (!response.ok) {
  throw new Error(`Request failed: ${response.status}`);
}

const data = await response.json();

В компоненте добавьте обработку loading, error, empty state и отмену через AbortController. Можно использовать принятую в проекте обертку или библиотеку для запросов. Это не значит, что fetch хуже Axios. Это значит, что у каждого инструмента есть контракт, который нужно понимать. Такой пример хорошо усиливает ответ, потому что показывает практику, а не спор о вкусах.

Не пытайтесь доказать, что ваш привычный стек единственно правильный. Лучше показать переносимый опыт. Если вы работали с React Hook Form, а в компании Formik, скажите, что понимаете общие задачи форм: состояние полей, touched, ошибки, async validation, отправку, reset и связь с backend-ошибками.

Хорошая формулировка:

С Formik я работал меньше, чем с React Hook Form, но задачи понимаю: валидировать поля, показывать ошибки, не терять состояние и корректно отправлять данные. Я бы быстро посмотрел принятые в команде паттерны и не стал бы менять библиотеку без причины.

Такой ответ звучит спокойно. Он не выдумывает опыт и не обесценивает стек компании.

Ваша цель не в том, чтобы назвать максимум библиотек. Цель в том, чтобы показать, что вы умеете выбирать зависимости осознанно и понимаете цену каждого инструмента.

Держите ответ в формате: использовал X для Y, потому что Z, но учитываю W. Этот формат помогает отвечать и про React-экосистему, и про тесты, и про утилиты, и про стили.