Какие интересные задачи были на предыдущих работах
Что проверяют
Хотят понять, на каком уровне вы работали: собирали формы по макету или принимали решения, которые влияли на скорость, архитектуру и команду. Попутно оценивают, умеете ли вы рассказать о технической задаче человеку, который её не видел. Следом обычно просят углубиться: «Как мерили?», «Какие были альтернативы?»
Как отвечать
Одна-две истории, каждая по понятной схеме: контекст, в чём сложность, что сделали вы лично, результат с цифрой, вывод. Подготовьте хотя бы одну про производительность и одну про архитектуру или процессы. Во фронтенде хорошо звучат такие сюжеты:
- большие списки и таблицы: виртуализация через TanStack Virtual или
react-window, после которой страница с десятками тысяч строк перестала подвисать; - Core Web Vitals: улучшение LCP, INP или CLS с замером по полевым данным (CrUX, свой RUM), а не только в Lighthouse на своём ноутбуке;
- размер бандла: разбиение кода через динамический
import(), отказ от тяжёлой библиотеки, разбор через bundle analyzer; - миграции: переход с Webpack на Vite, с классовых компонентов на хуки, внедрение TypeScript в живой проект без остановки разработки;
- дизайн-система: общая библиотека компонентов, Storybook, визуальные регрессионные тесты.
Результат формулируйте проверяемо: «LCP на мобильных упал с 4,1 до 2,3 секунды по данным RUM», «бандл главной уменьшился с 900 до 350 КБ». Нужны ваши собственные цифры: выдуманные проценты разваливаются на первом уточнении. Если опыта мало, расскажите о пет-проекте или учебной задаче так же подробно, честно назвав её статус.
Где спотыкаются
Отвечают «у нас было много интересного» и перечисляют технологии стека. Интервьюеру нужна история с проблемой, а не список из резюме.
Приписывают себе работу команды. На вопросе «а какую часть делали вы» такой рассказ рассыпается.
Не могут объяснить, почему выбрали именно это решение. Упомянули useMemo, будьте готовы сказать, какой лишний ререндер он убрал и как вы это увидели в React Profiler.