Способность декомпозировать задачу до уровня простых алгоритмов так явно не проверить. Джунов имеет смысл так проверять, но только их, кмк.
Я согласен, что декомпозицию так не проверить. Но когда я провожу собеседование — я сначала проверяю, что человек тянет хотя бы на джуна, а потом уже даю мидловские/сениорские задачи.
Я вижу тут какое-то противоречие: если вы придумываете задачу — она уже по определению не реальная.
Если ваша реальная задача сводится к тому, чтобы заниматься таким вот извращением, возможно вам стоит отойти на шаг подальше, и понять где именно вы свернули не туда
Кажется, вы забываете о том, что не всё программирование делается по шаблону. И иногда приходится обрабатывать терабайты неструктурированных данных для которых оператор сравнения не определён (точки на графе, например).
На объяснение «реальной задачи» может уйти 10 минут. И если я уже знаю, что «реальная задача» сводится к «найти наибольший элемент в массиве без использования оператора сравнения» — то я сэкономлю 10 минут и дам сразу задачу в сжатом виде. Потому что на собесе время ограничено. И если кандидат успеет быстро решить задачу — то поясню, откуда она такая взялась и как она относится к нашей деятельности. Но только если времени хватит.
Простите, что придираюсь, но оплата картой — это оплата наличными. В обиходе принято называть наличными только материальные деньги, но вообще говоря этого неверно.
В отдельных маленьких организациях это работает лишь потому, что у каждой конкретной организации выборка маленькая =) В тех маленьких, которых был я — не сработало ни разу (т.е. все, кого наняли «по прошлому опыту» оказались буллшитерами). Но, правда, я там не принимал участие в собеседованиях, а только наблюдал.
Ох, сколько нужно — не знаю. Обычно я даваю две простых задачи. Я считаю, что если человек не может решить одну простую задачу — мб не повезло, нервничает и т.п. А если не может решить две — это уже закономерность.
Но тут ведь система со смещённым фидбэком: если мы наняли слабого человека (т.е. человек оказался слабее, чем показалось при найме), то мы об этом узнаем; а если не взяли сильного (т.е. человек оказался сильнее, чем нам показалось) — то не узнаем. Поэтому очень сложно подобрать оптимальное количество и сложность задач.
Есть ещё интересное соображение: если давать много простых задач, то можно не успеть дать сложные (и недооценить кандидата). И это действительно правда, изредка так и бывает. Но если дать сразу сложную задачу и кандидат её не решит — тут всё намного хуже. Т.к. если кандидат не решил сложную задачу — это не значт, что он не подходит, мб он пойдёт на должность ниже. Надо разибраться с причиной того, почему конкретно человек не смог решить задачу — а это ну очень сложно. Я видел как люди на собесе очень хорошо всё рассказывают по плану задачи, но не хватает времени написать код. Их берут в штат, и оказывается, что люди и код-то толком писать не умеют. Это было бы отлично видно, если бы дали простую задачу, но т.к. дали сложную — то подумали, что «перемудрили с задачей, давайте просто дадим ему не сениора, а мидла».
Ну как бы меркантильно это ни звучало, но время кандидата дешевле, чем время разработчика. Потому что большинство кандидатов отсеются с нулевым результатом, а разработчик время-то потратит всё равно.
— это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),
О, ну тут всё просто. Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива». Потому что им на практике нигде не надо было работать работать с большими данными и, соответственно, задумываться про асимптотику и т.п. Поэтому к «реальным» задачам далеко не все могут перейти. Но они есть, вполне себе интересные.
это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.
Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).
Текущая система используется (кстати, в том же FAANG примерно всё то же самое при найме — регулярно прохожу собесы чтобы «знать рынок») не потому что идеальная, а потому что пока лучше ничего не придумали.
Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
Так ведь в каждой конкретной ситуации надо смотреть и думать, что нужно. Не может быть универсального решения, т.к. где-то очень важен lookup-time (не асимптотика, а чистое время), где-то важен объём памяти, занимаемый данной структурой. Вы, кажется, не понимаете, что когда речь идёт о миллиардах, то начинает быть важна каждая мелочь.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
Ну всем подряд и не задают. У вас тут типичная ошибка выжившего. Те, у кого интервью прошло нормально — они на хабре статей не пишут. Тут не принято писать о том, что в Яндексе хорошие собеседования, за такое можно и минусов отгрести. Поэтому вы со стороны видите только те собесы, которые прошли отстойно. Или прошли нормально, но человеку не хватило компетенции понять, что его вообще спрашивали и какие скиллы проверяли.
Это крайне плохо, да. Пока вы не сталкиваетесь с масштабами Яндекса. Когда вам нужен хэш-тейбл на миллиард элементов, то внезапно оказывается что стандартная реализация не такая уж и хорошая.
Эти собеседования нужны как раз для отсечения людей, которые мало того, что не привыкли работать с оглядкой на миллионы запросов в секунду (потому что «ну сколько реально запросов может быть-то?»), но и не понимают, что иногда размер данных больше, чем цифр в их номере телефона. А, ну и забыл мантру: «стандартная библиотека реализована эффективно, её можно использовать в любых высоконагруженных системах» (нет)
Вы написали неиформативный комментарий, который ничего не поясняет читателю. В моём комменте есть конкретный пример, позволяющий понять некорректность рассуждений автора выше. Ну и стиль изложения у вас, прямо скажу, сложный для восприятия.
Тут ведь какое дело — заранее не знаешь, бред там или гениальное открытие. Вот вы, например, будете рассказывать Ньютону о том, что закон относительной скорости (т.е. объект A движется относительно объекта B со скоростью Va — Vb) иногда не работает. И на вас как на шизика посмотрят, потому что абсолютно все эксперименты и все учёные того времени чётко видели свою картину мира. И не было тогда инструментов для опровержения очень логичной и понятной теории.
У вас очень странный стиль изложения мыслей. За 50 лет до разреза было 4 нобелевки, за 30 лет после разреза было 3 нобелевки. Вроде с открытиями всё ок. С бюджетом (судя по з/п сотрудников) тоже.
Я бы сказал что оно наивное т.к. люди думают, что там что-то типа «популярность * X + просмотры * Y + ....». Мол, вот формула, всё понятно. А на самом деле там (предположительно) мегабайты строк хитрого кода, переплетённые с ML всех сортов.
Мне это напоминает требование выложить исходный код (т.е. веса) нейросетки, которая распознавала лица в какой-то американской фирме. Ну выложили, понятнее всё равно не стало =)
В идеальном мире в ФАС должны работать очень умные и опытные дядьки, которые могут вовремя оценить, кого и и когда пускать под нож. История знает вполне успешные примеры таких решений (на мой взгляд самое успешное — это разрезание ATnT, но и Standard Oil тоже вполне ок). Но это только в идеальном мире…
Я согласен, что декомпозицию так не проверить. Но когда я провожу собеседование — я сначала проверяю, что человек тянет хотя бы на джуна, а потом уже даю мидловские/сениорские задачи.
Я вижу тут какое-то противоречие: если вы придумываете задачу — она уже по определению не реальная.
Кажется, вы забываете о том, что не всё программирование делается по шаблону. И иногда приходится обрабатывать терабайты неструктурированных данных для которых оператор сравнения не определён (точки на графе, например).
Я не дал ответ который вы хотели услышать. Но если вы читали невнимательно, то вот мой ответ:
Но тут ведь система со смещённым фидбэком: если мы наняли слабого человека (т.е. человек оказался слабее, чем показалось при найме), то мы об этом узнаем; а если не взяли сильного (т.е. человек оказался сильнее, чем нам показалось) — то не узнаем. Поэтому очень сложно подобрать оптимальное количество и сложность задач.
Есть ещё интересное соображение: если давать много простых задач, то можно не успеть дать сложные (и недооценить кандидата). И это действительно правда, изредка так и бывает. Но если дать сразу сложную задачу и кандидат её не решит — тут всё намного хуже. Т.к. если кандидат не решил сложную задачу — это не значт, что он не подходит, мб он пойдёт на должность ниже. Надо разибраться с причиной того, почему конкретно человек не смог решить задачу — а это ну очень сложно. Я видел как люди на собесе очень хорошо всё рассказывают по плану задачи, но не хватает времени написать код. Их берут в штат, и оказывается, что люди и код-то толком писать не умеют. Это было бы отлично видно, если бы дали простую задачу, но т.к. дали сложную — то подумали, что «перемудрили с задачей, давайте просто дадим ему не сениора, а мидла».
О, ну тут всё просто. Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива». Потому что им на практике нигде не надо было работать работать с большими данными и, соответственно, задумываться про асимптотику и т.п. Поэтому к «реальным» задачам далеко не все могут перейти. Но они есть, вполне себе интересные.
Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).
Текущая система используется (кстати, в том же FAANG примерно всё то же самое при найме — регулярно прохожу собесы чтобы «знать рынок») не потому что идеальная, а потому что пока лучше ничего не придумали.
Так ведь в каждой конкретной ситуации надо смотреть и думать, что нужно. Не может быть универсального решения, т.к. где-то очень важен lookup-time (не асимптотика, а чистое время), где-то важен объём памяти, занимаемый данной структурой. Вы, кажется, не понимаете, что когда речь идёт о миллиардах, то начинает быть важна каждая мелочь.
Ну всем подряд и не задают. У вас тут типичная ошибка выжившего. Те, у кого интервью прошло нормально — они на хабре статей не пишут. Тут не принято писать о том, что в Яндексе хорошие собеседования, за такое можно и минусов отгрести. Поэтому вы со стороны видите только те собесы, которые прошли отстойно. Или прошли нормально, но человеку не хватило компетенции понять, что его вообще спрашивали и какие скиллы проверяли.
Я бы сказал что оно наивное т.к. люди думают, что там что-то типа «популярность * X + просмотры * Y + ....». Мол, вот формула, всё понятно. А на самом деле там (предположительно) мегабайты строк хитрого кода, переплетённые с ML всех сортов.
Мне это напоминает требование выложить исходный код (т.е. веса) нейросетки, которая распознавала лица в какой-то американской фирме. Ну выложили, понятнее всё равно не стало =)