Как стать автором
Обновить

Яндекс открыл запись на диагностику технических навыков для всех сторонних разработчиков, кто хочет проверить себя

Время на прочтение2 мин
Количество просмотров16K
Всего голосов 11: ↑11 и ↓0+11
Комментарии27

Комментарии 27

3В настоящий момент проверка навыков и способностей доступна для разработчиков бэкенда, интерфейсов, мобильных разработчиков и аналитиков.

Под собеседованием аналитиков имеются в виду ML-разработчики как у яндекса на странице с вакансиями?
т.е. сюда относится вся ватага людей типа data scientist, ml-engineer, ml - разработчик и т.д.?

Нет, аналитики в Яндексе грубо разделяются на 4 направления:

data-engineer

data-scientist

Продуктовые аналитик

Бизнес аналитики

(Ведущие аналитики множество над предыдущими, - они же тимлиды соответствующих команд)

Подробнее можно узнать на

https://events.yandex.ru/events/data-driven-2022

Попробовал порешать, первое решение упёрлось в лимит по памяти второе по времени.

И даже данные входные у теста не описали, ну либо я слепой :) не говоря уже о том каким образом замеряли память и время.

Известно что микробенчмарки вещь неблагодарная, но захотелось хотя-бы примерно понять насколько всё плохо.

По-быстрому набросал замер времени с использованием System.nanoTime()

И памяти с Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory() при самом "худшем" случае(даты с 2000 по 3999 и разбивка по неделям) в первом решении память была ~90М во втором ~66М байт.

По времени оба алгоритма примерно одинаково, в районе 800 мс, первый чуть побыстрей.

А по результатам с яндекс-контест память в первом случае 258.96Mb, во втором 263.53Mb - вообще никакого снижения, что выглядит странно.

В время в первом 1.228s во втором 2.078s - разброс явно не пропорционален тому что замерял у себя.

Процессор у меня старенький Intel(R) Core(TM) i3-4330 3.50GHz и не должен сильно уступать Xeon(R) CPU E5-2660 2.20GHz, что у них в настройках указан.

во многих подобных системах память считается включая «инфраструктурную обвязку» и на её фоне может быть не так заметно разницу собственно в решении (особенно если это не специальный тесткейс с проверкой на расход памяти)

Лучше собеседование проводить именно неуниверсальное, а под конкретную компанию, команду и проект. А то есть риски получить универсального солдата, который будет также решать задачи, а не оптимальным образом их решать. И не каждый специалист с опытом тем более немаленьким станет тратить столько времени на прохождение собеседований тем более когда можно за 1-2 встречи получить очень хороший оффер-даже лучше, чем от Яндекса и не только по уровню ЗП (это из реальной жизни) причем в РФ.

очень хочется узнать, в какой компании можно за одну встречу получить такой оффер — я бы попробовал у них поучиться как проводить собеседования...

Легко. Собеседование в виде диалога: что делали и как с уточнениями и корреляцией что нужно Вам в текущей вакансии, т е кого ищете. Это самое быстрое и эффективное собеседование. И таки да, проверено временем.

это в какой компании так? хочется понимать для контекста...

и как устроена защита от обмана?

Как минимум в 3-х и таки да ИТ.

Какая защита? Вы не можете задать уточняющих вопросов, чтобы понять кто перед Вами?)

Называть компании все не буду, т к я не представитель данных компаний и не уверен, что имею право именно так их пиарить. Но иногда применяется в ОзонТехе (не для всех и не всеми конечно) . Но помимо тех 3-х компаний также такая форма попадалась в одном крупном банке и в нескольких небольших компаний, которые вроде как ИТ, но на самом деле дочки более крупной не ИТ компании. Однако, Вы можете походить по собесам и сами натолкнуться на такую форму. Она да, нечасто встречается. Обычно скрининг+тех интервью, а затем финальная встреча. Т е обычно всегда 1 встреча как тестирование с вопросами и одна как финал, но прошу заметить не 4 тех интервью). Такая форма например в ОзонТехе.

А чтобы просто как диалог с финалом сразу или сначала диалог, а потом финал встречается редко и бывает что в одной и той же компании используют разные формы собеседований.

Я напр использую просто диалог с финалом, если конечно позволяет здешняя бюрократия, Т к понимаю что все прочие формы есть трата времени как кандидата, так и компании и по сути не особо сильно оно определяет справится кандидат с задачами вакансии или нет. Оно проверяет тупо знания академические, которые в большинстве своём не особо наизусть и нужны в работе. Главное-уметь искать и кастомизировать, а опыт познаётся в форме диалога.

Вы же диалог умеете вести? Или только через задачи и опросники мучаете? Если последнее, то у меня для Вас плохие новости.

Ну и в целом, общался с некоторыми коллегами, которые ушли из Яндекса в Озон. Отзывы не самые положительные, но и не плохие. В целом недовольны внутренними процессами.

так 4 технических интервью и у нас уже давно нет! 1 скрининг, 2-3 технических секции и финальные выборы конкретной команды

диалог вести, думаю, умеем ;-) но слишком уж много случаев, когда технический уровень на словах отличается от технического уровня на деле — я понимаю, что получается в итоге, что честные кандидаты страдают из-за нечестных, поэтому и интересны способы, которые бы позволили исправить это

Спасибо за уточнение. Так, а 2-3 секции почему нельзя уложить в одно тех интервью на 1,5-2 часа как это делают многие компании?

На счёт просто диалога забыл добавить, что так делают когда конкретный коллега (руководитель ищет себе в команду или специалист ищет себе помощника) знает кто ему нужен и сам ищет параллельно рекрутерам. Кого сам находит обычно через форму диалога, а когда от рекрутеров-по форме бюрократии компании.

секции разные, по нескольким причинам:

  • разные проводящие, что позволяет нивелировать персональные ошибки

  • если мы говорим про 2 секции, например покодить и поговорить про архитектуру, то пока не придумали, как это ужать меньше чем в 2 часа, чтобы можно было успеть на каждую из этих тем поговорить

Но другим компаниям как-то удаётся (Озон, Каспер, Сбер, ЦРТ, ЦФТ и т д) - да почти все: скрининг+тех интервью+финал

поспрашиваю у инсайдеров... но возможно они готовы получить меньше информации на техническом интервью...

Лучше самому походить по собесам. Рекомендую это делать периодически. Таким образом можно узнать как не нужно это делать и иногда отмечать как нужно. Ключевое-иногда, т е очень редко. И да, заявляю прямо, что хорошо проводить собеседование за разумное время мало кто может. Для этого нужно как минимум постоянно самому проходить собесы в разных компаниях как соискатель и периодически как наниматель. Часто как наниматель не получится, иначе времени на основную работу не останется.

не встречал в больших компаниях практики нанимать мимо «бюрократии», если сам параллельно пообщался просто как-то...

Нет, приглашаешь на одну встречу официально. И оно засчитывается как скрининг и тех интервью одновременно. На встречу можно позвать коллег.

На счёт 4 технических секций по 1 часу каждая-это по информации знакомого, который сам устраивался в Яндекс в мае этого года. Правда ушёл в другую компанию.

я мог бы посмотреть конкретно этот случай в нашей системе с логом секций, чтобы рассказать, почему так получилось — но нужно ФИО знакомого (можно в личку)... 😅

Судя по описанию всё равно очень долго. Важно понимать кто нужен и искать, а так получается что нет чёткого понимания кто нужен и делается очень долгий отбор:

https://yandex.ru/jobs/pages/dev_interview

Думаю опытные разрабы просто в другие компании пойдут, т к за разумное время проще туда уйти за те-же условия (примерно) или даже лучше. Про всех говорить не буду, но тех кого спрашивал: опытные и архитекторы почти все говорили, что точно не будут проходить долгие процессы собеседований, т к обычно к ним самим приходят с предложением и таки да в виде диалога и реже с тех интервью. А вот рядовые или "зелёные" специалисты мечтают попасть в Яндекс) Они просто не понимают, что Яндекс не самая ИТ компания и в ней не лучше всего работать. Зависит от целей. Но за опытным человеком сами придут и всё предложат. Так зачем ему проходить эти долгие этапы? К тому же не все этапы не факт что пройдёт.

но ведь по ссылке написано про скрининг + попрограммировать + архитектура — и это отличается от скрининг+техсекция максимум одним часом (это если техсекция длится час)

для опытных высоких грейдов, про которых мы откуда-то знаем их технический уровень у нас тоже кастомный процесс где больше разговоров про будущий проект и задачи — но вот жаль не про всех мы это знаем :-(

Я прошёл интерактивный тест для бэкендера. Там было 4 задачи, одна сложнее другой, соответственно, одна оценивается выше другой. Я решил первые 3 из 4 в порядке возрастания сложности. Первые 2 вместе с отладкой и вспоминанием консольного ввода решал где-то 40 минут, 3-ю - 2 часа 40 минут. Мне хватило баллов для прохода на следующий этап.

Сразу скажу, что я не спортивный программист, не литкодер. Я обычный работяга. Но алгоритмы я очень люблю, с удовольствием изучаю их и реализую, потому что мне нравится оптимизация и всё такое. Тем не менее, поскольку последний раз с олимпиадным программированием я имел дело лет 5-6 назад, когда ещё учился в 11-ом классе лицея, можно сказать, что опыта спортивного программирования у меня толком нет. Уже после 3-ей задачи у меня сильно заболела голова, я не мог приступить к самой сложной 4-ой, но всё равно был доволен собой, поскольку прошёл необходимый порог.

Следующий этап - интервью через Zoom, написание кода алгоритма под присмотром наблюдателя. Я подключился, мне дали задачу. И меня просто выбило из колеи. Тикающий таймер + чел, который внимательно мониторит весь процесс + алгоритмическая задача, над которой надо очень хорошо думать. У меня от волнения всё в голове перемешалось, я аж синтаксис своего языка забыл. Думал над алгоритмом, но мысли в голову не лезли, я дико затупил, завтыкал. В какой-то момент мне надоело позориться, я попрощался и отключился.

Один мой друг сказал мне, что это было похоже на экзамен с билетами. Но нет, на экзамене студент берёт билет, уходит на своё место, пишет, готовится, а уже потом идёт отвечать. А вот описываемое интервью было скорее похоже на ответ у доски на уроке математики. И я не помню, чтобы хоть раз получал за такое оценку 5. Максимум за домашку, самостоятельную и контрольную.

Уже потом, вечером, через много часов после интервью, я подумал над этой задачей. Решение пришло мне в голову буквально за минуту. И оно было в несколько раз короче решения третьей задачи из отборочного онлайн-теста. Да и значительно проще в плане логики. И вот у меня назрел вопрос: а что вообще тогда проверялось на том интервью? Стрессоустойчивость? Потому что свой уровень кодинга я уже хорошо продемонстрировал на предыдущем этапе. А стрессоустойчивость проверять зачем? Я что, в разведичики иду? В спецслужбисты? Там-то ещё понятно. Там вообще тест психологической выдержки и полиграф. Но зачем тестировать стрессоустойчивость у разработчика ПО? Или есть компании, где на каждую задачу включают таймер, сама задача при этом сложная алгоритмическая, а сзади всегда стоит чувак и внимательно смотрит? Так и поседеть можно смолоду.

Ну, наверное, я просто лох. Я даже не отрицаю. Наверное, литкодеры к стрессу привыкли и легко с ним справляются. Но тогда я вообще не вижу смысла проводить такие интервью. Если вам интересны именно спортивные программисты, то проще (и дешевле) просить у человека ссылку на его профиль на LeetCode или ещё какой-нибудь платформе олимпиадного программирования.

Да, действительно, у меня и раньше были лайв-кодинг интервью. Но там у меня спрашивали относительно простые вопросы, а не алгоритмические задачи. Либо было что-то, касающееся языка и его скрытых особенностей, знание которых приходит либо с опытом, либо с прочтением соответствующих статей.

Да, я знаю, что в Google то же самое. Но Google - одна из лучших в мире компаний, куда вообще можно устроиться. У них огромное количество кандидатов, при чём очень сильных. Так что они (спорно) имеют право быть придирчивыми. Да и многие вещи они сами разрабатывают с нуля, вместо того чтобы использовать готовое. Но даже Google и прочие FAANG-компании критикуют за такие интервью. В итоге теперь они не спрашивают наиболее конченые вопросы вида "почему канализационные люки имеют круглую форму".

да, бывает такое, что сам процесс собеседования даёт сильный стресс (даже если никто не нагнетает его специально, а просто находится в одной конференции, как это делаем мы) и даже решение, которое вполне может прийти за минуту, не приходит — мы стараемся как-то смягчать это во время секций и заранее просим быть морально готовыми к тому, что за процессом решения будут наблюдать

как показывает практика, в большинстве случаев этот эффект уходит буквально после нескольких «тренировок», а сам по себе навык «программировать, когда кто-то рядом» очень пригождается потом в работе, например в процессе парного программирования

А вы на каком языке писали интерактивный тест?

Go, он же Golang.

Ок, я на Яве пробовал, по памяти и быстродействию не проходило. Думал может найду у кого прошло решение.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории