Разбор live coding собеседования Go-разработчика

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

Ролик сочетает запись третьей части реального технического интервью и комментарии автора. Сначала кандидат предлагает план расследования медленного HTTP-запроса: поиск по логам и trace ID, анализ SQL через EXPLAIN ANALYZE, профилирование Go-кода с pprof и проверку цепочек синхронных вызовов. Затем при запрете Redis и ClickHouse он предлагает горячий кэш в памяти процесса. В live coding обсуждаются map, RWMutex, Get/Set, nil-инициализация, пропущенный return и проверка базового сценария. В финале интервьюер спрашивает о корректном ограничении кэша до 200 записей.

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

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

• При расследовании медленного endpoint сначала локализуют задержку по логам и trace ID, затем отдельно проверяют SQL-план, Go-код и синхронные downstream-вызовы.
• Запись в nil map в Go вызывает panic, поэтому map нужно инициализировать до Set; чтение value, ok отличает отсутствие ключа от zero value.
• RWMutex защищает общую map и уместен при преобладании параллельных чтений, но не является автоматической заменой Mutex.
• defer выполняется при возврате из окружающей функции в обратном порядке; os.Exit не запускает отложенные вызовы.
• Лимит в 200 элементов требует явной политики вытеснения и структуры для поиска удаляемой записи: одного счётчика при бизнесовых ключах недостаточно.