Вернуться в видеотекуСобеседование на Go-разработчика с тимлидом из Avito | Эйч Навыки
Публичное mock-интервью на Go с разбором типичных ловушек языка, конкурентности и кэширования. После задач участники обсуждают качество ответов, менторство и вопросы карьеры разработчика.
- Направление
- Backend
- Формат
- Мок-собеседование
- Компания
Авито- Длительность
- 1 ч 50 мин
Коротко о видео
Это публичное 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 честно предложить свериться с документацией.