Комментарии 44
Почему нет PHP?
Кодовых задач, которые можно красиво разобрать пока мало. В основном аля "спроектируй сервис на Laravel". Да и выборка по пыхе достаточно скудная.
бельше интересно почему нет C++, в яндексе на сколько мне известно это одна из самых больших команд
Основная проблема не в задачах, а в том что интервьюеры говорят под руку, мешают думать и меняют условия в процессе решения.
ВК оценивает не алгоритм, а аккуратность. Кандидат, который с первого раза написал чистое решение без багов за 12 минут в приоритете.
Им не рассказали, что это называется зазубривание, а не аккуратность?
Яндекс тебя может спокойно отпендюрить, если ты не реализовал кастомную обработку ошибок. Наверное поэтому появились "волки" и они так успешно паровозиком хакают собесы. Кого ищут, того и находят. Все честно.
Что такое «волки» ?
ооооо, вот сейчас ты вышел на скользкую дорожку
Это прямо новый тренд, когда работодатель не семья и друг или бизнес-партнёр, а просто дойная корова. И если корова даёт мало молока, то её меняют. Никаких переработок, никаких сверхурочных, никакой бизнес-заинтересованности. Любые хаки для прохождения собесов, снова и снова тренировать собесы проходить, а работать "от и до".
У меня вопрос, можно? можно же?
Как они хакают HRов которые подбирают по "астрологии как дополнительному аналитическому инструменту в HR..." (C)? День рождения в паспорте не изменишь же -> натальная карта одна на всю жизнь...
Если компания постоянно толкает на переработки, ещё и бесплатно (есть и такие), то её точно надо менять. Это должно быть здоровым минимумом для любого человека. Нельзя поддерживать того, кто хочет вернуть крепостное право
За остальное не говорю, дело каждого. Мне, к примеру, важно, чтобы проекты были интересные, а коллеги - приятные. Но переработки - зло. От них и выгореть можно
Вот смотрю на такие статьи, такие продукты, которые рекламируются напрямую даже без блога компании, и становится грустно — как нанимать теперь кого-то с рынка?
Задавать вопросы и слушать ответы, так же как и всегда. Когда человек отвечает как гпт, это слышно и чувствуется, если один-два раза человек ну может реально так и запомнил теорию/пограничный кейс, то больше таких ответов, или вечные задержки до появления ответов, или чтение с экрана
Лайвкодинг в принципе никогда не был адекватной метрикой, так что я даже рад что кто-то его убил, пускай и таким методом
так это индивидуальная разработка, под силу одному человеку. Какой уж тут блог компании.
И да, это деградация отрасли. Сами породили то, что нас может убить. Раньше шли в ИТ не за деньгами, верно? ;-)
Так происходит с любой отраслью - сначала энтузиасты, сорви-головы, рок-стары, а потом постепенно она превращается в обычное ремесло, появляются нормы, правила, регламенты и вот он конвейер.
Раньше, в авиацию шли отбитые наглухо смелые и бодрые ребята, которым пролететь под мостом, как два пальца, а сейчас? Взлет по карте, посадка по карте - чет не сделал? увольнение и волчий билет. Автоматика так вообще все может сделать сама.
Очень интересно посмотреть правильное решение вот этого. ПРавильное по Озону, конечно
Потоковая обработка лог-файла – Ozon, Middle
Имеем файл логов 10 GB. Посчитать топ-10 URL по количеству запросов. В память не влезает. Ожидается решение через генераторы и
collections.Counter.
Ozon любит data processing. Кандидат, который делает
file.readlines()провалил задачу ещё до того, как начал считать. Правильный ответ: генератор, построчное чтение, Counter сmost_common(10). Могут задать вопрос: "а если URL миллионы уникальных и Counter не влезает в память?"
Deepseek выдал решение на 7200 строк
import hashlib
from collections import Counter
from heapq import merge
import os, tempfile, json
def top_urls(logfile, n=10, num_buckets=256):
tmpdir = tempfile.mkdtemp()
buckets = []
for i in range(num_buckets):
buckets.append(open(f"{tmpdir}/bucket_{i}", "w"))
with open(logfile) as f:
for line in f:
url = extract_url(line)
h = int(hashlib.md5(url.encode()).hexdigest(), 16) % num_buckets
buckets[h].write(url + "\n")
for b in buckets:
b.close()
global_top = []
for i in range(num_buckets):
with open(f"{tmpdir}/bucket_{i}") as f:
counter = Counter(line.strip() for line in f)
global_top.extend(counter.most_common(n))
global_top.sort(key=lambda x: -x[1])
return global_top[:n]Наверное как-то так. Дипсик наверное с нуля начал реализовывать MapReduce.
Дипсик читал весь лог и аггрегировал в mmap
У Вас, если, например, половина логов из одного URL, то опять не влезет в память один bucket.
Т.е. если реально глючит что-то и засирает лог, то такой перекос реален.
Counter влезет, т.к он хранит уникальные ключи, а не строки. Если бакет маленький то Counter. Если распух то sort и линейный проход. Память после сортировки O(n) т.е 10 записей в heap. Но с оценкой в midlle, я погорячился. Тут вполне и сеньор вспотеть может. А mmap это делегирование работы с памятью на ОС, не думаю, что такое на собесе понравится.
Ага
Так и получается, что нужно прочитать построчно (лучше пачками) все 10G и для каждой строки по URL вести счетчик - а это лучше mmap. И сразу хранить 10 наиболее частых, что бы не сортировать потом.
И тут вопрос - а если будет 11 одинаковых наиболее частых? Которые 10 из них пойдут в ответ?
А в словарь +1 делать не?
если URL миллионы уникальных и Counter не влезает в память?
Самое простое
Чанковый подход с потерей точности. Читаем генератором порциями, скажем по 5 миллионов URL, обновляем Counter. Когда он распухает выше порога — обрезаем, оставляя только топ-N тысяч. Редкие URL теряются, но нам нужен именно топ, и для большинства практических распределений (Zipf) это работает.
Чуть сложнее
External sort (MapReduce-стиль). Извлекаем URL, записываем во временные файлы, сортируем каждый файл на диске, затем делаем merge sort из отсортированных чанков. В отсортированном потоке одинаковые URL идут подряд — считаем длины серий за один проход, держа в памяти только текущий URL и счётчик. Точность абсолютная, но медленнее из-за I/O.
Корпы: AI-HUI, агенты, рои агентов, MCP, RAG, ML, промпт-инжиниринг, кто не кодит через агентов - тот отстал на поколение, знать ЯП больше не нужно
Также корпы: прогромировай на листочке, а я над душой постою
Думаю, тут код писать на надо.
Надо только подсветить потенциальные проблемы и поставить задачу для LLM
Ленивый конвейер: файл читается построчно через итератор, генератор извлекает URL, результат скармливается в collections.Counter, most_common(10) выдаёт ответ
Потенциальные проблемы, которые нужно учесть
readlines() / read() / list(f) — моментальный OOM, нельзя загружать весь файл в память
Много уникальных URL — сам Counter может не влезть в RAM, нужен fallback: hash-партиционирование на бакеты, чанковый подход с обрезкой, или вероятностные структуры (Count-Min Sketch)
Битые строки — парсинг должен быть обёрнут в try/except, а не ронять весь pipeline
Ну ещё по мелочи...
А код? Ну его нафиг
"над душой постою" это уже про софт скиллы )
Реализовать EventBus с подписками. Но подписчики не должны удерживаться от GC, используй WeakReference. А что с потокобезопасностью?
Бггг!
Похоже на архитектурную ошибку постановки задачи. Не рекомендую реализовать в таком виде, а исправить арх ошибку.
Извините, поспрашивал LLM
почему требование WeakReference в EventBus — это «красный флаг» и как на это смотрят опытные архитекторы?
Перекладывание ответственности: Требование использовать WeakReference означает: «Наши разработчики забывают отписываться от событий, поэтому нам нужно, чтобы система за ними подчищала»
Правильный подход: Явное управление жизненным циклом (через IDisposable). Если объект создается контейнером (DI), он же должен его и утилизировать.
Я за 10 секунд понял что тут предлагают секс стоя и в гамаке.
Мужик в скафандре сено косит. Мимо проходит женщина, и говорит: — А почему в скафандре? Мужик: — Трудности люблю. Женщина: — Плюнь ты на эти трудности, пошли лучше потр%%аемся! Мужик, подумав: — Ладно, пошли, только в гамаке. И стоя!
Система бэкапов: стриминг, сжатие, пайплайн
Как я понял, предполагается решение: разбить входной файл на куски (чанки) разумным маленьким размером (4-16 Мб), посжимать отдельно и выходный файл наполнять сжатыми кусками, пока он не перейдет лимит в 100 Мб, а последний невлезающий кусок откатить и сделать началом нового файла. Типа сжатие можно распараллелить, а лимиты чанков и выходных кусков менять независимо?
Но я не понял, как определить границы сжатых чанков в выходном файле. То есть я не смогу, как winrar, рассматривать последовательность .part1, .part2, ... как один виртуальный файл, и разархивировать, будто нет границ между файлами? То есть приступая в будущем к восстановлению, я должен знать какую-то схему, иначе не смогу прочитать бэкап?
И еще вопрос по вашему опыту. Насколько итоговый коэффициент сжатия через чанки может быть хуже, чем сжатие всего файла?
Когда увидел вот это "Тихо. Без исключений. В проде." сразу как-то ChatGPT повеяло.
Про Kotlin на backend ничего нет? Или на 80% пересечение с Java и только 20% разбег в асинхронщине: потоки пулы (или что там нынче в Java?) с одной стороны и корутины, каналы с другой? Пропорции взял с потолка.
Kotlin на бэке в моей выборке плюс минус 4% всех сессий маловато для отдельного разбора. Но подметил верно, процентов 70–80 задач пересекаются с Java.
Спасибо за инфу, я как раз собираюсь идти на собес в тбанк, вакуха на фронте.
Одно интервью может включать квиз, задачу на паттерн, react-компонент с API и вопрос про ререндеры.
вьетнамские флешбеки
Зачем в задаче от Яндекс на балансировщик проверять контекст между попытками? Если он завершен, то Invoke не отменит сразу запрос? Если не отменит, то зачем тогда вообще контекст в b.backends[idx].Invoke(ctx, req)?

Реальные задачи с собеседований в Яндекс, VK, Ozon и Сбер — Go, Java, Python, React