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

Собеседование на Go-разработчика с тимлидом из Avito | Эйч Навыки

Публичное mock-интервью на Go с разбором типичных ловушек языка, конкурентности и кэширования. После задач участники обсуждают качество ответов, менторство и вопросы карьеры разработчика.

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

Открыть на YouTube

Таймлайн

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

Это публичное mock-интервью на Go: тимлид Александр из Avito беседует с Евгением, Go-разработчиком X5 Tech, и разбирает три задачи. Обсуждаются замыкания и goroutine, конкурентный доступ к map, интерфейс с typed nil, а также кэширование внешнего курса с периодическим обновлением, отменой через context и защитой от race condition. В финале интервьюер даёт Евгению обратную связь: знания есть, но на собеседовании важно не спешить, проговаривать решения и проектировать код устойчивым к будущим изменениям; затем идёт Q&A о менторстве и карьере.

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

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

  • Для goroutine, запускаемых в цикле, отдельно проверяйте захват переменной цикла и ожидайте завершения через sync.WaitGroup или другую явную синхронизацию: иначе main может завершиться раньше выполнения goroutine.
  • Обычная map в Go не безопасна для одновременного чтения и записи. Даже если текущий пример кажется безопасным, интервьюер советует проектировать код так, чтобы его было трудно сломать последующим изменением; применимы sync.RWMutex, sync.Mutex или подходящий atomic-тип.
  • Интерфейс, содержащий typed nil-указатель, сам не равен nil: у него задан динамический тип, поэтому проверка interface != nil пройдёт, а вызов метода может привести к ошибке.
  • Для редко меняющегося результата дорогого внешнего запроса подходит кэш с начальной загрузкой и обновлением по time.Ticker; одних идей о кэше недостаточно — нужно также защитить совместный доступ к значению.
  • Фоновую goroutine обновления следует останавливать через context cancellation; context лучше передавать в вызовы, а не хранить полем долгоживущей структуры.
  • На mock-интервью Евгению помогало время на рассуждение: интервьюер рекомендует сначала изучить условие, вслух зафиксировать допущения и только затем давать ответ, а при забытом API честно предложить свериться с документацией.

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