Вернуться в каталог собеседований

Самое полное интервью Golang Middle

Длинное учебное mock-интервью для Go-разработчика уровня Middle с техническими вопросами, разбором примеров и сессией системного дизайна. В конце — подробный фидбек кандидату и презентация менторской программы канала.

Эйч Навыки — менторская программа
  • Опубликовано на YouTube:
  • Просмотры на YouTube: 86 тыс.
  • Лайки на YouTube: 1,7 тыс.
Открыть на YouTube

Таймлайн

Коротко о видео

Это учебная запись пробного собеседования на Go Middle: кандидат рассказывает о переходе с C# на Go, а интервьюер последовательно проверяет знания языка, конкурентности, баз данных, сетей и системного дизайна. Разбираются слайсы, map, интерфейсы, каналы, goroutine, ошибки, context, тестирование, PostgreSQL, Kafka и проектирование сервиса уведомлений. В финале интервьюер даёт кандидату обратную связь: сильнее проработать конкурентность, утечки goroutine, указатели и уверенность в системном дизайне.

Затронутые темы

Что взять на заметку

  • Для Go-интервью нужно уметь объяснить устройство slice: header содержит указатель, length и capacity; изменение элементов видно снаружи, а результат append и рост capacity нельзя безоговорочно переносить между версиями Go.
  • Map нельзя безопасно одновременно изменять из нескольких goroutine без синхронизации; выбор между mutex/RWMutex, sync.Map и иной архитектурой должен зависеть от характера чтений и записей.
  • Канал стоит закрывать один раз владельцем жизненного цикла, обычно на более высоком уровне, а при чтении после закрытия проверять второй результат операции receive.
  • Context применяют для отмены и дедлайнов по цепочке вызовов; в него не стоит складывать изменяемое состояние сервиса — его лучше передавать явными параметрами или структурой зависимостей.
  • Нужно знать ловушку типизированного nil в error: интерфейс может быть не nil, если содержит типизированный nil-указатель; для проверки и оборачивания ошибок обсуждаются errors.Is, errors.As и fmt.Errorf с %w.
  • При проектировании доставки уведомлений полезно разделять приём, durable-хранение и отправку, вводить уникальный идентификатор сообщения для дедупликации, а зависшие задачи возвращать в обработку контроллером по тайм-ауту.
  • В системном дизайне важно сначала уточнять нагрузку, гарантии, задержки, число дата-центров и допустимые компромиссы, а не сразу предлагать Kafka или распределённую БД.

Рекомендуем посмотреть