Полгода назад была статья как Яндекс обновляет процесс найма разработчиков - а недавно, в феврале 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 недели, а о том чтобы вообще изменить идеологию. Подход при котором кандидаты сами приходят и находят путь в компанию, в проекты - он гораздо более плодотворный. К сожалению он требует некоторых усилий со стороны квалицицированного технического персонала, говоря общо - изобретение всевозможных челленджей, квестов, контестов, оффлайновых задач, опенсорсных проектов - через которые можно получать себе работников.
Гораздо легче, кажется, увеличивать поголовье менее квалифицированного персонала - рекрутёров а то и "сорсеров" которые могут фрилансить на полставки в свободное от учёбы время. Брать не количеством а качеством.
В какой-то старой книжке был фрагмент когда компания объявляет набор телепатов. Конечно откликается множество людей заявляющих о своих паранормальных способностях. Их всех держат в приёмной, анкетируют, и некоторое время провялив отправляют домой с просьбой приходить ещё через столько-то дней. А в это время настоящий штатный телепат усиленно посылает мысленный сигнал "кто меня слышит - пройдите в маленькую дверь в левой стене".
Подходы в этом ключе позволяют не только уменьшить количество однообразных и мутных "скринингов", но и выявить действительно мотивированных кандидатов.
К сожалению здесь недостаточно места чтобы развить эту мысль, да и выходит она за пределы повествования об опыте прохождения этих двух цепочек собеседований в Яндекс и ВК.
