На чём был фронтенд в проекте
Что проверяют
Работали ли вы в проекте, про который рассказываете, и видите ли границу своей ответственности. Бэкендеру не нужно знать фронтенд, но он обязан знать, с чем разговаривает его API и как выглядит контракт.
Как отвечать
Назвать то, что было на самом деле, без украшений. Если это был серверный шаблонизатор, так и сказать: для внутренней панели или админки это нормальное решение, а не признание в отсталости. Если одностраничное приложение, назвать фреймворк, сказать, кто его писал и как оно собиралось и выкатывалось.
Дальше добавить то, что относится лично к вам:
- формат контракта: REST, GraphQL или gRPC, где лежит схема, генерировались ли клиентские типы из описания;
- типовые стыки: авторизация куками или токеном в заголовке, CORS, пагинация, загрузка файлов, формат ошибок и их коды, обновления в реальном времени через веб-сокеты или опрос;
- как договаривались: кто первым фиксирует схему, как ловили расхождения, был ли мок-сервер для фронта;
- что болело: приходилось ли сокращать число запросов, делать пакетные ручки или отдельный ответ под конкретный экран.
Если фронтенд был не ваш и вы его не трогали, скажите прямо и переведите разговор на контракт. Там ваша компетенция и видна.
Где спотыкаются
Пересказывают модный стек, которого в проекте не было. Достаточно одного уточняющего вопроса про сборку, маршрутизацию или состояние, чтобы стало видно: человек читал, а не работал.
Второе: путают фреймворк с экосистемой вокруг него. Библиотеку состояния называют фреймворком, серверный рендеринг считают частью бэкенда, а сборщик вообще не могут назвать.
Третье: отвечают одним словом. Вопрос задан для разговора, и односложный ответ обрывает единственную возможность рассказать про API, которое делали именно вы.