Вернуться в видеотеку

Открытое собеседование на Middle Go-разработчика

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

Источник: Эйч Навыки — менторская программа

Открыть на YouTube

Таймлайн

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

Открытое учебное собеседование на позицию Middle Go-разработчика: кандидат с опытом PHP отвечает на вопросы интервьюера о Go и системном дизайне. Разбирают диагностику 500/таймаутов, интеграцию с медленным провайдером координат, кэширование в Redis, воркер-пулы и Circuit Breaker. Основная техническая часть посвящена goroutine, каналам, context, select, планировщику Go, а также интерфейсам и принципам SOLID; в финале интервьюер даёт кандидату рекомендации по подготовке.

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

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

  • Для расследования HTTP 500 сначала нужны логи; при таймаутах следует сопоставлять логи, метрики и distributed tracing, чтобы найти медленный внешний вызов или участок цепочки.
  • Для API с требованием ответа за 300 мс при пятисекундном внешнем провайдере обсуждается фоновое обновление координат воркерами и выдача последнего значения из Redis; история перемещений потребует отдельного постоянного хранилища.
  • При массовом опросе внешнего сервиса нужны ограничение числа воркеров/соединений, контроль нагрузки и, по обсуждению интервьюера, Circuit Breaker на период нестабильности провайдера.
  • Небуферизированный канал в Go блокирует отправителя до получения значения; отправка в канал без читателя может привести к deadlock, а работа с nil-каналом также блокируется.
  • Для отмены фоновой работы нужно передавать context, слушать ctx.Done() через select и вызывать cancel, обычно через defer, чтобы освободить связанные ресурсы.
  • По оценке интервьюера, кандидату стоит укрепить теорию goroutine, каналов, context, асинхронности, worker pool и архитектуры, а не только опираться на практические кейсы.
  • Интерфейсы в Go обсуждаются как узкие контракты на стороне потребителя: бизнес-логика зависит только от нужных методов, а реализации можно заменять и расширять через композицию.

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