Какие есть мысли по реализации нашего сайта
Что проверяют
Посмотрели ли вы продукт до собеседования и умеете ли оценить фронтенд глазами инженера, а не пользователя. Заодно проверяют такт: критиковать чужой код при его авторах нужно аккуратно. Следом обычно спрашивают, что бы вы сделали первым делом, если бы пришли в команду.
Как отвечать
Готовиться нужно заранее: полчаса с DevTools дают материал на хороший разговор. Что стоит посмотреть:
- производительность: отчёт Lighthouse и Core Web Vitals, то есть LCP, INP и CLS. Во вкладке Network видно размер бандла, число запросов, форматы картинок, работают ли кэширование и сжатие;
- рендеринг и SEO: отдаёт ли сервер готовый HTML или страница пустая до загрузки JS, заполнены ли
title,descriptionи разметка Open Graph. Для каталога или контентного сайта клиентский рендеринг без SSR обычно заметная проблема; - адаптивность и доступность: как сайт выглядит на ширине телефона, работает ли навигация с клавиатуры, есть ли
altу картинок, хватает ли контраста; - стек: по бандлу и расширениям вроде Wappalyzer видно фреймворк и часто его версию;
- продуктовые шероховатости: длинная форма, непонятное сообщение об ошибке валидации, загрузка без скелетона.
Строить ответ удобно так: что понравилось и почему, две-три конкретные зоны роста с метрикой, гипотеза о причине и способ её проверить. Например: «LCP на мобильном около 4 секунд, похоже, мешает крупная картинка в первом экране без preload, я бы начал с неё». Закончите вопросом об ограничениях команды: неудачное решение часто объясняется сроками или легаси, а не незнанием.
Где спотыкаются
Не открывают сайт заранее и отвечают общими словами про React, SASS и адаптивность. Это видно сразу.
Разносят сайт в пух и прах. Даже если проблем много, тон «здесь всё плохо» подсказывает, как вы будете вести себя на код-ревью.
Предлагают переписать всё с нуля на модном стеке или «перейти на микросервисы». Сильнее выглядят точечные улучшения с измеримым эффектом, которые можно сделать без остановки разработки.