«Яндекс» открыл разработчикам доступ к своим тестам для проверки технических навыков Статьи редакции
Они смогут пройти те же этапы, что и на реальных собеседованиях в компании, и проверить свой технический уровень.
- Диагностика бесплатно доступна бэкенд- и мобильным разработчикам, разработчикам интерфейсов и аналитикам, объявила компания.
- Для этого нужно подать заявку и пройти отборочный тест на платформе «Яндекс.Контест», в котором будет около пяти задач. В случае его прохождения компания назначит онлайн-встречу со своими практикующими разработчиками.
- На встрече также нужно будет решить реальные задачи с технических собеседований. Если результаты будут выше среднего, «Яндекс» предложит ещё одну встречу с задачами.
За это начисляются баллы и формируется финальная оценка: четырёхбалльная шкала с кратким описанием уровня. Результаты будут доступны по персональной ссылке, ими можно поделиться в соцсетях или с работодателем.
- Если в течение полугода после получения результатов специалист захочет откликнуться на подходящую вакансию в «Яндексе», ему их зачтут — останется финальное собеседование и знакомство с командами.
- Повторно пройти диагностику можно через месяц, третий раз — через три месяца, четвёртный — через полгода.
- Также «Яндекс» предложил другим ИТ-компаниям создать универсальный метод оценки технических навыков при трудоустройстве. Обычно прохождение технических секций — самая долгая часть в процессе найма в ИТ, отметили в компании.
13
показов
31K
открытий
4
репоста
Если бы ещё критерии оценки Яндексом технических навыков имели бы какое-то близкое отношение к реальности - было бы менее смешно.
Собеседование в Яндексе +/- похоже и по уровню задач и по структуре на FAANG. Для людей, которые планируют устроиться в FAANG отличный вариант на родном языке пройти +1 собеседование. Стоит рассматривать вариант как подготовка к IELTS или чему-то подобному.
По структуре - да, похоже. Другое дело, что структура эта не уникальна и понимание оной примерно бессмысленно.
По поводу уровня задач (и, что важнее, критериев их оценки) - тут уже более сомнительно. Я бы не взялся так утверждать, хотя, возможно, у вас есть какой-то сравнительный анализ?
Другое дело, что не совсем понятно как "люди которые хотят в FAANG" соотносится с "универсальный метод оценки технических навыков при трудоустройстве".
FAANG - довольно специфичное и сомнительное удовольствие, со своими критериями отбора и приоритетами.
Проецировать их подход к найму на всю отрасль - довольно глупое занятие.
Сравнивать с IELTS тоже так себе затея, потому что IELTS хотя бы примерно отображает уровень владения языком (хотя и в своей парадигме), а факт прохождения собеседования в FAANG или Яндекс примерно ничего не говорит о профпригодности для работы в любой компании за пределами FAANG и Яндекса.
(да и даже в их пределах не то, что бы говорит)
У меня есть знакомые/друзья, которые проводили собеседования в Яндексе и сейчас проводят собеседования в Гугле/Фб.
FAANG - довольно специфичное и сомнительное удовольствие, со своими критериями отбора и приоритетами.Самый простой вариант для релокации. И самый комфортный. Переезд через стартапы это часто лютые геморой.
Проецировать их подход к найму на всю отрасль - довольно глупое занятие.На всю отрасль - нет. Но зачем идти в мелкие компании? Ну разве что для того, чтобы быстро набрать базовое понимание как работать.
Сравнивать с IELTS тоже так себе затея, потому что IELTS хотя бы примерно отображает уровень владения языком (хотя и в своей парадигме), а факт прохождения собеседования в FAANG или Яндекс примерно ничего не говорит о профпригодности для работы в любой компании за пределами FAANG и Яндекса.(да и даже в их пределах не то, что бы говорит)
Нет. Это отличные показатель того, что человек готов приложить усилия для того, чтобы подтянуть свой уровень до предполагаемого. Человек, который забивает на подготовку может быть и подойдет, но я бы не стал с таким работать, ибо вряд ли в работе он будет проявлять интерес к поиску новой информации. Если что я работал и в мелких компания, помогал запускать стартапы, работаю в компании уровня FAANG.
У меня тоже. А ещё есть знакомые/друзья, которые проводили собеседования в Яндексе, но не прошли их в FAANG.
Самый простой вариант для релокации. И самый комфортный. Переезд через стартапы это часто лютые геморой.И наоборот тоже.
Но к чему эти анекдотические доказательства.
Если под "релокацией" подразумевать только US, то возможно.
На всю отрасль - нет. Но зачем идти в мелкие компании? Ну разве что для того, чтобы быстро набрать базовое понимание как работать.Во всех остальных случаях можно получить визу быстрее, чем пройти цепочку собеседований в FAANG.
С таким же успехом могу спросить "зачем идти в FAANG?".
Нет. Это отличные показатель того, что человек готов приложить усилия для того, чтобы подтянуть свой уровень до предполагаемого.Это, очевидно, вкусовщина.
И, как бы, "на всю отрасль - нет" и есть то противоречие декларируемому "мы сделаем стандарт оценки тех скиллов для отрасли" из статьи.
90% отрасли критерии отбора в Яндекс и ФААНГ нахер не уперлись.
Ещё раз. Желание человека попасть в FAANG и то, что он задрочился на типовых FAANG задачах для собеседований не говорит ничего о профпригодности человека за пределами FAANG.
Здорово, потратил время, молодец. Научился - тоже молодец.
Это не значит, что он пригоден для работы в компании, у которой критерии отбора отличаются от FAANG.
А отличаются они примерно везде, кроме этого фаанг.
> Если что я работал и в мелких компания, помогал запускать стартапы, работаю в компании уровня FAANG.
Рад за вас. Тоже много где работал, и куда куда, а в подобие FAANG я ещё раз точно наступать не стал бы. :)
И наоборот тоже.
Здесь есть еще человеческий фактор. Вчера в чатике обсуждали как раз, что человек просто забыл как решать задачу. Такое бывает. У меня раз было что я запутался в указателях у линкедлиста при инплейс реверсе. Это одна из самых простых задач.
Но к чему эти анекдотические доказательства.А какие другие можно привести? В чем можно измерить сложность задач?
Если под "релокацией" подразумевать только US, то возможно.Во всех остальных случаях можно получить визу быстрее, чем пройти цепочку собеседований в FAANG.
Переезд это не только виза. Это еще и перевозка вещей, аренда жилья, всякие документы на месте. Не все могут взять рюкзак, визу и переехать в Airbnb.
90% отрасли критерии отбора в Яндекс и ФААНГ нахер не уперлись.Лучше бы они были. Я и участвовал и создавал стартапы. Да, конечно на старте нужно бежать быстрее, но когда делаешь это с людьми из FAANG у тебя уже есть контракт на то как делать правильно и однотипно. Там где участвовал со стороны, там было весело. Был человек, который писал код по-другому код стайлу и ни в какую не хотел использовать общий. В итоге пулл реквесты ломались из-за код стайла. FAANG хорош тем, что как бы ты не сопротивлялся, но в конечном счете будешь делать как это заведено, а не как ты хочешь.
А отличаются они примерно везде, кроме этого фаанг.Чем отличаются-то?
как делать правильно
Простите, это очень смешно. :)
но в конечном счете будешь делать как это заведено, а не как ты хочешьЯ бы исправил это на "в конечном счете ты будешь делать так, как это заведено, а не так как стоило бы".
Чем отличаются-то?Да много чем:
Степенью самостоятельности и зоны ответственности.
Количеством изобретенных до тебя велосипедов, которые "зато своё", и необходимостью их использовать.
(а заодно количеством задач на изобретение своих велосипедов)
Скоростью принятия решений и изменений, как результат - требований к коду и продукту.
Инженерной и "корпоративной" культурой.
Бюджетами и возможностями.
Разные размеры компании, продукты и условия требуют, неожиданно, разных подходов к решению задач.
Я каждый раз смеюсь, когда люди не имеющие опыта работы над большими проектами рассказывают что процессы в компании построены неправильно. Что типа все большое и неповоротливое, а вот мы сейчас найдем свой особый путь. В итоге этот свой особый путь через 5 лет превращается в тоже самое что и в больших компаниях. Не зря сотрудники гугла выпустили несколько книг с описанием процессов. "Стоило бы" обычно заканчивается хождением по граблям по которым большие компании уже прошлись.
Степенью самостоятельности и зоны ответственности.В FAANG степень самостоятельности и зон отвественности чем-то отличается? Ну разве что она обычно пронумерована и люди сформировали критерии в виде грейдов и ожиданий в зависимости от грейда.
Количеством изобретенных до тебя велосипедов, которые "зато своё", и необходимостью их использовать.(а заодно количеством задач на изобретение своих велосипедов)
Это самое смешное, что люди в мелких компаниях всегда рассказывают. Вот любого спроси и он расскажет про велосипеды. Только вот проблема в том, что мелкие компании берут готовые опенсорс решения, которые по большей части либо открытый код большой компании в урезанном виде, либо вольная интерпретация. Я помню когда появился Mesos, который умел только в пессимистик офферс, а оптимистик не умел. И так в целом со всем. Хадуп вроде до сих пор не научился ipv6. k8s так и не научился держать больше 5к нод. А у нас это все было 10 лет назад и на таких масштабах, до которых не все дорастут. Большие компании придумывают то, что потом мелкие будут использовать. Называть это велосипедами непонимание как устроены процессы.
Скоростью принятия решений и изменений, как результат - требований к коду и продукту.Это очень сильно зависит от отдела. Опять же непонимание как работают большие компании. У меня был опыт работы и в таком внутреннем стартапе, где все делалось на коленке и нужно было все сделать вчера и опыт в соседнем отделе, где планирование шло на 5 лет вперед.
Разные размеры компании, продукты и условия требуют, неожиданно, разных подходов к решению задач.Подход всегда будет один, но у компании может не быть ресурсов на его выполнение. Вот и все. А сказки про разные подходы это экономия этих самых ресурсов.
Минус велосипедов в том,что за пределами компании эти навыки не ценятся или ценятся очень ограниченно.
Здесь все просто. У меня приблизительно такой опыт: я писал что-то подобное envoy/nginx и конечно же знал следил за развитием обоих продуктов. У нас была система оркестрации контейнеров созданная до докер свармов и прочих кубернетисов. Я пошел, почитал по ней дизайн доки, посмотрел в ядре как работают неймспейсы и сигруппы итд. Потом почитал дизайн доки наших распределенных числодробилок. Оттуда всяких паксосы с рафтами нашел.
Мне было лень обновлять линкедин, да и это приносит свои лулзы. В общем было у меня несколько собеседований в компании где пользуются опенсорсными решениями. План действий был такой: как только говорят про опенсорсное решение, то сразу говорить, что опыта работы с ней нет, но могу рассказать как оно работает внутри. Это был очень интересный опыт. С парой человек было интересно пообщаться, они знали внутренности этих опенсорс проектов, знали их ограничения и в целом их не интересовало знаю ли я формат конфигов или набор команд для управления. Мы не сошлись по деньгам, но потом с одним человеком пересекались и я ему немного помог с кодом. Были и компании где хотели именно формат конфигов с набором команд. Было конечно очень скучно слушать человека, который пытался потешить свое ЧСВ. Эти собеседования очень легко скипаются просто предложением не тратить время зря.
Недавно столкнулся как раз с тем, что нужно было разобраться в слое совместимости с k8s и поверх всего этого посмотреть что запускают клиенты. Это были решения, которые мы реализовывали 10 лет назад, но у нас были практически бесконечные ресурсы. У нас даже граф исполнения при визуализации был сильно лучше вылизан, чем в опенсорсе. Всякие манифесты, нормальные DSL и прочее. А сейчас приходишь и видишь yaml или json конфиг и людей, которые на нем фактически код пишут. Не знаю где человечество свернуло не туда и зачем-то вместо Lua/Kotlin/etc DSL выбрало yaml DSL, но сочувствую людям нравится страдать.
Конечно, опыт же только у вас есть. :)
Большие компании придумывают то, что потом мелкие будут использоватьАга, поэтому в Аркадии (которая сама, в общем-то, является прекрасной иллюстрацией, но ладно), например, есть своя имплементация .tolower().
Подход всегда будет одинС багами, правда, зато своя.
А, ну да, точно. Есть же один "правильный" способ делать программные продукты, которые знают в FAANG.
Тогда ладно, капитулирую.
Опытный человек понимает, что велосипеды в большинстве случаев не велосипеды. Это либо решение, которое было реализовано до того, как стало доступным другим компаниям, либо решение, которое создано под конкретные задачи. Ну про первый вариант я уже писал, а про второй у меня тоже есть опыт написания кода. Мы писали свою систему доставки пакетов во времена puppet/chef/cfengine потому, что на наших объемах нужно было гарантировано устанавливать пакеты на десятках тысяч серверов. Пришлось написать свой аналог bittorrent для того, чтобы машины шарили пакеты между собой, а не носили их из соседнего ДЦ. В целом это велосипед, но ни один продукт не мог решить наши задачи.
Ага, поэтому в Аркадии (которая сама, в общем-то, является прекрасной иллюстрацией, но ладно), например, есть своя имплементация .tolower().С багами, правда, зато своя.
Давайте начнем с того, что Аркадия появилась приблизительно 15 лет назад, когда в C++ не было строк. Сейчас TString(TStroka) использует std::string. В чем баг может расскажите?