Следующий пост в серии Ozon, на этот раз по Java. Имеем 7 записей техничек наших учеников. Темы в них повторяются из собеса в собес, а часть вопросов звучит почти слово в слово. Давайте разбираться, что спрашивают и на чем сыпятся люди чаще всего.
🗄 Базы данных: 5 из 7, самая частая тема
Были вопросы по индексам: "Как устроен B-tree и чем он отличается от бинарного дерева?", "Важен ли порядок колонок в составном индексе?". Еще спрашивали про транзакции: "Чем read committed отличается от repeatable read?", "Есть ли в PostgreSQL read uncommitted?".
Уровни изоляции спрашивали дважды, и оба раза ответ развалился. Один ученик перепутал read committed с read uncommitted, другой запутался, от чего защищает repeatable read.
Как избежать ошибки. Выучи таблицу "уровень → от какой аномалии защищает", потом добавь поправку на Postgres и модели MVCC. Read uncommitted там работает как read committed, а repeatable read за счёт модели MVCC защищает от фантомного чтения. Так видно, что ты работал с живой базой, а не пересказываешь стандарт.
В 2 из 7 SQL писали руками: покупки на сумму больше 5k с учётом даты блокировки пользователя, топ-3 самых читаемых авторов. Ловят на GROUP BY, HAVING и выборе между JOIN и LEFT JOIN.
🧵 Многопоточка: спрашивали в 4 из 7, ребята столкнулись со сложностями во всех четырёх
Типовые вопросы тут звучат так:
- "Можно просто повесить volatile на поле счётчика?"
- "Чем compare-and-set отличается от обычной блокировки?"
- "Можно сделать счётчик через synchronized на Integer?".
Ещё просили решить race condition и data race. Типичная ошибка: ты знаешь слово, но не механизм. Говоришь "volatile нужен для многопоточности" и не можешь объяснить механизм работы. Интервьюер хочет узнать: "Он действительно понимает, почему count++ теряет прибавления, или просто выучил определение?"
Как избежать ошибки. Готовь тему на одном примере: два потока увеличивают общий счётчик. count++ — это три шага: прочитать, прибавить, записать. volatile даёт видимость, а не атомарность, поэтому потоки всё равно перетирают друг друга. synchronized на Integer тоже не спасёт: после каждого ++ в поле лежит новый объект, и потоки захватывают разные мониторы. Работают synchronized на общем объекте, ReentrantLock или AtomicInteger, который крутит compare-and-set в цикле без блокировки. Пройдёшь эту цепочку вслух, и закроешь половину блока.
📦 Коллекции и сложность: 4 из 7
Вопрос "Какую структуру взять, если часто удаляешь первый элемент?" прозвучал в двух собесах почти дословно. Рядом устройство HashMap, коллизии и амортизированная сложность. Здесь соискатели валятся на цифрах: один ученик назвал поиск в HashMap O(log n).
Как избежать ошибки. Для каждой коллекции держи три ответа: как устроена, какая сложность в среднем и худшем случае, когда её брать. На удаление первого элемента отвечай ArrayDeque: кольцевой массив снимает голову за O(1) и не создаёт узел на каждый элемент, как LinkedList.
📨 Гарантии доставки: 4 из 7
– "Какие гарантии доставки бывают?"
– "Как добиться at least once?"
– "Можно ли сделать exactly once в Kafka?"
– "Что такое Outbox?"
Как избежать ошибки. Отвечай связкой: at least once плюс идемпотентный обработчик. Сообщение может прийти дважды, поэтому консьюмер запоминает ключ обработанного и на повтор ничего не меняет. Для бизнес-логики это и есть "ровно один раз".
⌨️ Код без IDE: 4 из 7
Основные задачи были на поиск числа в массиве. Тут двое учеников споткнулись о синтаксис: забыли, как написать main, не могли объявить массив. Логика была верной, а впечатление смазалось. В одном собесе прямо предупредили: следующий этап без гугла, одна задача на алгоритмы, вторая на многопоточку.
Помни, провал на техничке в Ozon — не приговор твоему уровню, а список тем, который теперь известен заранее.
Пиши в комментариях, на чём тебя ловили на техничке: на многопоточке, на транзакциях или на коде без IDE?
Полный список вопросов и задач с собеседований в Ozon по Java в боте @booster_tbot
Если хочешь подготовиться к следующей попытке в Ozon с ментором, который знает эти темы, пиши в личку.
#техничка #java