Расскажите про опыт работы и выполняемые задачи

Что проверяют

Реальность опыта и его глубину. По рассказу видно, писали ли вы на Go боевой сервис или перенесли в него привычки другого языка. Уточняющие вопросы почти наверняка уйдут в конкурентность и эксплуатацию.

Как отвечать

Сначала сервис: что делает, кто его вызывает, какая нагрузка и требования по задержкам. Потом ваш участок. Потом детали, которые невозможно выдумать.

• транспорт: HTTP или gRPC, как описан контракт, как живёте с его изменениями;
• конкурентность: где горутины действительно нужны, как ограничиваете их число, как отменяете работу через context;
• ошибки: обёртывание через %w, разбор через errors.Is и errors.As, что отдаёте наружу, а что оставляете в логе;
• завершение: корректная остановка сервиса, дренаж соединений, почему утечка горутин опаснее, чем кажется;
• тесты: табличные тесты, httptest, база в контейнере для интеграционных;
• эксплуатация: метрики, трассировка, ваши действия во время инцидента.

tests := []struct {
	name string
	in   string
	want int
}{
	{"пусто", "", 0},
	{"один", "a", 1},
}

Если опыта на Go меньше, чем на прошлом языке, скажите прямо и покажите, что уже перестроились: здесь меньше слоёв абстракции, а ошибка возвращается значением, а не бросается исключением.

Где спотыкаются

Рассказ сводится к написанию обработчиков на популярном фреймворке. Нет нагрузки, нет базы, нет отказов, нет эксплуатации. На вопрос, что происходило при недоступности соседнего сервиса, ответа не находится.

Второе: называют паттерны из чужого мира. MVC и микросервисы это не шаблоны проектирования, и код на Go в такие термины укладывается плохо. Гораздо сильнее звучит рассказ о том, как нарезаны пакеты и почему интерфейс объявлен на стороне потребителя.

Третье: присваивают командный результат. Фраза про поднятую пропускную способность без деталей, чем мерили и что именно меняли, ломается на первом уточнении. Честное разделение работы команды и своего куска выглядит выигрышнее.