Готов ли ты писать код сейчас?
Что проверяют
Это переход к лайвкодингу, и формальное «да» интервьюеру мало что даёт. Он смотрит, как вы входите в задачу: уточняете ли условия и среду, рассуждаете ли вслух, не теряетесь ли без привычной IDE. Следом звучит сама задача, и оценивается уже процесс.
Как отвечать
Ответьте «да» и сразу договоритесь о правилах: где писать (общий редактор, Go Playground, своя IDE с демонстрацией экрана), можно ли запускать код и тесты, подсматривать документацию стандартной библиотеки. Это не затягивание времени, а привычка работать в понятных условиях.
Дальше рабочий каркас:
- уточнение: входные данные, граничные случаи (пустой срез,
nilmap, отмена по таймауту), что важнее: скорость или простота; - план вслух: пара фраз о подходе и сложности до первой строки кода;
- простое рабочее решение: сначала корректно, потом быстро. Ошибки обрабатываются явно, без
_ =ради скорости; - проверка: прогон примера по коду или табличный тест, для конкурентных задач
go test -race.
Готовьтесь к типичному для Go набору: worker pool, ограничение параллельности через семафор или errgroup с SetLimit, отмена через context.Context, слияние каналов, задачи «что выведет код» про append и общий массив у срезов, порядок обхода map, замыкания в цикле. С Go 1.22 переменная цикла своя на каждой итерации, и старый ответ про замыкания уже неверен.
Если прямо сейчас писать неудобно, скажите честно и конкретно, например что нет нормальной клавиатуры или обрывается связь, и предложите перенос или другой формат. Это воспринимается лучше, чем мучения на камеру.
Где спотыкаются
Молча пишут десять минут. Интервьюеру важен ход мысли, и даже верное решение без пояснений оценивают ниже.
Сразу строят сложную конструкцию из горутин и каналов там, где хватает цикла. Конкурентность ради конкурентности выглядит как непонимание её цены.
Теряются без автодополнения: не помнят strings.Builder, sort.Slice или пакет slices, пугаются первой ошибки компиляции. Её лучше спокойно прочитать вслух и исправить, это нормальная часть процесса.