Мы уже публиковали вопросы по техничке C#, теперь давайте разбираться с Go в Ozon.
У нас 9 записей техничек учеников с конца мая по начало августа 2026. Конкурентность спрашивали в 8 из 9 случаев, и почти всегда на задаче, а не устно.
Кстати по Go у Ozon больше всего вакансий на рынке, я писал об этом в апрельском разборе.
🛠 Как устроена техничка
Сначала проходит скрининг на 30–40 минут: задают пару теоретических вопросов, дают задачу на Go и SQL-запрос. Дальше техническое собеседование на полтора-два часа, где спрашивает то же самое, но глубже. В одной записи было ещё и код-ревью. Рисовать систему с нуля не просили ни в одной из 9ти записей.
🔀 Конкурентность: 8 из 9
"Что будет, если читать из nil-канала?", "Какой кейс выберет select, если готовы все три канала?", "Что выведет этот код с горутинами в цикле?". Из задач: обход списка URL, merge нескольких каналов в один, потокобезопасный кэш, логгер, который копит сообщения и пишет в базу пачкой.
Здесь же главный провал: в 6 из 9 записей ребята плыли именно на конкурентности. Путались в select без default, не закрывали канал и ловили deadlock, запускали 32 горутины, типа чтобы быстрее обработали.
У интервьюера в этот момент один вопрос: "Он вообще понимает, что станет с сервисом под нагрузкой, или просто вспомнил слово worker pool?". В одной записи он подсказал сам: воркеров ограничивают, чтобы сайт на той стороне не забанил за частые запросы.
Как избежать ошибки.
Возьми одну задачу и прогони её через все модификации. Последовательный обход, горутины с WaitGroup, канал результатов, адреса из канала, worker pool, отмена через context после двух успешных ответов. На каждом шаге проговаривай вслух, кто закрывает канал и когда. Именно здесь ловили deadlock. Число воркеров обосновывай внешним ограничением: лимитом запросов на той стороне, пулом соединений, числом ядер.
🗄 SQL вживую: 7 из 9
Запрос пишут почти на каждом этапе, включая скрининг.
Одна задача встретилась дважды почти без изменений: по таблицам users, purchases и ban_list вывести уникальные пары пользователь и товар из покупок до бана с сортировкой. Тоже по два раза: пользователи с суммой покупок больше 5000 и книги, у которых больше трёх авторов.
Типичная ошибка: сразу писать SELECT и собирать JOIN по ходу. Так в 4 из 9 записей кандидаты начинали не с той таблицы, забывали COUNT(DISTINCT) после JOIN с позициями заказа и получали дубли, путали WHERE и HAVING.
Как избежать ошибки.
Перед запросом скажи вслух, от какой таблицы идёшь и сколько строк останется после каждого JOIN. Это работает с двух сторон: ты ловишь размножение строк до того, как написал код, а интервьюер слышит ход мысли вместо угадывания.
🐘 PostgreSQL под нагрузкой: 5 из 9
"Как создать индекс на таблице с миллиардом записей, которая активно используется?", "Почему поле "пол" ты поставил первым в индексе?", "Почему не используем serializable всегда?". В одной из команд прямо сказали, что простой даже на полминуты стоит им миллионы.
В 3 из 9 записей здесь сыпались: забывали, что обычный CREATE INDEX блокирует запись в таблицу, не вспоминали CONCURRENTLY, ставили в начало составного индекса поле с двумя значениями.
Как избежать ошибки.
Разбери, как построить индекс без блокировки и проверить его валидность. Отдельно повтори порядок полей в составном индексе и уровни изоляции.
Сверх этого в 4 из 9 была база по сетям (TCP и UDP, версии HTTP), в 5 из 9 внутрянка Go: map, слайсы, defer, GOMAXPROCS.
На техничке в Ozon мало назвать worker pool. Следующий вопрос всё равно будет: “Почему воркеров именно столько?”
Расскажи в комментариях, на чём тебя ловили на техничке по Go: на каналах, на SQL или на индексах под нагрузкой?
Полный список вопросов и задач с собеседований в Ozon по Go в боте @booster_tbot
Если целишься в Ozon по Go и хочешь отработать вопросы с ментором, напиши мне.
#техничка #golang