Был ли опыт настройки сборщиков

Что проверяют

Работали ли вы со сборкой руками или только запускали npm run dev в готовом шаблоне. Следом спрашивают, какую конкретно проблему решала ваша настройка и чем Vite отличается от webpack.

Как отвечать

Это вопрос про опыт, поэтому каркас строится на вашем случае, а не на пересказе документации:

• контекст: какой проект, какой сборщик и почему он. Webpack 5 в старом монолите, Vite в новом SPA, Turbopack внутри Next.js, Rspack как быстрая замена webpack с совместимой конфигурацией;
• проблема: тяжёлый бандл, медленный старт dev-сервера, долгая сборка в CI, переезд с Create React App, который официально объявлен устаревшим;
• что сделали: разбили код через динамический import() и React.lazy, настроили splitChunks или manualChunks, алиасы путей, переменные окружения, source maps, прокси к API в dev-сервере;
• как измеряли: размер бандла до и после в webpack-bundle-analyzer или rollup-plugin-visualizer, время сборки, LCP в Lighthouse.

Цифры должны быть ваши. «Бандл уменьшился с 1,8 МБ до 900 КБ, когда moment.js заменили на date-fns» звучит убедительно, а круглое «ускорили загрузку на 30%» без объяснения выглядит шаблоном.

Если сборку с нуля вы не настраивали, так и скажите, и покажите, что понимаете, что внутри: чем лоадер отличается от плагина, как работает tree shaking и почему ему мешают CommonJS-модули, что Vite в dev-режиме отдаёт браузеру нативные ES-модули без бандлинга, а для продакшена собирает полноценный бандл. Хорошо, если есть пет-проект, где вы сами перенесли конфигурацию с CRA на Vite.

Где спотыкаются

Перечисляют file-loader и OptimizeCSSAssetsPlugin. В webpack 5 их заменили встроенные asset modules и CssMinimizerPlugin, и такой список выдаёт знания времён webpack 4.

Называют Gulp сборщиком наравне с webpack. Это таск-раннер, модульные зависимости он не разрешает.

Не могут объяснить ни одной строки своего конфига. Интервьюер обязательно попросит разобрать одну настройку, и «скопировал из статьи» здесь хуже честного «не настраивал».