С каким продуктом ты работал
Что проверяют
Вопрос открывает собеседование и задаёт ему темп. Проверяют три вещи: понимаете ли вы, что за продукт делали и кому он нужен, какова была ваша личная зона ответственности и соответствует ли масштаб задач уровню, на который вы претендуете. Ответ становится каркасом, из которого собеседующий вытянет технические вопросы.
Как отвечать
Держите структуру из четырёх шагов и укладывайтесь в пару минут.
- Продукт: одно предложение о том, какую задачу пользователя он решает.
- Ваша роль: за какие сервисы и части отвечали лично, где принимали решения.
- Масштаб и стек: сколько сервисов, какие хранилища и очереди, порядок нагрузки, размер команды. Если детали закрыты соглашением, опишите функционально, без внутренних названий.
- Сложное место: конкретная техническая проблема и то, как её решили.
Для позиции на Node важно, чтобы сложное место было про платформу, а не абстрактным. Подойдут долгие соединения и вебсокеты, потоковая обработка выгрузок вместо чтения файла целиком, вынос тяжёлого счёта из цикла событий, фоновые задачи и повторные попытки, ограничение числа параллельных вызовов внешнего сервиса, аккуратное завершение процесса при выкатке.
Заканчивать хорошо фразой о том, что сделали бы иначе: это показывает рефлексию и почти всегда нравится.
Где спотыкаются
Рассказывают за команду. Сплошное «мы сделали» не даёт понять личный вклад, и следующий вопрос будет неприятным: а что именно писали вы.
Заучивают историю с красивыми показателями роста продаж или выручки. Разработчик обычно не может ни измерить такой эффект, ни объяснить методику, поэтому числа лучше заменить фактами, которые вы правда контролировали: время ответа, доля ошибок, длина очереди.
Не готовы к продолжению. Про продукт рассказали складно, а на вопрос, почему выбрали именно это хранилище, как устроен деплой и что делали во время последнего инцидента, ответа нет. Собственный проект стоит освежить в памяти перед встречей.