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

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

Публичное мок-интервью на Middle Go-разработчика: кандидат сначала разбирает проблемный код, затем решает и обсуждает задачи по конкурентности в Go. Интервьюер корректирует ответы о транзакциях, SQL-инъекциях, аутентификации, cookie, goroutine scheduler, каналах, select, WaitGroup и worker pool. В финале он даёт кандидату обратную связь, после чего идёт Q&A о подготовке к собеседованиям и менторской программе.

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

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

• На code review следует проверять не только стиль: nil map вызовет panic при записи, интерфейс должен соответствовать возвращаемой реализации, а проверка длины строки должна учитывать Unicode.
• Не стоит передавать готовый SQL в репозиторий: репозиторий должен принимать параметры и сам строить параметризованный запрос. Проверки прав и последующее обновление полезно выполнять в одной транзакции, чтобы не работать с устаревшими данными.
• В аутентификации нельзя хранить или сравнивать пароль как обычную строку: пароль должен храниться в виде хеша и проверяться специализированным алгоритмом. Отсутствие пользователя не должно возвращаться как успешный ответ.
• Нужно различать атрибуты cookie: Secure ограничивает передачу HTTPS-соединениями, а HttpOnly запрещает доступ к cookie из JavaScript. Проверку авторизации удобно выносить в middleware.
• Общий счётчик, изменяемый несколькими goroutine, требует синхронизации через mutex или atomic; локальная map, создаваемая на запрос, не становится общей только из-за наличия goroutine.
• Отправка в небуферизированный канал блокируется без готового получателя; запись в закрытый канал вызывает panic. Выходной канал закрывают лишь после завершения всех отправителей, например синхронизировав их через WaitGroup.
• В worker pool канал входных jobs не должен закрываться самим пулом, если он создан внешним кодом; для управляемого завершения обработчики должны учитывать отмену context через ctx.Done().
• По мнению интервьюера, кандидату полезнее практиковать code review и задачи на конкурентность: знания часто проявлялись после наводящего вопроса, а не сразу.