31:04Разбор live coding собеседования Go-разработчика
Третья часть записи реального технического собеседования на Senior Go-разработчика с авторскими комментариями. Кандидат разбирает диагностику медленного бэкенда и запросов PostgreSQL, а затем в live coding реализует внутрипроцессный горячий кэш на map и RWMutex; интервьюеры уточняют работу defer, обработку отсутствующих значений и ограничение кэша 200 элементами.
it father.
Открыть на YouTube- Опубликовано на YouTube:
- Просмотры на YouTube: 3,8 тыс.
- Лайки на YouTube: 72
Таймлайн
Коротко о видео
Ролик сочетает запись третьей части реального технического интервью и комментарии автора. Сначала кандидат предлагает план расследования медленного 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 элементов требует явной политики вытеснения и структуры для поиска удаляемой записи: одного счётчика при бизнесовых ключах недостаточно.
