Полгода назад была статья как Яндекс обновляет процесс найма разработчиков - а недавно, в феврале 2026 я вновь опробовал этот "процесс" - и вот поделюсь, насколько он реально "обновился" (т.к. я проходил его и раньше). Одновременно шёл аналогичный процесс с ВК - постараюсь описать сходства и различия по всем этапам, в которых участвовал - может быть полезно и тем кто проходит подобные собеседования - и тем кто формирует процессы найма.
Краткий вывод такой: описанные в той статье "обновления" присутствуют, но значительных изменений не ощущается. В конце выявился "один нюанс", который портит целесообразность процесса изначально (можно сразу пролистать в конец статьи если любопытно). Так что "обновлениям" впереди ещё немалый путь!
Предыстория
Работу трудновато найти когда она нужна. Зато когда это неактуально - рекрутёры выскакивают как из табакерки! С разницей в 4 дня мне написали барышни из Яндекса и ВК - это после нескольких месяцев тишины. Хотел было вежливо отказаться (тем более что раздражает это "я нашла твой профиль" - где ты его нашла? что за профиль?) - но вспомнил вышеупомянутую статью - и любопытство взяло верх. Когда из ВК написали - я уже махнул рукой, попробуем обоих - может хоть узнаю какие сейчас уровни зарплат актуальные.
Как следствие такой ситуации, на сей раз я к собеседованиям относился несколько более "вольнодумно" чем обычно, поэтому не следует воспринимать изложенный опыт как строгое руководство к действию.
Яндекс приглашает на "Серф-Кэмп" - процесс где новоприбывший работает в нескольких проектах в течение испытательного срока, и выбирает что больше по душе.
VK более прицельно предложили собеседоваться в VK-видео (команда отвечающая не собственно за подачу контента а за сайт/чат вокруг этого дела).
Похожие процессы в обеих компаниях я уже проходил раньше - в VK (конкретно VK-ID) в августе 2023 года (тогда HR ушла в отпуск а вернувшись и собравшись готовить оффер обнаружила что я уже принял предложение от Ozon) - а в Яндекс в сентябре 2024 (там процесс затянулся месяца на полтора и у меня накопилось три оффера от других компаний так что я предложил досрочно прекратить эту тягомотину).
Вообще же в Яндекс, например, собеседовался в разные годы, начиная с 2011 а где-то в 2016 даже получил оффер (но не принял, т.к. в компании "Tango" предложили лучшие условия и ездить ближе) - так что наблюдал за эволюцие процесса собеседований у них можно сказать полтора десятка лет. По ощущениям в последние лет 5-8 он не менялся значительно.
Календарь
Для наглядности все прошедшие этапы коммуникаций с обеими компаниями сведены в календарик. По ощущению в Яндекс процесс несколько более затянувшийся, но в общих чертах всё примерно похоже.
Сам я старался соглашаться на ближайшие предлагаемые даты этапов, за исключением пары случаев когда уж очень сложно оказывалось совместить с работой и домашними делами. Как можно видеть, порой из-за этого оказывались два собеседования в день, иногда полуторачасовые.
Здесь же отмечены даты получения фидбэка по прошедшим этапам - как видно обычно сотрудники старались быть оперативными кроме недели с 23 февраля.
Перечислим эти этапы кратким списком (а потом уже поговорим о них подробнее):
Яндекс
Первый контакт от HR - 30 января
Интервью с HR - 2 февраля
Секция "алгоритмы" (live-coding) - пропустили т.к. мне "зачли" прохождение её в 2024 году
Секция "язык" (тоже live-coding) - назначили на 6 но перенесли на 10 февраля (оказалось что у меня только час времени запланирован - а настаивали на полутора - на деле минут за 70 мы справились в ленивом темпе).
Секция "архитектура" - назначили на 20 февраля (был один слот раньше но уж очень неудобный по времени)
Секция "опыт" (см ниже, рассказ об одном из проектов, которые разрабатывал) - 2 марта
Финальные собеседования с руководителями проектов - они предстоят, если "опыт" и "архитектура" окажутся удовлетворительными (и найдутся подходящие проекты).
Отказ - получен 4 марта (с оговоркой что якобы это отказ на грэйд Senior а на Middle+ в теории могут найтись позиции но вряд ли удалённые и т.п. - ну в этом я сомневаюсь)
Можно видеть что это довольно точно соответствует "процессу" изображённому в упомянутой выше статье (на уровень senior):
Очевидно "специфические навыки" это алгоритмическая секция, а "базовые технические" - по языку. Единственное новшество по сравнению с 2024 годом, по-моему, секция "про опыт" (а может в прошлый раз мне её просто не предложили?) Также новым заявлена фича "фидбэка" от интервьюеров. Его действительно присылают через HR, хотя в целом обычно по ходу интервью и так примерно всё понятно (а замечания полученные постфактум иногда выглядят спорно - об этом ниже упомянем).
И в VK процесс похожий:
Первый контакт с HR - 4 февраля
HR-интервью - 10 февраля (можно было раньше но у меня напряжёнка со временем уже была)
Технический "скриннинг" (в основном устные вопросы на час) - 12 февраля
Live-coding - 17 февраля
Финал с VK-видео - 20 февраля
Финал с VK-музыкой - 2 марта
на момент публикации статьи (11 марта) отказа, оффера или вообще комментариев от HR не поступало - предполагаю, что и в музыке решили обойтись без меня :)
Тут два замечания - во-первых опционально существует секция "архитектуры", но мне её не предложили - либо потому что недостаточный уровень по предыдущим этапам определили - либо потому что включили её частично в "финал" с руководителями проекта (об этом дальше будет).
Во-вторых этот самый финал я видимо прошёл не слишком удачно и рекрутёр через несколько дней выразила это так что рекомендуют побеседовать ещё с другим проектом куда я, якобы, подхожу больше. Таким образом некая "гибкость" подразумеваемая процессом Яндекса присутствует и в случае ВК.
Что же, теперь пойдёт рассказ об этапах более подробно. Можно пролистнуть до интересующего вас заголовка если какие-то секции вам знакомы или неинтересны.
HR-интервью
Оно достаточно похоже в большинстве компаний - в данном случае разница была основная в том что барышня из Яндекса попросила созвон с камерой, а её коллега из ВК сказала что это не требуется.
Обычный порядок в духе:
Сначала HR расскажет про компанию и проект - обычно HR не много может сказать о проекте по существу, а про компанию и так более-менее известно; тем не менее можно что-то услышать о масштабе команды, может быть понять поточнее идёт ли речь, например, о бэкенде сервиса непосредственно ориентированного "фронтом к пользователю" - или где-то в глубине, в платформе и т.п.
Вопросы касательно опыта кандидата - тоже порой до комичного "имели ли вы дело с АПИ" - с каким АПИ? - ну, не знаю, у меня написано "АПИ" :) Здесь я обычно стараюсь взять инициативу в свои руки и просто прочитав вслух список требований вакансии по пунктам отвечаю "Go использую последние 4 года, с SQL разумеется знаком, но не гуру, про NoSQL вопрос туманный т.к. баз очень много разных, я имел дело с такими-то".
Что нравится или не нравится в текущей, или предыдущей компании (бывают случаи когда HR о ней хорошо осведомлён или недавно оттуда). У меня обычно честный ответ типа "очень милые ребята, но процессы имеют большой потенциал для улучшения".
Зарплатные ожидания
Вот на этом последнем пункте я акцентировал внимание. Говорю - моё резюме вы перед собой видите? А цифры в нём какие указаны?
Дело в том что у меня было несколько резюме на HH с немного разным стеком технологическим (Go, Java, Erlang) и заголовками - и "ценники" там тоже были разными. И я их с одной стороны не помню - с другой стороны не знаю какое именно резюме смотрит рекрутёр. Я вообще не жадный и предпочитаю отталкиваться от предложений работодателя. Так всегда и говорю.
И тут оказывается удивительное - рекрутёру (и в Яндексе и в ВК) эта цифра не видна! Очевидно резюме они видят уже скопированное во внутреннюю базу компании и из каких-то соображений зарплатные цифры удаляются или стираются.
Я удивляюсь: "раз вам их сознательно не показывают, зачем же я буду вам говорить?"
На это какой-то невнятный ответ - мол, мы сами ничего от себя не скрываем, это у вас "галка не отжата". Не слыхал и не видал я "галки сокрытия зарплаты в интерфейсе HH", но не поленился спросить в поддержке:
Отсюда делаю вывод - рекрутёры сами не в курсе подробностей собственных процессов. Как увидим далее, это может вести к абсолютно нелепым последствиям.
Яндекс - live-coding
Этот этап может вызывать некоторый стресс, но тут делать нечего, раз у них такой "процесс". Сам я стараюсь относиться к возможности "пошевелить мозгами" более-менее позитивно, хотя разные компании под live-coding понимают иногда разные вещи (иногда сюда включают "найдите ошибки в этом коде", например). Сам я с бОльшей симпатией отношусь к "оффлайновым" тестовым заданиями над которыми можно "покубатурить" денек другой. Последний раз в Яндексе такое предлагали где-то в 2014 (что-то в духе "написать download manager").
В случае Яндекс таких секции две - одна по "алгоритмам", другая же "по языку" (в моем случае Go). Вообще они очень похожи, если попытаться выделить разницу то я бы сказал что в обоих случаях есть некая "первая задачка попроще", а после того как с ней удаётся успешно справиться дальше небольшая вариация:
в секции "по языку" обычно следует усложнение первой задачи, обычно делающее её более "практической"
в секции "по алгоритмам" просто дают другую, немного более сложную задачу (т.е. всего 2)
Как я упоминал, секцию "алгоритмическую" мне зачли "с прошлого раза", хотя я бы не без интереса потренировался на очередных задачках про места в театральном зале или ямки заливаемые водой. Обычно они не завязаны явно на какой-то стандартный алгоритм и это отчасти любопытно.
В секции "языковой" задача была "написать программу для составления карты сайта". Причём задан шаблон из 3х функций:
функция
GetPage(url string) -> (string, error)для скачивания страницы по урлу (на выходе текст страницы и, возможно, ошибка)функция
Hostname(url string) -> stringдля выделения доменного имени из урла (нужна для того чтобы не ходить по внешним ссылкам)функция,
ParsePage(text string) -> []stringпарсит страницу, возвращая список ссылок в её тексте
Результатом работы должна быть "мэпа" в которой ключами являются адреса страниц сайта - а значениями - списки урлов страниц на которые можно попасть отсюда.
Решение
То что страницы сайта и ссылки между ними представляют собой граф, и что для составления его "карты" нужно реализовать поиск в глубину или ширину - это наверное совсем не ново :) На всякий случай повторю в общих словах как это происходит:
заводим "мэпу" для результата, а также используем её чтобы помнить какие страницы уже обработаны - изначально она пуста
заводим массив (или список) для страниц которые предстоит обработать - изначально в него помещаем "корневую" страницу, которая используется на входе алгоритма.
также взяв "hostname" от этой начальной страницы запоминаем его, чтобы потом сверять найденные ссылки и отбрасывать те, которые ведут на сторонние сайты
теперь в цикле достаем из массива очередную ссылку, парсим, добавляем запись в мэпу (урл этой страницы - и список страниц на которые она ведёт) - а также добавляем эти связанные урлы обратно в массив, если у них hostname совпадает с нашим и если их ещё нет среди ключей мэпы-результата
Вот и всё. Если доставать урлы из массива "с конца" (т.е. использовать его как стек) - получится поиск в глубину. А если из начала (т.е. очередь) - то поиск в ширину. Для нашей задачи не имеет значения т.к. нам нужно весь граф просканировать.
Отдельный вопрос - как обрабатывать ошибки скачивания. Поскольку шаблон задания не содержит для этого каких-то специальных возможностей, я в первом приближении просто стал добавлять в мэпу записи со значением nil - на это интервьюер позже сказал что так мол не очень хорошо. Он имел в виду что если мы впоследствии захотим обработать эту мэпу и перевыкачать какие-то из страниц, то хорошо бы понимать какой был тип ошибки (т.е. где повторный запрос может помочь а где нет).
Усложнение задачи
Было выражено пожеланием "распараллелить" процесс на несколько тредов, вплоть до заданного максимального числа N.
Тут в подробности не стоит вдаваться т.к. реализация может сильно зависеть от возможностей языка и стандартной библиотеки.
Главное что важно уловить - когда заканчивать процесс. Однопоточный вариант заканчивается когда в массиве "на обработку" больше ничего нет. В многопоточной версии это не критерий - ведь сейчас могут ещё обрабатываться какие-то страницы. Т.е. остановиться нужно тогда, когда и в массиве пусто, и "воркеры" пассивны.
Полученный фидбэк
Немного меня удивил - как будто его писал другой человек, нежели тот что меня интервьюировал. Было отмечено что кандидат молодец потому что сам проверил своё решение - абсолютно неясно что имелось в виду, т.к. проверять-то нечем и не на чем (см. ниже) - в то же время среди недочётов было указано, например, использование глобальных переменных и функций. Так это шаблон был такой задан - и вроде бы даже я спросил оставлять ли так, или переделать в "оопшном" стиле.
Примечание
Да, у Яндекса до сих пор live-coding проходит в блокноте без возможности запуска кода. Так что его даже "live" называть не очень правильно.
Это раздражает не только тем что надо самому, по-видимому, демонстрировать "глаз-компилятор", но и интервьюер проверяет код визуально, что может занимать сколько-то минут, по результатам которых он может все ещё быть не до конца уверенным "так, дайте ка ещё раз посмотрю... э-э-э..."
В чём проблема использовать хотя бы тесты, приготовленные заранее вместе с шаблоном - неясно. Ниже можно сравнить как это проходит у VK (да и у почти любой компании использующей live-coding на собеседовании) - хоть минимальные возможности для компиляции и проверки предусмотрены и используются.
VK - технический "скрининг"
Аналога этого этапа у Яндекса нет. Вообще вещь полезная - не столько для того чтобы "отсеять неугодных", а скорее в общем сориентироваться насчет познаний кандидата. В редких случаях его проводит HR, хотя в урезанном виде (и м.б. по вопросам которых не понимает сам) - но здесь для этого был выделен отдельный сотрудник и час времени.
Выше я назвал этот этап "устным" - но это не совсем так. Тут был примерно 15-минутный "live-coding" с бородатой задачей:
дан массив чисел и некая желаемая сумма S - мы хотим найти пару чисел в массиве которые в сумме дают как раз это число (либо сообщить что такой пары нет)
Задача настолько известная что, быть может, и упоминать её не стоило - но для полноты картины на её примере вспомним как вообще следует "подходить" к решению:
сперва объясняем как выглядит "тупой" способ решения
потом объясняем чем он плох
предлагаем лучший вариант
и убедившись что интервьюер согласен с ним, занимаемся реализацией
В данном случае это может выглядеть так:
Наивный способ решения заключается в том чтобы в двойном вложенном цикле перебрать все возможные пары чисел и проверить равенство их суммы числу S. Этот способ плох в смысле быстродействия - O(N^2) - затраченное время растёт квадратично с размером массива.
Улучшить подход можно разными способами - например, сложить все числа в мэпу (точнее в множество) и (даже на том же проходе) проверить находится ли для каждого из чисел пара в этой мэпе. Альтернативно можно отсортировать массив и идти с двух концов двумя указателями.
Способ с мэпой работает за O(N) но требует дополнительной памяти под мэпу. Способ с массивом можно реализовать "на месте" (но исходный порядок в массиве окажется нарушен) а его быстродействие чуть хуже O(N*log(N)).
С интервьюером согласились что достаточно написать способ с мэпой. Удачно что у него уже были заготовлены собственные тестовые наборы данных так что проверка и с моей и с его стороны не заняла много времени.
Вопросы
Вторая, более длинная часть это вопросы по списку, по разделам:
по языку (Go)
по базам данных (SQL-ным) - типичное про индексы, шарды и т.п.
по сетям - привычное про TCP, UDP, как резолвится DNS и т.п.
по операционной системе (чем потоки отличаются от процессов и пр)
по "безопасности"
Слабо я себя показал пожалуй в последнем разделе - оказывается мои познания в этой части в основном заканчиваются на SQL-injection а большинство аббревиатур в стиле X...F звучат очень похоже. Впрочем по-видимому и этого было достаточно.
VK - live-coding
Эта секция имеет сходство с обеими Яндексовыми, но с тем различием что:
задание в виде шаблона, являющегося работоспособным приложением (остов веб-сервиса)
код писать нужно на своей машине в любимой IDE, просто в режиме расшаренного экрана
Таким образом нет проблемы с проверкой - более того, задание включает примеры "курлов".
Учитывая сходство с вышеописанным аналогичной секцией в Яндексе я бы не упоминал этот этап подробно, но тут интересно вышло что все мы "чуть-чуть сели в лужу" - и я, и интервьюер, и язык Go. Вот на какой несложной задачке это вышло:
Новостной Сервис
Дан шаблон веб-сервиса с 3 эндпойнтами (примерно такой):
добавление новости (айдишник, заголовок, текст, и score - рейтинг)
получение "топа" новостей (лучших по score)
апдейт новости (в том числе может измениться её score)
Сделать это нужно "in-memory", то есть подключать базу не требуется. Достаточно выбрать подходящую структуру данных и реализовать логику.
Можно запустить пример из гиста и в отдельном окне выполнитьcurl http://localhost:8081/news/top - должен получиться пустой json-массив.
Я спросил какого объёма может быть "топ" - интервьюер задумался немножко и предложил "например тысяча". Вот этот момент нам следовало проговорить подробнее - но ни он ни я не обратили внимания. Я решил что раз только "топ" может содержать 1000 элементов, то общее количество новостей может быть произвольно большим. Сколько влезет в оперативку. Например если новости в среднем занимают 1000 байт то гигабайта хватит на миллион.
Решение
Удобнее всего использовать дерево поиска (например двоичное, самобалансирующееся) - они есть например в Java и C++ прямо "из коробки" (TreeMap и просто map). Дерево позволяет добавлять новость за незначительное время O(log(N)) и оперативно выбрать T элементов.
К сожалению в языках вроде Python или Go деревьев в стандартной библиотеке нет. В первом есть OrderedDict - но это скорее для создания кэша - а во втором есть Heap но из неё нельзя по простому выбрать T топовых элементов.
Поэтому я написал решение, которое хранит все пришедшие новости в гигантской мэпе (по айдишникам), а "топ" отдельно держит в небольшом массиве на 1000 элементов.
При добавлении новости мы заносим её в мэпу, а кроме того если её score достаточно высок (выше чем у последнего элемента в топе) то добавляем в топ и пересортируем его.
Топ маленький и сортировать его можно очень быстро.
Минут за 30-40 всё было написано (я использовал vim с плагином и тестировал с помощью curl и jq) - мы уже радостно потирали ручки и тут я сообразил что есть "неприятный" кейс, а именно:
когда
updateменяетscoreновости так что она выпадает из "топа" и на её место должна прийти "лучшая" новость из мэпы
А вот какая новость в мэпе лучшая? Этого мы не можем сказать не перебрав все элементы мэпы. В принципе и миллион записей проитерировать и найти лучшую - это доли секунды займёт, но всё таки это уже O(N) чего хотелось бы в идеале избежать. Хотя если учесть что новости вряд ли приходят чаще чем раз в секунду то это терпимо.
После того как я не с первой попытки смог объяснить эту проблему интервьюеру, он задумчиво спросил (и переспросил потом н есколько раз):
А зачем вообще мэпа, почему не хранить все новости в массиве и сортировать его при каждой вставке.
Тут я понял что он похоже не рассматривает задачу в которой новостей миллионы. Действительно, массив на миллион элементов на современном железе можно за секунду отсортировать даже несколько раз. Но если там 10 или 30 миллионов? И учитывая что на время сортировки нам нужно залочиться и запросы на выдачу будут тормозить...
В общем, резюмируя, несмотря на положительный итог прохождения этой секции - мы оба были немножко неправы - интервьюер в том что не обмозговал заранее возможные ограничения и вытекающие варианты решения задачи (и то что задача вообще неодинаково удобно решается скажем на Go и на Java) - ну а я в том что спросил только про размер топа - и из этого интуитивно сделал какие-то допущения насчет общего количества. Это все лучше обсудить до того как начать реализацию...
Яндекс - архитектура
Эта секция опциональная, как пояснила HR она даёт возможность "повысить итоговый грэйд" - ну и схема выше как будто это подтверждает. Что же, хотя у меня более чем скромный опыт в архитектуре - но хуже ведь не будет - да может и что-то полезное узнаю!
Из лёгких негативных моментов - интервьюер опоздал к началу минут на 12 - притом что секция всего на полтора часа. Всякое бывает, но хотя бы предупредить было бы неплохо, чтобы кандидат не пытался в телеграме достать HR-ов и выяснить что происходит.
Наконец мой визави проявился :) Поведал что уже 15 лет проводит архитектурные секции в яндексе, стал пространно рассказывать как у нас будет построен диалог и т.п. В основном эта информация была заранее прислана в памятке HR-ом, так что можно было значительно сэкономить время. Тем более похожие секции в разных компаниях уже случалось проходить - и в том же Яндексе в 2016 году по-моему даже.
Ну наконец соизволили приступить к делу. Задача звучала в духе "я (интервьюер) выступаю в роли продакт-овнера и предлагаю тебе как архитектору следующее"
Спроектировать сервис шаринга фото, подобный Инстаграму
Основной требуемый функционал:
пользователь может создать пост (фото плюс какие-то комментарии)
пользователи подписаны на других пользователей и на странице "ленты" (feed) видят сколько-то последних постов тех, кого они "фолловят".
Я уточнил - всё прочее, включая лайки, комментарии, нотификации и т.п. нас сейчас не интересует. Ну это и правильно, такие вещи отдельными сервисами вероятно будут реализованы.
По ходу я должен был рисовать архитектуру в удобном мне редакторе схем, на выбор - интервьюер на это дело смотрел в режиме расшаренного экрана и слушал мои идеи и пояснения. Подробно рассказывать не буду т.к. честно считаю свои скиллы в этой части недостаточными - но вот то что я нарисовал, и ниже в общих чертах пояснения.
Первым делом нужно понять "масштаб бедствия" - на какое количество пользователей мы ориентируемся, на какое количество постов (в т.ч. скорость их генерации). Тут мне не очень понравилось - поскольку интервьюер не торопился давать оценки, я предположил ориентироваться на 500 млн аккаунтов и один пост в день в среднем от аккаунта. Интервьюер некоторое время допытывался "почему такие цифры" - насчет первого я сказал что беру посередине между Фейсбуком и Телеграмом (насколько я их помню). Насчет второго - что это цифра "по собственным ощущениям, по наблюдениям за аккаунтами друзей и пр".
Наконец интервьюер выразил своё мнение - 2 млрд аккаунтов (якобы столько в инстаграме было на момент продажи) - и один пост в 10 дней от пользователя. Не знаю что мешало сразу эти цифры предложить - не путаем ли мы архитектора с аналитиком?
Так или иначе я изобразил арифметические расчеты - 200 млн постов в день - или чуть больше 2000 в секунду.
Дальше рассуждаем, как это будет храниться.
графический контент хранится точно отдельно от поста - легко заметить что это общая практика в любой соцсети - изображения и выдаются отдельными серверами - но это в общем и понятно.
таким образом "пост" состоит из user_id, текста, таймстемпа и image_id (по которому картинку к этому посту можно найти в сервисе хранения картинок) - это всё небольшой объём данных, условно 500 байт в среднем.
посты всё равно придётся хранить в шардированном хранилище (это может быть и постгрес) - где шарды сделаны по user_id - потому что их много
а вот хранилище (таблица) пользователей сравнительно не так велика - и связей между ними тоже (да бывают аккаунты с тысячами подписчиков но это не средняя величина)
при создании поста запрос от пользователя (например с моб.приложения) уходит в некий пост-сервис, который размасштабирован условно по ноде на шард хранилища
этот сервис выдаёт пользователю image_id по которому клиент (моб.приложение) сможет сохранить картинку в медиа-сервис (его функционирование мы не рассматриваем, понятно что это гигантски размасштабированный но сравнительно более простой по логике сервис)
подписчик, когда смотрит в ленту, отправляет запрос на feed-сервис - он тоже размасштабирован, но безотносительно шардов
feed-сервис обращается в хранилище пользователей и выясняет на кого подписан этот человек - то есть, список user_id по которым нужно достать недавние посты
эти посты лежат в кэше недавних постов - ключом является user_id а значением - список постов (например за последние 7 дней)
feed-сервис получив списки постов которые нужно отобразить в ленте, мёржит их в один список с соблюдением порядка и отправляет пользователю (картинки же пользовательский клиент будет подгружать из медиа-сервиса по мере прокрутки - сразу их выкачивать не нужно)
если пользователь прокрутил историю больше чем на 7 дней то feed-сервис дальше должен обращаться за данными непосредственно в хранилище постов, а не в кэш (таких запросов будет сравнительно мало, так что это норм)
нужен ещё сервис который обновляет кэш по мере появления новых постов - он может работать по-разному, например пост-сервис складывает айдишники добавленных постов в очередь - а этот спокойненько себе занимается "балк-процессингом" их.
Всё это я придумывал на ходу чуть менее гладко. Впрочем интереснее продумать вопросы интервьюера после того как этот "общий скелет" был рождён:
как мы поддерживаем консистентность - например пост-сервис создал пост, а картинка в медиа-сервис не загрузилась (я ответил что тут можно разные политики избрать - либо удалять такой пост при обнаружении, либо отображать его без картинки - мало ли там что-то важное - конечно клиент должен несколько раз попытаться перезаслать картинку - и в любом случае узнать об ошибке, чтобы пользователь мог отреагировать).
как мы будем наращивать количество шардов по мере роста сервиса (я ответил что для этого у нас будет отдельный сервис, запускаемый когда происходят такие миграции - и описал как будет происходить копирование с разделением, потом перенаправление потоков постов и т.п. - в любом случае это достаточно нудный процесс требующий нескольких шагов и аккуратности)
как мы будем реплицировать данные (я ответил что в принципе у нас могут быть датацентры в нескольких регионах и пост-сервис может отправлять данные на сохранение сразу в несколько из них - хотя впрочем такие вещи могут решаться и отдельным обеспечением самих датацентров)
что будет происходить если нам удалось записать пост не во все датацентры (я предположил что мы всё же отвечаем юзеру "ок" если записалось хотя бы в несколько - а отдельный сервис будет задействован репликацией и восстановлением "упавшего" датацентра, или стойки, когда их "поднимут")
Тут я явно вдался в область о которой уже ничего практически не знаю - но, возможно, это действительно на уровне ниже архитектуры должно решаться. Например автоматическая репликация между датацентрами (или стойками) и т.п.
В одном из моментов я категорически оказался не согласен с интервьюером - или мне не удалось объяснить свою мысль. Он допытывался во сколько же копий нужно сделать запись, чтобы считать её успешной. В две, или три, или больше. Я отвечал что это вопрос выбранной нами "политики" и в целом он опирается на то насколько важными мы считаем данные постов и сколько денег хотим платить за инфраструктуру.
По-моему интервьюер вот эту мысль не хотел принять и даже отметил в обратной связи. Мне кажется что тут имеет место некая "косность" сознания "архитекторов крупных компаний" которые считают что инфраструктура дана свыше и ничего не стоит.
Напротив, когда ты разрабатываешь архитектуру например в облаке Амазона, ты всё просчитывает в том числе и непосредственно в долларах - и решаешь с какой кратностью ты будешь что-нибудь реплицировать, и нужно ли переплачивать вдвое, например, ради того чтобы вместо 99.99% сохранения постов обеспечить 99.999%
Рекрутёр после этого предложила мне пройти секцию "про опыт" (о которой ниже) и я подумал что архитектуру мне зачли "условно-успешно", а "опыт" должен её подкрепить. Однако их схемы выше можно понять и так что обе секции более-менее стандартны для уровня Senior - тут я честно сказать не до конца понял.
VK - финалы
В тот же день с архитектурой был и "финал" с VK - собеседование с двумя руководителями команды VK-видео. Как они пояснили, собственно видеопотоки обрабатываются отдельными командами и серверами (наследство от ОК якобы) - в их же ведении написание сайта в который видео вставлено, чатов в которых "стримеры" общаются с подписчиками и так далее.
Вообще этот созвон был утром того же дня когда вечером была архитектура - то есть я чуточку нарушил порядок изложения. Но сделал это потому что бОльшую часть созвона, по-моему, заняло очень похожее обсуждение. Мне предложили в духе:
Спроектировать чат, в котором стример общается с подписчиками
Почему-то одним из самых важных пожеланий было несколько раз выражено что стример в чате должен отображаться со значком короны (т.е. его посты), а посты от ботов "тоже с каким-нибудь другим значком".
В подробности вдаваться тут я не буду, поскольку как мне показалось к этой задаче сами собеседующие подготовились не очень тщательно. В частности странно казалось что когда я спросил "сколько стримеров - и их чатов - мы обслуживаем одновременно" - было отвечено, что об этом не надо думать, можно считать что чат только один.
Это конечно значительно снижало нагрузку (очевидно в чате нет смысла генерировать больше нескольких сообщений в секунду). В целом вы можете легко уследить параллели между этой задачей - и той с проектированием инстаграма.
Важный вопрос (об отображении короны и "иных значков") я пояснил, отмахнувшись, так: у нас тело сообщения это JSON - в нём есть сам текст сообщения - а есть ещё и флаги - и вот в этих флагах могут быть проставлены любые нужные значки и иконки - иными словами это вспомогательная информация к сообщению, ради которой даже колонку в БД заводить не нужно.
В то же время на этой задаче у меня случился довольно комичный "затык" - когда спросили "как же мы будем отображать пользователю, например, последние M сообщений в чате - я начал мудрить (что-то отдалённо похожее на то что позже объяснял в задаче с "инстаграмом") - и даже немного растерялся, думая что нужно вспомнить какую-то особую магию постгреса. Хотя как со смехом пояснил интервьюер, речь идёт просто об order by и limit в запросе, в духе:
select from messages where stream_id = ... order by msg_id limit 50
Тут могут быть вариации (например msg_id могут быть не сквозными но тогда можно выбирать по таймстемпам). Факт тот что я продолжал по инерции думать о том что у нас много-много чатов одновременно обслуживаются и надо на этот счет что-то изобретать - а интервьюер пытался понять насколько я вообще помню азы SQL :)
Немного странное впечатление произвело как тщательно интервьюер требовал придумывать название таблицы. Просто messages? нет, так нельзя, у нас ведь могут быть всякие другие сообщения, служебные и пр... А stream_messages? тоже нехорошо (не помню почему) ну и так далее - закончилось чем-то вроде user_stream_messages, но не уверен. Я уже немного рассердился и напомнил что в постгресе можно "схемы" использовать чтобы группировать таблицы. На это интервьюер как будто даже немного оскорбился, зачем мол схемы и т.п. :)
Я считаю что проект можно и нужно импрувить и рефакторить по ходу его жизни. Конечно таблицы переименовывать - это требует больше телодвижений, чем переименование переменных - но всё же это не повод чтобы на самом старте "зависать" пытаясь продумать в деталях названия всех элементов схемы данных. Тем более на собеседовании.
Помимо этой довольно долгоиграющей задачи были и вопросы об опыте, о проектах. Спросили про TCP и DNS зачем-то. Я даже не сразу понял что подразумевают вопросом "вот мы если подключаемся к серверу, то по какому протоколу идёт обмен" - говорю ну, SSL/TLS/HTTPS - не пойму что вы имеете в виду. А это про TCP оказывается. Ещё бы про физический уровень спросили.
Немного рассказали о проекте и его текущем состоянии (например, прозвучало что исторически он написан не на PHP как бОльшая часть VK а вообще на Perl - поэтому в команде есть и "перловики" - забавно, мне перл по своему нравится, но не ожидал его встретить в таком контексте).
Из того что HR мне предложила через несколько дней попробовать побеседовать с представителем другой команды я так понял что произвёл не лучшее впечатление. Не могу сказать что я сильно расстроился - у меня тоже сложилось странное впечатление о моих визави - как будто они не очень подготовились к встрече и с трудом пытались сообразить что хотят от меня узнать и о чем спросить.
Попытка #2
В качестве второй попытки мне назначили собеседование с представителем VK-музыки, а точнее, как пояснил интервьюер, пришедший на встречу - к инфраструктурной части VK-музыки.
Вообще интервьюер представлял значительный контраст со своими коллегами - как мне показалось более молодой и оптимистичный. Пустяк - но пожалуй такие вещи немало помогают и кандидату.
В этот раз не было никаких технических вопросов, ни архитектурных задач. Мы целый час в общем-то говорили о компаниях и проектах в которых я работал - по-видимому интервьюер пытался поточнее понять "какие проекты нравятся, какого типа и т.п."
На это я со смехом ответил что (как и многим программистам) нравятся мне проекты за которые никто платить не будет, поэтому таковыми я занимаюсь в свободное время, для развлечения. Вообще показалось что мы по ряду вопросов "на одной волне" - вплоть до отношения к применению AI в разработке (консервативно-осторожного) и упоминания "алгоритмов, структур данных, паттернов и принципов программирования" в описаниях вакансии.
За отсутствием технических вопросов и задач об этой встрече мало что можно добавить - упоминаю я её в основном как демонстрацию что у разных интервьюеров (в т.ч. на "финале") может быть очень разный подход. В данном случае визави явно подготовился - по видимому заранее просмотрел резюме, не только выцепил взглядом названия знакомых компаний - но даже отметил используемые технологии, задачи на проектах и т.п. - так что мне нужно было не столько рассказывать "с нуля" сколько чуть расширить и пояснить то, что он уже выяснил и так.
Яндекс - секция "про опыт"
Когда HR предложила мне (настойчиво) пройти эту секцию, я несколько удивился. Судите сами:
Секция про опыт кандидата Для секции нужен слот в 1.5 часа. В ходе этой секции интервьюер оценивает опыт кандидата — в проектировании, разработке, эксплуатации и обслуживании реальных систем. Во время беседы рассматривается пример одной крупной задачи, поэтому важно тщательно подобрать показательный кейс. Нужно будет выбрать самый интересный проект из твоего опыта Проект должен быть закончен (то есть быть внедрён в продакшен) и иметь ограниченный скоуп Проект должен быть свежий (до 7 лет) В этом проекте кандидат должен играть ключевую роль с точки зрения технических вопросов — то есть быть техлидом, архитектором и пр. Кандидат должен быть готов подробно рассказать детали технических решений, так что проекты под жёстким NDA не принимаются...
Итак резюмируя:
нужен проект где я был лидом или архитектом (это на уровень сеньора)
должен быть как можно более сложным
он должен быть относительно недавним и быть в проде
не быть секретом фирмы (чтобы о нём можно было рассказать)
Я, так сказать, развёл руками - конечно, бывало небольшое количество проектов где мне выпала "лидирующая" роль - но чтобы они одновременно всем требованиям удовлетворяли - это прям как-то нереально.
Спрашиваю - а нам точно это надо? Зачем пытаться "демпинговать грэйд" если по предыдущим этапам уже выявлено что я, вроде бы, не дотягиваю до их высоких требований :)
Тут произошёл диалог, второстепенный по смыслу, но который важно упомянуть для последующего контекста: в частности я предложил "синхронизироваться" по нашим взаимным ожиданиям, напомнил что ищу удалёнку и спросил про предполагаемые уровни зарплат по грэйдам. HR стала говорить как почётно работать в Яндексе, мол "это крутая строчка в резюме", рассказывать что "сейчас многие компании переводят сотрудников в офис", но впрочем согласилась что удалённые вакансии есть - а касательно цифр сказала "360 в вилке senior" - я на тот момент не обратил внимание на необычное построение фразы :) Также упомянула что "у нас бОльшую часть дохода составляет премия по результатам перфоманс ревью, оно проходит 2 раза в год - премия от 1 до 4 окладов". Интересно, конечно, насчет того что "премия - это бОльшая часть дохода..." :)
В общем, HR была очень настойчива (я так понимаю что от определенного грэйда кандидата в результате зависит и бонус HR-а) так что в конце концов предложил список из трёх проектов о которых мог бы рассказать. Его я оформил в гугл-документ на полторы странички с кратким описанием сути проектов - так чтобы HR могла прямо передать этот список интервьюеру, а он бы выбрал.
проект "шины сообщений" для распределенной системы на базе кафки в буржуинском ритейлере OCADO - там я напроектировал и написал в одно жало сервисы вокруг кафки, которые не только создавали REST-интерфейс к ней - но и позволяли хитроумно маршрутизировать сообщения по настраиваемым правилам, вплоть до разбора полей JSON-ов регэкспами - к сожалению это было аж в 2015 году да и честно говоря проект не кажется таким уж сложным (по крайней мере когда всё придумано и сделано)
бэкенд крипто-телекомного стартапа, по мотивам проекта Helium - в этой команде мне выпала радость не только бэкенд написать но и первые версии смарт-контрактов в блокчейне, и интеграции с NFT-маркетплейсами, с мобильными операторами - это было недавно, но я среди себя также не считал проект достаточно сложным - да и хотя он в проде (у него есть сайт, карта, статистика - даже крипту можно купить) - мне он не кажется успешным в смысле бизнеса
мой собственный проект CodeAbbey - сайт с задачками по программизьму, отдалённо по мотивам ProjectEuler / TopCoder / CodeForces (или более современного LeetCode) - недостатком этого проекта являлось то что он точно некоммерческий - и высоконагруженным конечно он не является.
Интервьюер выбрал "крипто-телеком". Про сам проект здесь рассказывать смысла нет - у каждого проекты свои - возможно главная часть подготовки - создать хотя бы небольшую презентацию (у меня получилось примерно штук 7 страничек), которые поясняли:
в чем заключается "телеком" составляющая - что за беспроводные протоколы использовались, какие типы датчиков - короче, в чём физическая суть
из каких частей состоял в общих чертах бэкенд
как выглядела команда и где в ней моё место (поскольку это был совсем небольшой стартап - не было проблемы поимённо написать как распределялись роли)
статистика проекта - взял скриншоты с сайта (удивился что сайт ещё жив и даже нашёл в нём с умилением много следов своего участия)
Вот, например, картинка по второму пункту:
Такие, даже грубо сделанные изображения, значительно помогают в ходе рассказа - как кандидату, так и интервьюерам. Если вы не сделаете этого заранее, вам скорее всего придётся искать какую-то графическую доску по ходу и криво-косо на ней что-то малевать. Поэтому имеет смысл подготовиться.
Резюмируя - я подозреваю что ребятам, проводившим этот этап, было скучновато - хотя проект (и его бэкенд) достаточно широкий по функционалу и разнообразным интеграциям (я наверняка ещё много нудных мелочей забыл но их и вряд ли стоило упоминать) - но какой-то заметной сложности в смысле "высокой нагрузки" он не представлял (по крайней мере на стартовом этапе). Наиболее "нагруженной" частью являлся "event-service" через который в принципе проходили все пакеты приходящие с датчиков, то есть в гипотетическом будущем это могли быть сотни и тысячи в секунду - но это вполне решалось шардированием же, не говоря уж о том что на стартовом этапе никаких подобных нагрузок не могло возникнуть. К тому же по обратной связи выглядело так, будто интервьюерам хотелось чтобы разработчик был с девопсом в одном лице :)
Впрочем, как я понял, один из интервьюеров "практиковался" в проведении секций этого типа - а второй был его ментором по этой части. Так что по крайней мере они смогли "потренироваться" на мне и описанном мною проекте :) В целом они, возможно, произвели вполне позитивное впечатление на фоне всех секций Яндекса упомянутых до сих пор. Вопросы задавали вдумчивые и по делу, явно активно вникая в суть проекта.
Яндекс - отказ и удивительные открытия
Спустя пару дней пишет мне HR - сперва пространный фидбэк по поводу секции "опыта", как я и предполагал, сводящийся к тому что хотелось бы услышать про "более сложный" проект. В конце же резюмирует отказ в такой форме:
Дальше про финальный грейд, по итогам результатов всех секций, коллеги которые ревьюили секции выставили грейд Middle+, и из-за этого я сомневаюсь в том, что мы сможем подобрать тебе релеватную вакансию. Ты явно ожидаешь сеньорскую вилку и сеньорские задачки. Но по результатам секций имеем, что имеем ? вилка ниже, и задачи проще. Получается, если мы тебе предложим то, что можем предложить по деньгам это будет сильно ниже твоих ожиданий и наверное даже текущего уровня. То же самое и в плане задач - скорее всего, это будет слишком скучно для тебя. Поэтому, к сожалению, на финал мы не выходим, тк не сошлись ни по деньгам, ни по сложности задач.
Меня вовсе не удивил "вердикт", но озадачила мотивация. Спросил из любопытства, откуда взялся вывод насчет "сеньорских ожиданий". (не говоря уж о том как это HR оценивает "интересность" задач для разработчика). И происходит такой обмен репликами:
-- мы на hr скрининге с тобой обсуждали зп ожидания
-- да, но разве я назвал какую-то цифру? :)
-- Александра, прости за прямоту, но такого в разговоре точно не было. Я отказался называть ожидания, предложив посмотреть в моем резюме - и сказал ещё что предпочитаю отталкиваться от предложений работодателя.
-- у меня записано 360, не знаю, насколько это актуально сейчас
В общем, диагноз проясняется :) хотя остаются второстепенные вопросы. Откуда она это взяла? Зачем тратить время на HR-созвон если нет возможности адекватно записать информацию? Риторическое...
Прояснив вопрос с тем что "сеньорские ожидания" были, вероятно, не у меня а у неё, однако вышли на новую препону:
мы точно на этом грейде [Middle+] не согласуем удаленку с HRBP - сейчас таких вакансий во всех сервисах не много
Отметим в скобках - фраза звучит так, что кроме рекрутёра занимающегося поиском кандидатов и сопровождением процесса собеседований с одной стороны - и отделов которым требуются работники с другой стороны - тут оказывается приходится учитывать мнение HR Business Partner который может из собственных туманных соображений препятствовать найму, даже если остальных кандидат потенциально устраивает. Вы можете почитать что это за непонятная сущность в оргструктуре - они сейчас в разных компаниях присутствуют - но я впервые слышу чтобы их участие выражалось в такой форме.
Итак, по прошлым собеседованиям в Яндекс (в том числе в 2024 году) я помнил, что к удалёнке они сложно относятся. Но ошибочно предполагал что у них эта информация записана (с прошлого раза). Раз уж HR решила выйти на меня.
Кроме того, вот так выглядит шапка моего резюме на HH:
Как ни крути, это не выглядит близко к 360. И слово "удалённо" как бы намекает что это даже не гибрид.
Примечание: не воспринимайте указанную в резюме цифру как референсное значение. За последние несколько лет моя з/п нередко сильно колебалась в том числе с курсами национальных и интернациональных валют - так что я не уверен, насколько это соответствует "текущему состоянию рынка".
И теперь давайте взглянем на "просмотры" - поскольку сам я сейчас не "откликаюсь", то здесь видны только компании которые активно просматривают "базу резюме":
Как можно видеть, Яндекс сканирует резюме чуть ли не чаще чем все остальные (в основном, кадровые агентства) вместе взятые.
Каким образом в этой системе HR умудряется использовать какое-то (якобы "старое") резюме из внутренней базы - это непонятно.
Как итог - всё время HR и интервьюеров было потрачено зря. Ну не совсем зря - я-то с ними мог в чём-то попрактиковаться - но для компании это, кажется, выброшенные на ветер деньги.
Как ироническую демонстрацию насчет того что HR-ы вообще теряют информацию о кандидатах отмечу и такой факт - в 2024 осенью я проходил в Яндекс собеседования (как упоминал выше), которые мы досрочно свернули. В начале 2025 мне опять стучались от них HR которые заявили что у них нет информации чем закончилась предыдущая серия интервью. Я попросил чтобы сделали отметку - больше мне не писать и не звонить. Сказали что сделают - но, очевидно, если такая отметка и была - она затерялась.
Заключение
Вообще насчет "потенциальных улучшений" которые рекрутинг мог бы взять на вооружение - идей очень много. Однако попробуем сконцентрироваться на нескольких наиболее значимых (м.б. не только для Яндекса).
Первым (нулевым!) пунктом отметим что HR должны иметь свежие версии резюме кандидатов, тем более если компания регулярно сканирует обновления на HH.
Далее посмотрим на "проблемы" подчёркнутые в упоминавшейся выше статье. Они в какой-то степени пересекаются.
Процесс найма очень долгий, а этапов и дублей очень много - очевидно, он таким и остался! Хорошо ещё мне "алгоритмы" зачли с прошлого раза, а то ещё несколько дней бы добавилось.
Это плохо не только для кандидата - в бОльшей степени это проблема для самой конторы. Если среди конкурентов много компаний куда можно пройти собеседования за 2-3 недели, а мы не можем вписаться в месяц - почти наверняка часть кандидатов не дойдут до конца, получив оффер раньше (как это случилось со мной в 2024 году).
Как упомянуто - две секции "кодинга" реально похожи одна на другую. Уместно их скомбинировать - либо давать две задачи за один присест и оценивать и алгоритмы и знание языка. Можно увеличить время с полутора до двух часов и использовать всё-таки хотя бы полуавтоматическую проверку, тесты (а не вот это "сейчас я пробегусь глазами, э-э-э-э") чтобы это время не затягивать. Пример аналогичной секции VK в целом неплохо показывает ситуацию где можно и язык и алгоритмы обсудить.
Если взглянуть шире - то мы понимаем что в течение 3-4 секций кандидат проходит "расширенный скриннинг" с участием специалистов из произвольных отделов. Тут можно задуматься насколько адекватно включать в этот процесс секции по "архитектуре" и "опыту". Обратим на это внимание чуть ниже.
Процесс не всегда прозрачный - если считать что "табличка этапов" увеличивает прозрачность, то этот шаг сделан. Однако это очень маленький шаг и реально всё остаётся довольно мутным. Возможно мутнее всего - почему секции именно такие. Руководитель проекта, в который требуется разработчик, имеет очень ограниченные возможности как-то повлиять на "общий фильтр", как-то акцентировать потребности связанные с его проектом.
Всё это было бы допустимо, если бы фильтр был достаточно умеренный - но в текущей ситуации слишком много достаточно рандомных факторов. Кто-то может сыпаться по психологическим причинам на live-coding сессиях или вообще отказываться их проходить. В моём случае, например, было явно понятно какого ответа хочет интервьюер по архитектуре на вопрос о количестве копий - фактически он м.б. добродушно пытался подвести к ответу который хотел услышать. Но у меня не было (на текущий момент) особой мотивации соглашаться и поддакивать :) Или этап про "опыт" - по обратной связи я заподозрил что интереснее выглядел бы проект в котором разработчику приходилось больше девопсить. Возможно рассказав про небольшой проект который мы разворачивали в амазоне с помощью CloudFormation я бы лучше "попал" в то что интервьюер хотел услышать.
Но как от этого зависит оценка "сеньор или нет"? Я не говорю что это плохо, но целей прозрачности тут достигнуть нереально. :)
Плохая обратная связь после секций - да, по крайней мере сейчас какую-то обратную связь возвращают, но по мне важнее та "связь" которую ты можешь получить во время собеседования в диалоговом режиме. А читая через пару дней замечания оставленные интервьюером неизбежно находишь повод удивиться.
На секциях решаем задачи, которые не встречаются в работе
Тут автор статьи отмечает что "это вечный холивар". Холивар-то холиваром, но в комбинации с проблемой затянутости процесса это явно просто "вопиет" об оптимизации.
Насчет секций лайв-кодинга уже было сказано выше. Насчет "архитектуры" и "опыта" - отчасти тоже. Но давайте к ним вернёмся - насколько часто руководитель будет приходить к нанятому сеньору и просить спроектировать "инстаграм"? :)
Не говоря уже о том что запас задач этого класса довольно небольшой и все эти "инстаграм", "чат", "сервис сокращения ссылок" гуляют по собеседованиям с незначительными модификациями.
Как тут быть? Возможно нужно договориться чтобы руководитель проекта/команды, делая запрос на найм сотрудников, указывал какие секции ему кажутся важными. Например он может предпочесть про "архитектуру" поговорить сам, на финальном интервью. Да и про опыт тоже.
Отдельно отметим что в процессе яндекса отсутствует секция со "скриннингом по вопросам". Меня никто не спросил какой индекс в БД лучше или как работает DNS.
Может тоже решили вынести на "финал"?
И ЕЩЁ КОЕ-ЧТО
Вообще "Агрессивный поиск кандидатов" при котором рекрутёры обстукивают телеграм, почту и т.п. не отвечает целям серьёзной IT-шной компании. Автору упомянутой статьи нужно бы мечтать не о том чтобы "ужать" существующие секции в 2 недели, а о том чтобы вообще изменить идеологию. Подход при котором кандидаты сами приходят и находят путь в компанию, в проекты - он гораздо более плодотворный. К сожалению он требует некоторых усилий со стороны квалицицированного технического персонала, говоря общо - изобретение всевозможных челленджей, квестов, контестов, оффлайновых задач, опенсорсных проектов - через которые можно получать себе работников.
Гораздо легче, кажется, увеличивать поголовье менее квалифицированного персонала - рекрутёров а то и "сорсеров" которые могут фрилансить на полставки в свободное от учёбы время. Брать не количеством а качеством.
В какой-то старой книжке был фрагмент когда компания объявляет набор телепатов. Конечно откликается множество людей заявляющих о своих паранормальных способностях. Их всех держат в приёмной, анкетируют, и некоторое время провялив отправляют домой с просьбой приходить ещё через столько-то дней. А в это время настоящий штатный телепат усиленно посылает мысленный сигнал "кто меня слышит - пройдите в маленькую дверь в левой стене".
Подходы в этом ключе позволяют не только уменьшить количество однообразных и мутных "скринингов", но и выявить действительно мотивированных кандидатов.
К сожалению здесь недостаточно места чтобы развить эту мысль, да и выходит она за пределы повествования об опыте прохождения этих двух цепочек собеседований в Яндекс и ВК.
Комментарии (124)
Sharque
11.03.2026 05:42По поводу "когда кандидат приходит сам" - есть отвратительный кейс, на сайте Я и ВК с завидной периодичностью публикуются интересные вакансии, но если вы на нее отзоветесь, ответите или еще как-то напишите "я хочу вот этим вот у вас работать" - ничего не будет. Скорее всего никто даже не ответит. Почему-то везде срабатывает подход "он сам пришел, наверно его никто не хочет, пожалуй лучше отказать". И нет это не только в Я, в свое время пока меня гуглоид самолично не толкнул в кадры гугла - они тоже даже не смотрели в мою сторону.
RodionGork Автор
11.03.2026 05:42Скорее всего никто даже не ответит.
да, этот функционал явно сломан
впрочем я имел в виду более хитроумные способы - не помню, упомянул ли конкретно Telegram - там процесс на этаких мини-челленджах выстроен вроде
https://www.businessinsider.com/telegram-ceo-looks-for-best-engineers-2025-10
у Яндекса самого на сайте например раньше (лет 10 назад) ещё был собственный "скриннинг", и это работало с грехом пополам, но явно уже никто не поддерживал и оно было на излёте
Были у них Яндекс-Алгоритм и Интернет-Математика соревнования - в общем тоже неплохие проекты чтобы через них завлекать.
А в результате имеем что имеем - вот эти низкоквалифицированные эйчары которые пытаются "брать числом".
Quintanar
11.03.2026 05:42Это же логично. Прийти может кто угодно, скорее всего полный 0. А если человека нашли, то он уже считай прошел один фильтр. Я был бы hr, тоже бы писал отобранным людям.
Shoman
11.03.2026 05:42Фигня все это, мне пишут из компаний находя мое резюме на hh или еще где, которые я 10 лет не обновлял. Соответственно там и технологии указанные все уже вымерли и в целом.. какой я фильтр прохожу?
Ghrec
11.03.2026 05:42Возможно, и не смотрят, но мне ответили отказом именно с тех вакансий, к которым опыт был наиболее релевантным
Biomoloko
11.03.2026 05:42Ну что сказать, "на каждого мудреца - довольно простоты".
Процесс нвйма отобрадает и работу самих компаний - излишне замороченые и не последоваиельные, и обе работают через задницу.
Начиная от работы эйчарки, заканчивая её же закрытием вакансии - на каждом этапе есть огромные косяки, не логичные требования и решения.
Точно так же работают и их приложения. Очень много внимания там где не нужно и полное отсутствие внимание в критичных местах. Как если бы повар готов стейк подарил бы 30 грамм мяса и пол кило овощей.
Который раз убеждаюсь, что люди ответственные за принятие решений в этих компаниях - обыкновенные е**наты.
Quackerjack
11.03.2026 05:42Нда, такой затянутый найм, который на выходе не дает заявленного эффекта. Потратить месяцы на поиски сотрудников не на ключевые позиции, чтобы выиграть сколько процентов в качестве? Во сколько это обходится? Обожаю считать их деньги, особенно когда при такой растрате, тебе потом предъявят, что ты слишком большую ЗП просишь.
И при всем этом, регулярно обсираться в разработке поведения и интерфейсов для такой детерминированной среды как ios, сужу по Кинопоиску и Телемосту. Телемост, вообще нормально работать на ios уже год наверно не может.
Замах на рубль - как будто всех нанимают на кровавые энтерпрайз задач бэка с рисками словить арбитраж от контрагентов за простои, а по факту - соискатели льют такой же пот, чтобы работать над апликухами для физиков и слать бесправных клиентов с их претензиями лесом через ботов. Я блин час доказывал ЛК, что я не идюк.
RedWolf
11.03.2026 05:42И это все, чтобы сказать человеку, что 360 - это завышенные требования? Яндекс work for food какой-то.
u_u
11.03.2026 05:42360 на мид+ действительно много.
Stan91
11.03.2026 05:42Чисто оклад - да, если с годовой премией хотя бы в 20%, то это оклад 300 и на мид+ это имхо нормально.
Учитывая что мид+ и синьоры по факту ничем не отличаются (не путать с лидом который лямку тянет за всех), то 300 оклад за одну из ключевых рабочих лошадок проекта чего бы и нет
ADEXITUM
11.03.2026 05:42Это сеньор. В статье сказано. И я ток что проходил собес. Вилка мид+ 280 / синиор+ 380... Дада... В Яндексе. Это что там сделать надо чтобы стать синиор+ я знать не знаю.
Не удивлюсь если это до НДФЛ. В целом много слышал что Яндекс платит ниже рынка.
RodionGork Автор
11.03.2026 05:42что там сделать надо чтобы стать синиор
не спорить с интервьюерами, даже если на твой взгляд они тупят :)
RedWolf
11.03.2026 05:42Человека на собесе просили спроектировать приложение на миллиарды юзеров, а платить хотят двести с чем-то. Две с чем-то тысячи евро. Я в шоке от такой наглости. Это было ок лет так шесть-семь назад, когда евро был по 70-80р, ипотека была 5-6%, а импортное пиво по 100-150р, но не сейчас же.
u_u
11.03.2026 05:42Человека попросили воспроизвести пример из книжки по микросервисам /s
RodionGork Автор
11.03.2026 05:42Ну да, я бы сказал что эти "архитектурные собесы" уже очень шаблонными стали - даже без книжек шардирование, кэш, очереди - ключевые моменты :) Тут и затык-то больше возник не в технической а в стратегической части архитектуры. И не уверен что на моей стороне.
DMGarikk
11.03.2026 05:42Хватает у вас еще мотивации с ними собеседоватся, ко мне яндекс очень часто стучался до НГ, пока я уже чутьли не матом их не начал посылать, сходил разок на их собес и ушел с первого этапа...тратить две+ недели времени на чесание эго их интерьвюверов по академическим задачкам както совсем не интересно, особенно если в итоге отказ будет, что я не совсем олимпиадный гений
HiItsYuri
11.03.2026 05:42Так там же алгобаза спрашивается, литкод изи, ну может редкие медиум задачки.
DMGarikk
11.03.2026 05:42в 3-5 итераций и с придирками?
зато аглобаза крутая... пфф.. качество софта яндекса както совсем не кореллирует с тем кого они там себе набирают
в реальных проектах алгобаза не является определяющей ценностью разработчика
Sequoza
11.03.2026 05:42Разрабы с опытом в N-лет, решающие проблемы реального бизнеса, конкурируют со студентами, которые последние 4-6 лет только и занимались литкодингом. Что может пойти не так?
HiItsYuri
11.03.2026 05:42Если разрабу с N лет нужно конкурировать со вчерашними студентами - он делал все это время что то не то или не так, да и не то чтобы это прям показатель. Можно годами чилово перекладывать json и за это время деграднуть до уровня буоыжника.
Позиции разные, и студентов никто не берёт выше Джуна. С очень редкими исключениями.
aldekotan
11.03.2026 05:42Предположу, что речь не о прямой конкуренции. Фильтр одинаково плохо работает и для тех и для других, но если для джунов убитое на литкод время окупается и они таки проходят, то для кого-то с реальным опытом работы литкод кажется пустой тратой времени - и они отсеиваются по нему. В результате в компании всегда избыток студентов, но нехватка опытных специалистов.
Напоминает ещё ситуацию с ЕГЭ. Чтобы получить высокие баллы многие задания прорешиваются многократно, так как у них есть определённый паттерн, свои условия и "ожидаемые решения". С эрудированностью или способностью разбираться в предмете такие задания, зачастую, связи не имеют, о чём свидетельствуют олимпиадники тех же предметов, не проходящие на максимальный балл.HiItsYuri
11.03.2026 05:42Олимпиада же перпендикулярна ЕГЭ, это более простой способ поступить в нормальный вуз, не? Если есть время на подготовку конечно же и понимание чего хочется.
Фильтр работает плохо, но он работает хоть как то, лучше чем ничего. Но количество интервью конечно нужно сокращать, мне в свое время было прикольно их проходить, стресс + скил чек.
DDroll
11.03.2026 05:42...а можно понять, что реальная разработка состоит на 1% из алгоритмов, 40% из знания кейсов (ой, простите, ОКАЗИЙ) и на 59% из взаимодействия с командами и заказчиками, и именно в этих областях у опытных разработчиков накапливается экспертиза, а лежащие плесневелым барахлом с универа алгоритмические знания постепенно вымываются системами оптимизации мозга. Нет, можно освежить, порешать задачи - но есть ли у занятого и семейного сеньора на это время? Я лично лучше своими петами (простите, ПОДКАЛЫМКАМИ) позанимаюсь, чем чьи-то насосанные из пальца фентезийные ожидания оправдывать, и то пользы на порядки больше будет для реальной работы.
Gay_Lussak
11.03.2026 05:42HR позвал меня на вакансию C++ разработчика в автономный транспорт. В требованиях — инференс нейронных сетей, математика, CUDA. В общем, довольно близко к моему профилю.
На первом техническом интервью внезапно оказался бэкенд-инженер. Он даёт задачу на LRU cache, просит найти проблемы в реализации, а потом переделать её в LFU.
Где-то ко второй половине разговора (на 1 час) я вспоминаю детали работы LRU пишу по заданию юнит тесты к нему и затем переделываю решение в LFU.
После этого приходит отказ: я, оказывается, «не увидел проблемы в реализации». И только с наводящими вопросами поправлял реализацию. И еще ожидалось, что я должен успеть реализовать многопоточную версию!
То есть схема примерно такая:
ищем инженера под задачи инференса, математики и CUDA,
на интервью ставим бэкенд-инженера,
даём классическую бэкенд-алгоритмическую задачу,
а потом удивляемся, что кандидат не ответил на неё идеально.RodionGork Автор
11.03.2026 05:42спасибо что поделились :) это конечно покруче чем в моём случае
видимо не очень им нужны разработчики, тем более на автономный транспорт. в китае закупают всё, от роверов до колонок
Ghrec
11.03.2026 05:42Может, тогда в китай надо собеседоваться?
К тем, кто им все это поставляет
RodionGork Автор
11.03.2026 05:42у нас есть же и локальный китай в виде затаившегося Хуавея :) отечественному разработчику режим китайской компании не очень придётся по душе
RodionGork Автор
11.03.2026 05:42Абсолютно вас понимаю :) иногда тоже посылаю. Но Яндекс стучатся буквально раз в несколько месяцев, похоже не хранят инфу о собственных неудачных попытках. Так что иногда ввязываюсь, вот как сейчас, в их собеседования - больше, наверное, для поддержания тонуса. Иногда что-то новое можно узнать. Ну и задачки порой потом для своего сайта адаптирую.
Femistoklov
11.03.2026 05:42Сколько в итоге своего времени выбросили в урну?
RodionGork Автор
11.03.2026 05:42Можно просуммировать :) Суммарно кажется чуть меньше двух рабочих дней.
Но я не считаю это совсем уж "выбрасыванием в урну". Можно что-то новое узнать, в чём-то потренироваться. К сожалению повседневная работа на текущем проекте тоже часто является очень неэффективным времяпрепровождением.
bfDeveloper
11.03.2026 05:42Хотел бы отметить, что задача с топом статей могла подразумевать решение через отдельное хранение топа в куче, а не массиве или дереве. Цена построения N*log(K), где N - общее количество статей, K - размер топа. Вставка за log(K), поиск линейный, но от K, а не N, да и индекс можно прикрутить сбоку. Может надо ещё покрутить, но почти всегда топы лучше всего делаются через кучу.
RodionGork Автор
11.03.2026 05:42Спасибо. Вы имеете в виду хранить одну кучу для топа и другую для всего остального?
bfDeveloper
11.03.2026 05:42Да. В предположении, что топ небольшой относительно всего объёма новостей, это небольшие расходы памяти ради снижения сложности получения топа. Это получается небольшой дополнительный индекс, потому что основное хранилище имеет смысл сортировать/хэшировать по id, а не score.
RodionGork Автор
11.03.2026 05:42да, для топа из 1000 новостей это действительно пустяк. я об этом варианте подумал вскользь, но кажется в спешке именно просто сказал себе "я же не смогу найти в куче", не додумал мысль до конца :)
интервьюера я убедил что на одной куче можно сделать (после собеседования понял что обманул его, просто очень уверенно)
Kovurr
11.03.2026 05:42Получается что ничего не изменилось. Болото, от которого стоит держаться подальше, ибо жаль потерянного времени. Кого они с такими "процессами" набирают - загадка.
RodionGork Автор
11.03.2026 05:42да, получается именно так
я подумал раз уж написали ту статью, наверное не зря, наверное большая работа проведена. но похоже работа по большей частью написанием статьи и косметическими мелочами по существующему процессу.
Onito
11.03.2026 05:42Достаточно посмотреть на кривые поделки которые они называют софтом, чтобы понять кого они набирают.
RicoX
11.03.2026 05:42Как же все поменялось. В далеком 18 году проходил собеседование в ВК (тогда еще Mail.ru) и весь процесс занял от первого созвона с HR до получения оффера что-то около недели, я еще был приятно удивлен процессу, созвон с HR, созвон с инженерами от предполагаемых коллег, личная встреча в офисе, оффер на следующий день после встречи, позиция сеньорская. Тогда еще мысленно похвалил службу рекрутинга за четкую структуру и отсутствие лишней бюрократии, в отличии от Яндекса с их десятком этапов, где каждый следующий ничего не знает о предыдущих. Но из текста понял, что эта дурость с затягиванием процесса настигает все больше компаний.
DMGarikk
11.03.2026 05:42+1, я гдето в 19-20 годах туда устраивался, очень и очень лайтово собес у меня прошел, буквально HR+коллеги
PastorGL
11.03.2026 05:42состоялся у меня c ычаркой из яндекса (довольно опытной, надо сказать, поначалу глупостей не несла) на прошлой неделе такой диалог:
— на техническое собеседование будет live coding...
— какие задачи?
— ну, с литкода...
— а зачем? у меня около 25 лет опыта, есть проекты в проде с открытым кодом, вот ссылка на гитхаб: (даю ссылку)
— ну, потому что нам надо оценить как вы кодите...
— так, стоп. у. меня. проекты. в продакшене. работают прямо сейчас. и вот он, мой код, который прямо сейчас сотни терабайт молотит в облаке на амазоне. почему нельзя его оценить?
— ну... вам что, не нравятся головоломки?
— нравятся. но реальные задачи с реальными кейсами, а не синтетика. я слишком стар для олимпиадных задачек. в студенчестве баловался, конечно, но это было в 2000 году последний раз.
— ну, просто у нас так принято...
— до свидания.DMGarikk
11.03.2026 05:42да чё толку с ней спорить то, они все давно в курсе что никому их собесы не нравятся
мне они говорили, еще про Воложе, что такие собесы это личное пожелание топов компании и они (он?) считают что это лучший способ отбора лучших
NIKEtoS1989
11.03.2026 05:42Может всё-таки не лучших, а лояльных бренду, желающих получить эту строчку в своём портфолио?
Bratken
11.03.2026 05:42Столько времени на 2 несчастные компании потратить, это боль. Обычно начинаю с нонеймов или просто тех, к кому не жаль не попасть, чтоб потренироваться.
Последний раз поиск работы (в 2024) занял 2 месяца. До этого в среднем 1 месяц. Правда я по 5 техсобесов в день иногда делал по 40-80 минут каждое, а с рекрутерами было ещё больше. Почему так плотно? Именно из-за того, что быстро пришло понимание, что найм это спектакль. И работа в большинстве компаний это корпоративный спектакль. А нужно найти "своё".
Я QA, кстати. Тоже понял, что компании сами не знают, кто им нужен (и тут в комментах это подметили). Либо знают, но скрывают это за HR'ами, которые ходят вокруг да около вместо того, чтоб честно объяснить расклад. В итоге тратят и своё и ваше время. Ну и да, очень часто задают вопросы в духе "угадай, о чём я тебя спрашиваю". И это бесит, потому что тебя максимально держат за тупого, спецом не выдавая инфы.
В итоге в течение каждой смены компаний набиваю где-то по 30-50 техсобесов. Не скажу, что горжусь этим, потому что тут напрашивается вопрос "а чё так много и чё так долго?"... но кто ж знал, что ИТ в болото превращается так активно. Бывали изи собесы, конечно, когда 1.HR 2.Лид. И вот тебя уже зовут. Но это не панацея, и в итоге ты окажешься в гнилой конторе. Просто попадешь туда без кучи этапов и будешь либо в токсичной среде, либо в унылой среде просиживать штаны, делая по 1 задаче в неделю (не осуждаю, но еще не дозрел до такого. А вообще не люблю терять время, даже если это работа).
В своём кругу были разработчики, которые прибегали из всяких яндексов в мою прежнюю нонейм контору на 30 людей. И наоборот - кто из нонейм конторы сбегал в яндексы. А другим сбер был родным домом (там же мемы про потерю навыков и "последний шанс" уйти в другой банк). Золотая середина в виде контор на 500-2000 человек выглядит золотой. Но это такая скользкая дорога - либо вы сработаетесь в команде и дальше вас пасти не надо, и будет мир труд май. Либо в порыве страсти руководство начнёт упарываться по менеджменту, над вами поставят некоего лида - а на самом деле это манагер, который начнёт всё сводить к тому самому performance-театру, где производительность оценивается по закрытым задачам, и любое "иное" мнение будет глушиться. И все скатится в болото. В крупных неповоротливых машинах, вроде яндекса или сбера, всегда будет сюр и туда если идти, то, наверное, будучи на пенсии, выплатив ипотеки, вырастив детей/внуков, и не имея больше главных жизненных задач, когда уже не жаль на что-то потратить время и ты добровольно готов в такие места идти.
Мне кажется, автор (и другие) не учитывает все эти культурные нюансы, т.к. вы же не одни там будете работать, а с другими разработчиками, у которых опыт отличается от вашего. И сейчас имя компании ничего не значит. Говорю как человек, который за 9 лет сменил 7 компаний. 5 из которых на слуху 100%. Лишь в двух мне понравилось работать. Одна нонейм (сам ушел), вторая относительно известная (но сократили). Важнее уметь задавать правильные вопросы, чтоб понять, что перед тобой та самая команда, в которой ты бы хотел работать. А вообще тут нет единого правильного рецепта найти место. Все очень ситуативно.
Ещё на "подумать" - ну точно не должны собесы столько времени занимать. От силы неделя все этапы, если ты в конкретную команду пробуешься. Там думать по поводу кандидата нечего, если ты общаешься непосредственно с будущим лидом/коллегой. И решается это на месте. Когда сам наймом занимался, то помимо техники спрашивал вообще, как человек работал на прежних местах и за что отвечал. И по таким рассказам обычно сразу становилось понятно, нужен такой человек или нет. Чего тут думать?
И еще одна тонкая тонкость. Нейродивергенции, т.к. большинство людей в ИТ это ND-люди (аутизм, аспергер, СДВГ и прочий спектр). Кто-то научился с этим жить, кто-то нет (все вот эти шутки про "подкинь дровишек" о том, что программисты понимают всё буквально) - это тоже важно уметь распознавать. И прекол в том, что нередко компании спецом строят найм так, чтоб таких людей отсеивать, т.к. корпоративные среды приспособлены для нейротипичных людей.
IgorPie
11.03.2026 05:42имхо, у команды свои интересы, у эйчара - свои, + нехватка людей, поэтому собесит не команда, а чья очередь страдать подошла.
эйчары меняют условия на ход ноги, потому что им надо закрыть давние висяки чтобы выйти на премию, вот и прогибают на отказ от удаленки, переезд в Москву/СПб и т. п. потому что на всяких роботов/картографию в офисе желающих особо и нет, а новые вкусные вакансии яндекс подкинет после закрытия невкусных.
еще, полагаю, все тащат в офис потому что не за горизонтом белые списки и с работой из дома в целом можно прощаться
Voliker
11.03.2026 05:42ИТ-гиганты одновременно бахвалятся тем, насколько много людей могут заменить ИИ-агенты и буквально продолжают пушить алгоритмическую секцию, хотя как раз такие задачки LLM исправно и без проблем решали ещё в 2022 году
Мне кажется давным давно пора от неё отказаться. Она эффективно только тратит время.
onets
11.03.2026 05:42Господи, какое же убожество этот Яндекс. Инстаграм? Серьезно? Это первое что попалось интервьюеру в гугле?
Рассказать про сложный проект и он недостаточно сложен? Ау, 95% кандидатов работают в обычных компаниях, а вы там сидите толпой и несколько лет в несколько итераций кодите всякие архитектуры, кэши и все такое, но кандидат непременно должен вас удивить, как он в одиночку лидом осилил нечто подобное?
И все это за 360??? Еще небось до налогов? Это зарплата 5 летней давности, вы инфляцию видели?
DMGarikk
11.03.2026 05:42И все это за 360??? Еще небось до налогов? Это зарплата 5 летней давности, вы инфляцию видели?
найдите за 450 работу в РФ рядовым разрабом для начала, чтобы удивлятся
а работа на забугор из РФ с адекватными рисками это чёто сложновато
onets
11.03.2026 05:42Причем тут сложность поиска работы в конкретный период времени? Типа раньше яндекс не спрашивал лютую дичь по 7 раз и предлагал больше денег?
И кто такой рядовой разраб?
DMGarikk
11.03.2026 05:42И все это за 360??? Еще небось до налогов? Это зарплата 5 летней давности,
Я к этому пишу, вы так удивляетесь зарплате в 360, но сейчас такая ситуация на рынке что за 360 вы офигеете себе работу искать, с любым типом собеса, хоть лайтовым хоть алгоритмическим
вы инфляцию видели?
рынку труда плевать на инфляцию, он отражает реалии экономические
И кто такой рядовой разраб?
обычный миддл/сеньор без замашек на тимлидство, который код пишет, которые составляют 90% найма среднестатистической компании
DarthVictor
11.03.2026 05:42Секция "алгоритмы" (live-coding) - пропустили т.к. мне "зачли" прохождение её в 2024 году
Секция "язык" (тоже live-coding) - назначили на 6 но перенесли на 10 февраля (оказалось что у меня только час времени запланирован - а настаивали на полутора - на деле минут за 70 мы справились в ленивом темпе).
Эта залупа и раньше обладала, по моим субъективным впечатлениям, скорее отрицательной корреляцией с качеством разработки, а во времена Опуса и Кодекса от неё какой прок, хотя бы теоретически?
event1
11.03.2026 05:42Это плохо не только для кандидата - в бОльшей степени это проблема для самой конторы
Конторе надо отфильтровать 90% кандидатов. Контора может позволить отфильтровать всех немотивированных кандидатов. То что вам кажется проблемой, для самой конторы является простым и дешёвым решением
использовать всё-таки хотя бы полуавтоматическую проверку, тесты (а не вот это "сейчас я пробегусь глазами, э-э-э-э")
Смысл этого, в том, чтобы кандидат не волновался о деталях реализации а излагал свои мысли о том как решить задачу
DMGarikk
11.03.2026 05:42отфильтровать всех немотивированных кандидатов
"работать в нашей компании - честь" (с)
не волновался о деталях реализации а излагал свои мысли о том как решить задачу
вы в реальной работе тоже в течении 60 минут должны выдать концепт прод-решения когда еще на вас пара глаз смотрит, да еще язвительно тыкает в ошибки?
То что вам кажется проблемой, для самой конторы является простым и дешёвым решением
это то как раз всё понятно, но контора явно не догоняет что такой выборкой они выбирают с рынка довольно своеобразный срез программистов
event1
11.03.2026 05:42вы в реальной работе тоже в течении 60 минут должны выдать концепт прод-решения когда еще на вас пара глаз смотрит, да еще язвительно тыкает в ошибки?
ну, как бы, да. Иногда, в течение 30и и при наличии начальства и потенциальных клиентов в комнате. Правда, справедливости ради, комментарий был про тест на программирование, а не проектирование
DMGarikk
11.03.2026 05:42как бы да - это вы где работаете то?
Цикл проектирования в крупной компании включает в себя архитекторов, аналитиков, техлида или тимлида, а не выдали задачку миддлу и давай напиши что за спринт сделаешь и без ошибок и еще совещание вместе с начальством и клиентами - такое только в стартапах на полтора человека бывает
не, я про яндекс наслышан что у них там дух стартапа и не все как у людей...но чтобы прям на столько?
event1
11.03.2026 05:42Цикл проектирования в крупной компании включает в себя архитекторов, аналитиков, техлида или тимлида
У кого денег много, то может себе позволить столько важных должностей иметь. Мы сетевые железки делаем: у нас каждая копейка на счету.
не, я про яндекс наслышан
Яндекс ту не при чём.
DMGarikk
11.03.2026 05:42Мы сетевые железки делаем: у нас каждая копейка на счету.
Если так экономить, то качество будет соответствующее
Вообще железячники, в целом, софт писать не умеют, я уж не знаю почему но весь софт который пишут железячники (вот взять например софт от Intel) это какойто тихий ужас в плане...эээ всего. и у меня много примеров, софт от производителя УПСов юзал и от дизель-генераторов, и какойто Российский производитель Serial коммутаторов... это прям всё, обнять и плакать
Даже взять Циску, казалось бы, так там UX такой что его явно люди с альтернативным мышлением придумали, просто отрасль привыкла...и это теперь стандартом считается... или вот телефоны Avaya... до сих пор помню какието адовые UI и странные настройки чтобы оно работало... хотя известные фирмы всё
я так понимаю что каждая копейка на счету, и важнее железку выпустить, а не софт написать под неё?
event1
11.03.2026 05:42Если так экономить, то качество будет соответствующее
Спасибо за совет
Вообще железячники, в целом, софт писать не умеют, я уж не знаю почему
Всё так. Думаю причина в том, что "железные" кампании не очень понимают, как организовать софтварную часть бизнеса. И организовывают так же, как железную.
Даже взять Циску, казалось бы, так там UX такой что его явно люди с альтернативным мышлением придумали
Циска сделана для спецов по сетям с цисковским-же сертификатом. Они другого не знают и думаю, что это лучшее, что может быть.
я так понимаю что каждая копейка на счету, и важнее железку выпустить, а не софт написать под неё?
Важнее в тендере прийти первым, чтобы продать железок, чтобы платить зарплаты и продолжать деятельность.
RodionGork Автор
11.03.2026 05:42Цикл проектирования в крупной компании включает в себя архитекторов, аналитиков, техлида или тимлида,
это всё так, к сожалению многие из нас работают в крупных компаниях и знают не понаслышке, что такой цикл зачастую не менее ущербный :) аналитики запрашивают хрень, архитекторы выдумывают фигню, техлид устало соглашается на трёхчасовом созвоне где его решили этим обрадовать, а разработчик потом должен бегать и стучать в личку всем этим гениям и объяснять почему так сделать нельзя.
я немного утрирую конечно, но думаю такая ситуация известна почти любому :)
DMGarikk
11.03.2026 05:42я немного утрирую конечно, но думаю такая ситуация известна почти любому :)
Хорошо когда эти люди вообще есть в цепочке, а когда их ф-ции выполняет миддл разрабочик, это вообще жесть. я уже два крупных проекта переписывал практически с нуля которые так были разработаны
RodionGork Автор
11.03.2026 05:42да, тут есть разные крайности и то о чём вы говорите тоже конечно классическая проблема :) и кстати в яндексе она тоже существует - помню на одном из собеседований мне прямо так и сказали "вот мы напедалили такое решение (минут 5 восхвалений) - и в общем мы хотели бы его теперь переписать с нуля"
event1
11.03.2026 05:42У нас это один человек. Он же и старший разработчик на полставки. Таким образом все нереальные запросы отпадают до того, как фантазёры заканчивают предложение. И без трёхчасового созвона.
RodionGork Автор
11.03.2026 05:42отфильтровать хоть 99% можно
я только о том что им надо учиться делать это быстро
event1
11.03.2026 05:42Вот вы сходили на интервью, написали об этом сюда. Тысяча человек прочитали и решили, что им такое удовольствие совсем не нужно. И не прислали в яндекс своё резюме, а на приставания их кадровиков ответили решительным отказом. Получилось очень быстро и дёшево
RodionGork Автор
11.03.2026 05:42если вы внимательно прочитали статью, то могли обратить внимание что присылать резюме в яндекс не требуется. они по своей устаревшей внутренней базе пытаются обстукивать народ :)
olegshutov
11.03.2026 05:42Я работал в Яндексе. Очень много высокоинтенсивной и тупой работы и маленькие зарплаты, плюс постоянное ухудшение условий. Высокая текучка, работать некому, в общем, бррр прямо. Несколько лет такой работы убьет желание вообще программистом быть
RodionGork Автор
11.03.2026 05:42и те кто не работал в яндексе встречали в других компаниях немало выходцев из него... в общем допускаю что яндекс большой и неоднородный и где-то найдутся и задачи поинтереснее и зарплаты повыше, но ситуации 2008-2011 годов видимо не повторится, когда яндекс джуниорские зарплаты мог предлагать на которые соблазнялись бы сеньоры а в смысле задач был непочатый край идей.
MishaBucha
11.03.2026 05:42Проходил собес в Яндекс в июне, live coding был в моей иде, даже попросили настроить проект для тестов и задача считалась решенной тольк тогда, когда были написаны тесты(как сказали на интервью, тесты, которые считаю нужными), а вот алгосы были в блокноте(в их приложении для кодинга) причем я писал на котлине, а мой код смотрел ревьювер на GO, который просто смотрел, как я пишу код, сказав, что котлин в глаза не видел))))
От Яндекса остались не очень впечатления)
RodionGork Автор
11.03.2026 05:42Любопытный опыт :) а live-coding это по языку было или какая-то специальная "секция"?
MishaBucha
11.03.2026 05:42по языку, я тогда писал на котлине и выбрал его, проходил в яндекс 360, для удаленки нужен был сеньор грейд, решил попробовать
первая секция была лайф кодинг как раз, дали задачу бизнесовую - есть клиент и его корзина, у каждого клиента свой процент скидки, нужно оформить заказ, на правильную сумму и в ответе отдать userName + orderSum. И тут как в архитектурных секциях нужно задать миллион вопросов, чтобы понять, что именно хотят) все проверки на отрицательные чиста и т.д выдумываешь сам и покрываешь тестами, в своей иде, обычные юнит тесты.
На самом деле секция прикольная, особенно идея с тестами, ее я прошел успешно и получил хороший фидбэк
следующим этапов были алгоритмы, решив 2 задачки на котлине с собеседующим, который даже не видел этот язык получил ответ, что немного было неправильно и я сказал, ну и ладно)
Через месяц позвали на собес в ОТП банк и прошел туда, где работаю по сей день)
Всего 2 человеческих этапа, собес на 1:30 часа и созвон с руководителем и командой, где спрашивали, что я буду делать в экстренной ситуации и тд) Ну и предложили там больше, чем в яндексе))RodionGork Автор
11.03.2026 05:42Спасибо за подробности! да уж, что-то звучит несколько насосно задачка для их формата (полтора часа?) - т.е. по содержанию действительно неплоха, но мильон проверок и т.п. - это я бы не стал требовать на собеседовании.
Любопытно про ОТП банк - надо будет присмотреться :)MishaBucha
11.03.2026 05:42там в этом был смысл) видимо без ТЗ разработать и продумать проверки и камни
Либо там плохо с аналитикой, либо очень странная и ненужная секция
yaroslavp
11.03.2026 05:42А меня, мидла, отфутболили в яндексе на первом этапе, сказав, что вакансий с 1 днём офиса/удаленно нет. А для сеньоров видимо есть. Осуждаю дискриминант по грейдовому признаку
RodionGork Автор
11.03.2026 05:42да, это бред но некому его объяснять :)
и главное что тут дело не только в дискриминации, а в том что компания нацеливается набирать людей ставя на первое место не скилл а возможность добираться до офиса (который в Питере расположен весьма по-дурацки - это не попа мира, но она оттуда уже видна). и тут я как кандидат думаю - мне интереснее работать с реально умелыми людьми от которых можно чему-то научиться - или просто с "пацанами с района"?
Caraul
11.03.2026 05:42А в это время настоящий штатный телепат усиленно посылает мысленный сигнал "кто меня слышит - пройдите в маленькую дверь в левой стене".
За столом секретарша устало повторяла на широчайшей телепатической волне: «Если вы меня слышите, пожалуйста, пройдите в дверь налево с табличкой „Только для служащих“. Если вы меня слышите, пожалуйста, пройдите в дверь налево с табличкой „Только для служащих“…» (с) Альфред Бестер. Человек без лица
jinn50k
11.03.2026 05:42Год за годом ничего не меняется. Есть ведь железобетонное правило: не работай с мудаками. А говноделы из Яндекса это сертифицированные мудаки, прям вот с медалью и справкой и держаться от этой навозной кучи нужно как можно дальше.
Хотя нет, год за годом качество их поделий становится только хуже и хуже, по вполне объяснимым причинам, нормальные люди туда просто не идут работать.
az2012
11.03.2026 05:42Был на собеседовании пару месяцев назад в одном известном банке. Правда, должность инженерная. Тоже с собеседованиями странная фигня. Точнее с тестовым как я его для себя назвал. Нужно было провести обследование системы на предмет выявления ошибки, устранить ее и сделать предложения по улучшению системы в целом. В корне - идея интересная и реализовано общение нормально. Но есть нюанс - собеседование сделано для SRE, а я шел на внутреннюю инфраструктуру. Соответственно в полной мере понимания как предложенная система и компоненты работают у меня не было. В итоге проблему найти и решить удалось, но потребовало больше времени чем предполагалось. Но самое удивительное было в следующем:
1. для других должностей вариаций подобных заданий с их спецификой нет
2. оценка идет как полноценного SRE, без скидок на предлагаемую должность. Что было отражено в обратной связи.
Такого поворота я конечно не ожидал. Что интересно HR это понимал, предполагаемый руководитель тоже. Но сделать ничего нельзя.
monamj
11.03.2026 05:42Потрясающие кино! Когда выставлял свое резюме год назад, ещё тогда в поле "не показывать мое резюме компаниям" указал Яндекс.
Он допытывался во сколько же копий нужно сделать запись, чтобы считать её успешной. В две, или три, или больше.
Ответ автора по этому поводу оказался намного весомее, чем ожидали на собеседование. Абсолютно согласен, что это зависит от политики компании. Количество записей должно отталкиваться от SLO. Если не этот ответ, то интересно какой в их понимании будет "правильным"
Curious_Vik
11.03.2026 05:42Кажется, всё-таки стоит написать статью про собеседования по итогам моего поиска работы год назад) Есть, чем дополнить этот и предыдущие тексты.
А по поводу эпопеи автора, есть пара заметок:
Да, Яндекс очень большой и, судя по всему, не имеет единой базы резюме по всем своим направлениям. То, что Вы видите в просмотрах на ХХ - скорее всего, заходы эйчаров из разных стримов.
Более того, они настолько не связаны между собой, что нарушают даже собственные внутренние правила. Например, в первый свой заход я не прошёл собес Яндекса Облака. По правилам, кандидат не может быть рассмотрен раньше, чем через полгода или год после предыдущего провала. Однако, девочка из другого направления Я написала мне уже через 4 месяца.
Я бы не спешил радоваться по поводу зачёта алгособеса с предыдущего захода. Его результат влияет на оценку текущего процесса и, если он был не идеальный, может утянуть оффер на более низкие грейды.
И даже если Вы проходите сейчас алгоритмическую секцию, то на Вашу оценку всё равно влияет оценка с предыдущей попытки в течение 2 лет. Мне это было прямо заявлено. Что, конечно, полное безумие, но как есть.
RodionGork Автор
11.03.2026 05:42судя по всему, не имеет единой базы резюме по всем своим направлениям. То, что Вы видите в просмотрах на ХХ - скорее всего, заходы эйчаров из разных стримов.
как Вы сами понимаете, то что такая крутая айтишная контора не имеет общей базы (или имеет какие-то с ней проблемы) - это очень негативные мысли по поводу такой конторы навевает, в этом смысл :)
по поводу зачёта за алгоритмы я вовсе и не радовался - я по большому счёту ради них и ввязался в эту тему, мне нравится эта секция - и я даже немного обиделся что её не дали :D
А статью напишите конечно, по возможности - как видите, творится всевозможный бардак и коллегам-единомышленникам отнюдь не вредно будет больше подробностей получить.
dobrobobrrobot
Работаю в сфере, не связанной напрямую с IT, и такой процесс найма для меня - это просто какая-то фантастическая дичь
1,5 месяца мурыжить кандидата собеседованиями и тестами - вы там выбираете одного идеального человека из всего населения Земли для отправки на Дзета Сетки для встречи с инопланетным разумом?
В целом думается Яндекс просто слишком разросся. Описанное выше - признак деградировавших процессов во всех разросшихся системах, в которых цепочки управления становятся слишком длинными и перегруженными, и очень много нарастает бесполезных сотрудников и даже отделов в целом, которым нужно показывать свою полезность
blik13
В больших системах может быть вопрос длительного периода погружения в проект. И зачастую проще потратить лишнее время на подбор сотрудника, чем через месяц испыта окажется что кандидат максимально печальный, а потом снова идти искать кандидата и снова ждать пока он поймет что к чему в конкретной системе.
dobrobobrrobot
только вот в процессе 1,5 месячного найма потенциальный сотрудник не погружается в реальный проект, цитата:
Если взглянуть шире - то мы понимаем что в течение 3-4 секций кандидат проходит "расширенный скриннинг" с участием специалистов из произвольных отделов.
а самое смешное, что уже работающие на реальным проектом сотрудники не могут повлиять на то, кого же к ним пришлют:
Руководитель проекта, в который требуется разработчик, имеет очень ограниченные возможности как-то повлиять на "общий фильтр", как-то акцентировать потребности связанные с его проектом.
Итого после успешного найма иногда получается такое: https://habr.com/ru/articles/438514/ - найм кстати шел 2 месяца
RodionGork Автор
дак ведь в статье про "обновление" автор (якобы глава-рекрутинга) сам пишет как это плохо и как нужно от этого безобразия уходить... :)
mikronavt
Получается, в течение месяца испыталки можно определить, подходит ли кандидат для проекта, быстрее и точнее, чем за 1.5-2 месяца собеседований
dph
Если в проекте длительное время погружения, то это проблемы организации проекта.
Пользу от нового сотрудника на уровне миддл и выше можно начать получать практически сразу (неделя-две максимум).
Ну и текущие методы проверки - все равно не дают какой-то вменяемой информации о кандидате, так что через месяц тоже легко выяснится, что кандидат не соответствует.
norguhtar
Ну нужно же чем-то оправдывать HR штат и интервьюверов. А так все при деле, работа делается интервью ведутся, производительность растет. То что при этом соотношение нанятых человек/количеству интервью подозрительно мало, можно объяснять хорошей работой HR по подбору персонала.
RodionGork Автор
Эта проблема не специфична для яндекса и не связана напрямую с разрастанием - когда я работал в одной гораздо меньшей (скандинавская Gelato всего около ~300 айтишников) конторе, там процесс был похожий устроен и как со смехом часто говорили - скорее всего сами интервьюеры друг у друга интервью с вероятностью 50% не прошли бы.
Но что касается Яндекса - я упоминал что собеседовался в него в разные времена :) и я бы отметил что на него сильно повлиял 2014 год - как "экономический провал" в связи с известными событиями, так и смерть Ильи Сегаловича, по-видимому.
dobrobobrrobot
300 айтишников уже довольно много
По моим наблюдениям "поломка" отношений в компании происходит, если между директором-принимающим-важные-решения и самым-рядовым-сотрудником встает больше чем один человек
То есть:
Сотрудник отдела
Начальник отдела
Директор
такая структура тянет от десятков до одной сотни человек, потом уже появляются новые слои и все сыпется
RodionGork Автор
Ну, в этом наблюдении конечно есть смысл :)
По воспоминаниям лучше всего получались собеседования (и дальнейшее сотрудничество) в случаях когда на единственном интервью присутствовал руководитель отдела (или всея компании). Конечно фильтровать по 200 человек в день так не получится... ну для этого и нужно заниматься изобретательством по поиску и завлечению подходящих кандидатов (вместо того чтобы форвардить с уровня HR пачки резюме)...
Stanislavvv
По моим наблюдениям, ломаться начинает при увеличении количества сотрудников примерно в районе числа Данбара, причём, похоже, независимо от направления деятельности компании.
ruvasik
На Яндекс повлиял приход Парахина (да, на место Сегаловича).
Да, потом от чего-от отказались, но, в целом, рельсы были поставлены, и он так и несется по ним
event1
В обычном бизнесе, если человек пришёл в контору устраиваться и демонстрирует формальное соответствие требованиям и не проявляет очевидной неадекватности, его берут. Потому что, человек не придёт устраиваться, чтобы не пройти испытательный.
В маманы (Meta Amazon Microsoft Alphabet Netfliх) же люди шлют резюме тысячами в день их нужно отфильтровать. И первый фильтр состоит в том, чтобы отфильтровать людей, которые не очень хотят работать в маманах. Потому что, даже таких мотивированных кандидатов больше, чем надо.
vvbob
Нет, ищут крудошлепа способного без выгораний таскать джейсоны через слои абстракций в кривом легаси, с осадочными породами из айтишного мегалита, присутствовать на стопятьсот бессмысленных обзвонах, сохраняя при этом вид счастливого идиота любящего свою работу и коллег.
rinaf2021
Как вы красиво ругаетесь)
vvbob
Спасибо, это наболело просто уже :)
Prjct-Mngr
Для вас это кажется фантастической дичью лишь потому, что вы работаете в сфере, не связанной напрямую с IT. Массовый потребитель цифровых решений не задумывается о том, как устроена та или иная программа. Для потребителя это лишь инструмент, при помощи которого он ежедневно совершает привычные ему действия - и это кажется ему само собой разумеющимся («нажал и получил»).
В создании удобного и привычного инструмента частично и кроется магия многих успешных IT компаний: создание такого интуитивно понятного цифрового продукта, который не будет вызывать никаких вопросов со стороны массового потребителя и станет его повседневным помощником.
Добавьте к этому критичность и масштабность используемых цифровых продуктов, где даже небольшая поломка может парализовать привычный уклад жизни и работы сотен тысяч, а иногда и миллионов людей. Такая ошибка способна создать трудности не только в повседневной жизни потребителей, но и для самой компании-разработчика. Ведь качество предоставляемого цифрового сервиса напрямую влияет на успех и репутацию компании-разработчика.
Разработка любого IT-решения - это сложный и нетривиальный процесс. Существует множество сайтов, где программисты соревнуются в мастерстве написания кода при решении тех или иных задач, и вариантов решений может быть великое множество. Один специалист способен решить задачу, написав 100 строк кода, а другой найдет изящное решение при помощи 10 строчек кода.
Именно поэтому полтора месяца проверок со стороны работодателя, особенно крупной IT компании - это абсолютно оправданный процесс.
RodionGork Автор
Где удобный и привычный, а где Яндекс?
Спасибо конечно за такое пространное восхваление очевидно сломанного процесса - но заметьте, в начале есть отсылка на статью автор которой позиционирует себя как "Chief of Engineering Staff" в этом самом Яндексе - и он сам же пишет о том как все было (и осталось) плохо.
Prjct-Mngr
Вы не пользуетесь Яндекс Такси? Еда? Карты? Поиск? Алиса? Музыка? Переводчик? Авто.ру? И тд и тп.
Что такого плохого в перечисленных выше сервисах, которыми пользуются десятки миллионов людей ежедневно?) Только аргументированно пожалуйста.
1.5 месяца собесов с учётом подбора удобных дат и времени собесов для обеих сторон, где между несколькими собесами ~10 дней промежуток, т.к. самому же автору было неудобно. В чем тут поломка?
Эффективность и качество собесов? Возможно автор прав и действительно есть что можно улучшить.
Я могу ошибаться, но по-моему люди склонны хейтить тех работодателей, которые им отказали. Стал бы автор писать этот пост, если бы Яндекс принял его на искомую позицию с хорошими условиями работы?)
DMGarikk
ими пользуются потому что аналогов нет, а популярными они стали не потому что качественные, а потому что маркетологи и продажники яндекса удачно их продвинули
Список багов каждого из сервиса можно отдельным постом оформлять на хабре (и получить минусов потому что хабр не жалобная книга)
Я вот погодой перестал пользоваться, потому что это капец во что превратилось, карты с каждой итерации все больше и больше бесят и по UX и по внезапным глюкам на пустом месте типа "бац пробки пропали на половине карты" (я это уже лет 15 наблюдаю кстати) или в андройдавто история поиска не подтягивается (а реклама зато подтягивается)
Музыка - всегда был спорным сервисам, он не стал заменой ушедшим сервисам по качеству
вот к Алисе не могу придраться просто потому что ее конкуренты прям совсем дно днищенское
RodionGork Автор
именно что пользуюсь - Такси и Картами больше всего
и моё замечание вызвано именно их катастрофическим качеством
ВК тоже отличились - год или около того назад ленту новостей так переделали что до сих пор ни старый функционал восстановить не смогли ни привнесённые баги пофиксить
RodionGork Автор
да, боюсь вы из-за каких-то собственных особенностей восприятия ошибаетесь
у меня нет какой-то ненависти к Яндексу, даже в чём-то наоборот. я же писал что мне случалось с ними и до оффера доходить, но в целом с годами он становится всё плачевнее, растерял множество тех фишек которые делали его уникальным (вы помните что теперь даже домен yandex.ru исчез). тут нет "хейта" это скорее некая грусть и ощущение что ребята уже никогда не смогут сделать его Great Again.
Статью я написал по двум простым соображениям - одно из которых - что Яндекс спрашивает обратную связь после собеседований. Там дурацкий опросник который, как я подозреваю, они и не читают. Поэтому я написал статью и отправил им ссылку. Впрочем тоже не думаю что будут читать.
Мне бы очень хотелось чтобы они взялись за ум и воплотили что-то из того о чём "мечтал" их руководитель в вышеупомянутой статье об улучшении найма. Но боюсь что сейчас уже не та коньюнктура.
alamer
Из всего названного вами списка пользуюсь только такси и то потому что они выдавили всех конкурентов.
Автору - вообще судя по всему тема для западной части России, в Сибири и на ДВ это дром.
Карты - опять же исторически у нас ДубльГИС и информация в нем точней и удобней
Поиск - мне вообще сложно представить кто им будет пользоваться, UI\UX и релевантность в моих поисковых запросах сильно хуже.
Еда - не заказываю
Алиса - так и не понял в чем смысл данного устройства.
Музыка - очень скудный список исполнителей и треков, система рекомендаций ломается буквально как только лайки перевалили за 500 штук. За несколько лет ничего нового, нативного приложения под линукс нет (появился недавно деб пакет)
Переводчик - никогда не возникало желание использовать.
Использовал по работе яндекс коннект, сорскрафт, кликхаус. Из всего этого рабочим только клик был.
Возможно ydb хорош
vvbob
Звучит красиво.. но реальность..
Вот помню до недавнего времени, практически каждый собес включал в себя массу вопросов по устройству гербеджколлектора. Как там все работает, поколения объектов, виды очисток и т.п. и т.д. Тема в принципе интересная, чисто полюбопытствовать на досуге, покопаться, разобраться.. Вот только сколько видел реальных проектов, нигде все эти глубокие знания потрохов коллектора никак не использовались. Везде все настроено из коробки (да тупо потому что там настройки подходящие для 99% случаев) и подавляющее большинство разработчиков ничего там не трогают.
И так куда не кинь, по массе вопросов, задаваемых на собесах. Крайне редко там спрашивают что-то такое, что требуется в реальной работе.
Отсюда и получается, то умение проходить собесы, мало коррелирует с профессионализмом. Можно научится брать практически любой оффер, но при этом быть так, на уровне джуна++.
Prjct-Mngr
Задача работодателя проверить широту/глубину мышления кандидата. Все компании делают это по-разному. Яндекс, как описал автор, по-своему, с алгоритмией, live кодингом, архитектурой и прочим. Я думаю как раз на таких разнообразных этапах и выявляются нужные качества кандидата, и работодателю это видно.
vvbob
Чаще всего они проверяют память и стрессоустойчивость, т.е. то, что на практике в более-менее нормально поставленном рабочем процессе не нужно практически никогда. Все эти заклепки из ЯП или фреймворков, которые приходится зазубривать перед собесами - все это легко и быстро доступно в сети по одному запросу, да хоть в исходниках глянуть - пять минут. Но нет, от тебя требуют заучивания всей этой хрени и умения воспроизвести зазубренное на перекрестном допросе. Зачем, кому это надо.. думаю они и сами на этот вопрос не ответят, просто тупо "так исторически сложилось".
aywan
Вы говорите что спрашивают не по работе, а я добавлю что они вообще не понимают для чего они собеседую и какую проблему будет решать новый человек.
Я на собесе когда-то спрашивал про GC, и тут либо человек говорит своими словами и пытается объяснить - это хорошо. Либо выдает заученный ответ - ладно сойдёт. На второе можно придумать вопрос на котором кандидат либо сломается, либо покажет что он не только заучил, но и понял.
Но вы абсолютно правы - практической пользы в этом около нуля. Разве что посмотреть как человек выражает свой мысли или рассуждает в нестандартной ситуации.
RodionGork Автор
Насчет GC это отдельная тема... Мне кажется так глубоко как в Java (JVM) его нигде не спрашивали - и это потому что там у него несколько механизмов было доступно да ещё и у каждого свои настройки. Собеседуясь однажды в "Одноклассники" я примерно после получаса вопросов по GC на которые я более-менее шатко-валко отвечал, я сказал что "ваще у меня сложилось стойкое ощущение что если в проекте приходится сложно и мучительно тюнинговать GC, то обычно это отражает проблемы дизайна самого проекта, и решения с тюнингом в общем-то корневой проблемы не решают а только позволяют немножко улучшить плохую ситуацию"
На это собеседующие помрачнели и сказали в духе "плохо что вы к этому так относитесь, нам де приходится этим заниматься практически на постоянной основе". Мне туда работу в этот раз не предложили но честно сказать я почему-то не расстроился :)))
То ли дело в Go - по-моему у нас ровно одна настройка для GC до сих пор присутствует, определяющая частоту срабатывания (и "глубину очистки") - и всё.
vvbob
Мне это напомнило как меня на одном собесе очень долго мурыжили на тему того, как в Яве кэшируются строки. На вопросы я ответил, хоть и был удивлен таким пристальным вниманием к не слишком-то важной теме. Во всем остальном на тот момент вакансия была хорошая, с хорошей з/п и прочее понравилось, поэтому офер я принял.
В процессе работы я понял причину такого перекоса на собесе. У них там был кластер из серверов, один их которых был отдан под сервисы с интеграциями всякими, на нем было установлено какое-то чудовищное по тем временам количество оперативки, что меня удивило, потому что интеграции хоть и нагружают железо, но все-же это все равно выглядело избыточным. Оказалось что тот сервак постоянно падал по ООМ, и вся его память в дампе была забита однообразными строками явно из БД. И похоже они думали над тем как заставить Яву закешировать все это и не жрать память, что явно было каким-то странным решением проблемы.
Покопался в этих дампах, нашел источник проблемы, оказалось что один из разрабов, при написании обмена данными с внешней системой, за каким-то лешим не использовал стандартные спринговые шедулеры, а запускал поток при старте сервера, и в бесконечном цикле обменивался данными. Но он не учел то, что при таком использовании нужно принудительно очищать кеши Хибера после завершения итерации обмена данными, иначе кеш не чистится, гербедколлектор объекты не уничтожает, т.к. они в кеше и память выжирается постепенно.
Но в этой истории, хотя-бы мурыжили по своей основной боли, это хоть немного понятно (хоть и странно). И коллектор тут хоть как-то можно пристегнуть к теме, хоть он тут и не при делах был совсем, замена или тонкая его настройка в лучшем случае только отсрочило падение по ООМ.
RodionGork Автор
Хе-хе, это "агонь" конечно :)
Но еще интересное наблюдение насчет "Покопался в этих дампах, нашел источник проблемы" - на удивление знакомо - когда приходишь на новое место, в проект "семантически" врастать ещё пока сложно - зато видишь какие-то очевидные косяки, которые месяцами никто не исправляет в силу какой-то ментальной инертности. Аналогично на текущем месте я одним из ранних достижений "базу починил" :)))
DMGarikk
Это типичный эффект свежего взгляда
RodionGork Автор
необязательно :)
например вижу что на проекте куча тестов нестабильные. мерж-реквесты в репозиторий приходится по нескольку раз перезапускать. все чертыхаются, но править никто не торопится. это мол ведь тесты нестабильные, с приложением всё норм.
заглядываю осторожно внутрь, минут через двадцать обнаруживаю, например, что обёртка библиотеки логгера через раз при инициализации nil-pointer ловит. это не в тестах проблема. и проблему все видят даже самым несвежим взглядом. просто считается что "есть дела поважнее".
vvbob
Там просто команда была изначально по типу "пожарных", система была на стороне написана, они просто занимались поддержкой и допилингом, ну, и проф уровень был поначалу так себе, ребята больше эникеили, чем программили, оттого и велосипеды странные и отсутствие кодревью, из-за чего эти решения в прод пролезли :)
alamer
Так мы еще раз пришли к выводу что хибернейт создает больше проблем, чем решает и вообще не нужен
DMGarikk
чистым sql предлагаете запросы писать?
alamer
jooq
RodionGork Автор
вообще да, есть такая тенденция - даже шутки на эту тему уже были, мол джуниор использует sql, миддл JPA, сеньор опять sql
но вообще в джаве есть и другие интересные подходы (например spring-data) насколько я помню
DMGarikk
Использование чистого sql накладывает определенные ограничения и вызывает сложности в поддержке такого продукта, далеко не везде его можно использовать бездумно
С шуткой согласен, я сам прошел через это, но я склоняюсь к гибридному подходу, простые запросы orm, сложные sql
vvbob
Неверный вывод, это инструмент, которым тоже надо уметь пользоваться. Проблемы возникли из-за того, что им пользовались неправильно. На чистом JDBC можно точно так-же налажать, если пользоваться им неправильно.
alamer
Неверный вывод, этот инструмент не решает задачи, а только добавляет дополнительный слой абстракции, с которым нужно бороться. Начинать в 2026 проект с хибернейтом это как минимум глупо
vvbob
Это был 19-й, а когда написано было я вообще не помню.
Я позже переписал тот-же модуль на шедулере спринга и все работало хорошо, без ООМ, просто не надо велосипеды изобретать без необходимости, а если уж их изобретаешь, то нужно понимать что делаешь и как этот велосипед будет работать.
ruvasik
Все так и есть.
Я уже писал про похожую с автором ситуацию - меня помурыжили, выдали вердикт из набора противоположных тезисов типа "скиловый, но похоже не пишет код, максимум джун, но даже джуном не возьмем - оверквалифайд"