Есть ли опыт работы с нашим проектом
Что проверяют
Изучили ли вы компанию перед встречей и насколько быстро сможете стать полезным: знаком ли вам домен, стек, масштаб. Следом обычно спрашивают, что вы знаете о продукте и какой ваш опыт ближе всего к их задачам.
Как отвечать
Прямого опыта с чужим внутренним проектом почти никогда нет, и это нормально. Каркас ответа:
- честный ответ в первой фразе: «Напрямую нет» или «Да, пользовался вашей библиотекой». Если проект открытый, скажите, что именно делали: подключали модуль в свой сервис, заводили issue, присылали PR;
- что вы изучили: продукт как пользователь, публичные репозитории на GitHub, статьи команды на Хабре, доклады с конференций. Одна-две конкретные детали, например, что у них gRPC между сервисами и Kafka для событий;
- ближайший опыт: тот же домен (платежи, логистика, реклама) или тот же стек и масштаб. Go, PostgreSQL, Kubernetes, какая нагрузка была у вашего сервиса и какую проблему вы на нём решали;
- вопрос в ответ: какая задача сейчас главная для команды. Это переводит разговор туда, где ваш опыт пригодится.
Приводите свои цифры: RPS, объём данных, на сколько сократилось время ответа и как это измеряли (pprof, метрики в Prometheus). Если цифр нет, лучше описать задачу словами, чем придумать проценты.
Где спотыкаются
Делают вид, что знают продукт, пересказав главную страницу сайта. Первый же вопрос о том, как устроена конкретная функция, это вскрывает.
Хвастаются, что «внедрили горутины для параллельной обработки запросов». В net/http каждый входящий запрос и так обрабатывается в своей горутине, и Go-интервьюер это сразу заметит.
Отвечают общими словами «быстро адаптируюсь, готов погрузиться» без единого примера, где вы действительно быстро вошли в чужую кодовую базу.