Go-код на интервью
Этот раздел готовит к формату, где нужно быстро понять незнакомый Go-код, безопасно изменить его и аргументировать решение. Оценивают не объём абстракций, а сохранение контракта, корректность на ошибках и способность заметить эксплуатационные риски.
Зачем это на интервью
В live coding и code review кандидат получает неполный контекст. Сильный ответ начинает с наблюдаемого поведения и инвариантов, называет риски, предлагает минимальное изменение и объясняет, как его проверить.
Минимум для E4
- Читать путь данных: вход, валидация, зависимости, ошибка, выход и cleanup.
- Отличать
nil-ошибку, обёрнутую ошибку и ошибку, пригодную для классификации черезerrors.Is/errors.As. - Формулировать маленький интерфейс у потребителя, а не копировать API реализации.
- Проверять закрытие ресурсов, отмену
context.Context, data race и обратную совместимость экспортов.
Углубление для E5/Senior
Оценивайте изменение как контракт: миграция пользователей, метрики и логи, SLO, rollback и границы владения. Предлагайте рефакторинг по этапам с тестами поведения, а не «переписывание для красоты».
Ключевые понятия
| Тема | Что показать в ответе |
|---|---|
| Чтение кода | Сначала контракт и инварианты, затем ветки и побочные эффекты. |
| Рефакторинг | Поведение фиксируется тестом; структура меняется малыми шагами. |
| Observability | Ошибка сохраняет причину, лог имеет контекст без секретов, метрика ограничена по cardinality. |
| Mockability | Интерфейс мал, определён рядом с потребителем; fake проверяет результат, не внутренние вызовы. |
| Public API | Экспорты документированы, zero value и nil-правила ясны, изменение совместимо. |
| Review | Проверяются concurrency, ресурсы, error path, API и измеренная производительность. |
Темы
- Чтение кода и рефакторинг
- Ошибки и observability
- Контракты интерфейсов и mockability
- Публичный API пакета
- Code review и идиоматичный Go
Типовые вопросы
- Как начать code review?
- С контракта и рисков корректности: ошибки, ресурсы, concurrency, безопасность и совместимость; стиль — после них.
- Что доказывает безопасный рефакторинг?
- Тесты поведения до и после изменения, малый diff и проверки, релевантные затронутому коду.
- Где определять интерфейс?
- Рядом с потребителем и только с нужными ему методами.
- Что важно в ошибке?
- Безопасный контекст, сохранённая причина для классификации и отсутствие секретов во внешнем ответе/логах.
- Когда абстракция оправдана?
- Когда есть повторяющаяся изменчивость или граница внешнего эффекта; не как предположение о будущем.
Практика
- За 20 минут разберите незнакомый handler: выпишите контракт, ветки ошибок, ресурсы и три риска.
- Для каждого изменения добавьте или измените тест, который фиксирует внешнее поведение.
- Проведите ревью pull request по чек-листу последней темы и разделите замечания на blocking и non-blocking.
Критерии готовности: вы можете вслух объяснить изменение через входы, выходы, инварианты, ошибки и проверку; код проходит gofmt, go vet ./... и go test -race ./... в соответствующем проекте.
Частые ошибки и ловушки
- Начинать с косметического рефакторинга, не выяснив контракт и тестовое покрытие.
- Подменять смысл ошибки строкой и терять возможность
errors.Is. - Вводить общий «универсальный» интерфейс или mock ради одной проверки вызова.
- Считать отсутствие замечаний о стиле доказательством отсутствия race, leak или регрессии API.
Связанные темы
Go · Observability · Тестирование · Интервью-практика
Источники
- Effective Go — проверено 2026-10-02.
- Go Code Review Comments — проверено 2026-10-02.
- Go blog: Errors are values — проверено 2026-10-02.