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

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

Стиль изложения — огонь. Жду продолжения истории
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет

Бедные курьеры...

Не курьеры, а коммивояжеры.

И решали задачу о рюкзаке?
Это та же задача, что и о коммивояжерах
Коммивояжёр решает рюкзак, наоборот нет.
Авторитетно, как яндекс-курьер получивший оффер, заявляю.

ПС
: sarcasm:

Я не настоящий сварщик, я маску нашёл, но насколько я понимаю, под словами "задача коммивояжёра" и "задача о рюкзаке" могут подразумеваться несколько разные вещи, в том числе NP-полные задачи, так что сведение одной к другой неочевидно в таком простом заявлении, как ваше :)

вы слишком многого хотите от курьера яндекс-яды.

Но если брать формулировку по «knapsack problem» и «travelling salesman problem» в английской вики — то я не вижу как решение второго свести к решению первого (без многократного повторения или увеличения размерности задачи).

Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)


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

Насколько я вижу по вики (да и всегда думал) — задачи имеют разное название потому что это разные задачи. Там где задачи явно сводятся к другим обычно это пишут, например тут


The knapsack problem is a generalization of subset-sum.

Если не пишут значится что не сводится одно к другому

Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)

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

Вопрос как раз и был о том, чистите ли вы свой дымоход. :)


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

Мне диплом был нужен только для того, чтобы страховка не придиралась к тому, что я не вызываю два раза в год дипломированного специалиста. А так я сам себе Буратино :)


Но действительно, Рассела не узнал, богатым будет.

Ветка огонь. Теперь финальная задача. Обойдите все дерево комментов не заржав ни разу) Стандартной библиотекой пользоваться нельзя)
Я срезался на вашем комменте.

Сколько теннисных мячей поместится в сумку

а сколько это будет в виде гитар?
Питерская контора яндекса должна помещать в сумки тело.
… найти минимальное количество распилов, чтобы уместить тело в заданном объеме…
С учётом тяжести пиления или без?
Учитывайте, но сторонние библиотеки нельзя.
Они ее распараллеливают, отправляют сразу 100500 курьеров одновременно, кто-то да дойдет.
Доставка еды по UDP? Приезжает отдельно колбаса, потом сыр и только к утру сам блин, а коробка где-то теряется

Вы только что Wildberries описали :)

В голос, спасибо! :)

Они думают, что так и будут по алгоритмам бегать, а после приема на работу приходится бегать по городу.
Это не шутка, ну или почти не шутка. Давно проходил собеседование на позицию Project-manager — первым вопросом было: «Какие алгоритмы сортировки вы знаете?»
Через много лет, когда стал Solution Architect, также было интервью по этой позиции, и угадайте каким был первый вопрос?:)
Да я и второй угадаю: «А можно быстрее?».
> Какие алгоритмы сортировки вы знаете?

Не, ну это ещё можно вытерпить. Хуже, когда хрюша идёт по опроснику и спрашивает «Какой алгоритм сортировки лучший?».
А для вас это очевидный вопрос? я бы если честно замешкался, т.к. нет никакого лучшего алгоритма. А что подразумевается-то?
Вот именно!
Вопрос-то с подвохом: если назовете хоть один — пиши пропало.

"Каждое ваше слово может быть использовано против вас"

Старый анекдот в тему
— арифмометр
— что арифмометр?
— используйте против меня арифмометр

В оригинале была голая баба :)

задать вопрос «а вы по какой книжке опрос составляли?» 8)))))
Так и есть, гоняют будь здоров, всегда. До 12 собеседований по алгоритмам доходит, а то и больше. И статья, про яндекс беспредел, уже далеко не первая и не последняя, но они имеют тенденцию удаляться. Люди на таком собеседовании разные попадаются, одни тебя пропустят, другие завалят на одних и тех же задачах. Ладно бы это было только в онлайне, а то и приехать просят, а это уже 4 часа только на одно такое собеседование. А если с возрастом давление шалит, то и не на каждом собеседовании блеснуть получается.
И ради чего?.. свет клином же не сошелся на Яндексе… Уж лучше какой-нить европейский стартап.
Ради того чтобы сказать, решаете вроде правильно, но как то медленно, и вообще мы Яндекс, вот вам на 100 тысяч меньше обещанной ЗП, выходите на работу и гордитесь что мы вас взяли. (из личного опыта)
«Работать в нашем банке — большая честь» (С)
При всех минусах такого найма, там работают отличные разработчики. Так что могут себе позволить. Желающих много. Да и найм у них в основном с вузов, где живут олимпиадными задачками.
Это плохая тенденция — считая себя великим, позволять себе «неадекватность». И потом, отличные разработчики работают практически везде, даже дворниками. Тем более что желающих много, каждого так собеседовать по 6-12 часов — это как то жирно, больше похоже на практику для уже работающих. А уж олимпиадными задачами не кормиться только ленивый, они в открытом доступе и даже нашему коллективу филиала из «откуда-то» удалось попасть в полуфинал мирового чемпионата. И все же, больше вопросов возникает к отдельным личностям, а не к общему маразму.
К сожалению, это не шутка…

И ЗП меньше среднего, прям как в Яндекс доставке!

Ну кстати неизвестно. до ковидлы ходил к ним на тех.манагера собеседоваться. на входе просил немного больше среднего по рынку (хотя хз может оно срденее или ниже, а я не знал)), но они не отказались общаться
Работал в Яндексе техническим менеджером, в итоге предложили зп сильно ниже того, что озвучивал. Но я уже прошел все собеседования, потратил кучу времени и в итоге решил рискнуть) Через год уволился)
Я не дошел до конца) После третей собеседки отказали (у меня последний опыт хреланса/удаленки, а это для них, как выяснилось, зашквар).

видимо, в этом и цель многодневных собеседований.


это как тест на 500 вопросов, в конце которого надов вести номер карты, чтоб узнать, какой вы олень.

А они так и делают всегда, но в конце будет меньше всё-равно.

Это не шутка
Собеседовался пару раз на девопса в Яндекс, первый раз года 3-4 назад, поговорили даже нормально половину интервью, потом дрочево алгоритмов, второй раз года полтора назад, всё проходило 1в1 как тут описано, готовился не менее ответственно, чем автор поста.

После прочтения предыдущих комментов и поста, а потом вашего коммента, в голове само всплыло название следующего сервиса: Яндекс.Девопс. Ну, знаете, сдача админов, которые почти прошли собеседование, в аренду клиентам Я.Облака.


Ну, чтобы просто результаты собеседований хоть как-то применить, даром, что они по алгоритмам!

Примерно то же самое проходил перед нг, но у меня сложилось впечатление, что у яндекса девопс это бекендер на дежурствах. Прошел первый такой этап, но настойчиво порекомендовали порешать больше задач на алгоритмы. Продолжать эти круги собеседований я не захотел и просто слился.
Несколько лет назад собеседовался на разработчика в Облако. Ожидал, что будет много вопросов по алгоритмам, но завалили вопросами по «железкам» и всему, что около них, а потом дали пару задач на лайвкод на любом удобном языке.
На многие вопросы из первой части я ответил с большим трудом, а на некоторые ответов вообще не знал, что наверняка и послужило поводом меня слить)
Напомнило: когда в 2008 (или 2009) на заре карьеры я устраивался в яндекс тоже просили проверить на корректность какое-то дерево и возмущались, что я знаю Руби: не то что пишу на нем, тестовое задание делал на C++, а именно что вообще знаю — интервьюер говорил с презрением «что это за Руби?», «какой-то учебный язык?», «какой-то школьный что-ли?».
Такое впечатление, что в яндексе хорошо умеют проверять знание алгоритмов — вот и ищут специалистов где светлее, а не за углом где потеряли.
Это неправда. В данном случае просто не повезло с подрядчиком, кому заказали рекрутирование. В моем случае все было лучше, глушил уже сотрудник Яндекса на последнем этапе, противореча собственным же инструкциям. Правда даже пройдя все этапы, нет уверенности, что вы будете работать в Яндексе, а не на Яндекс в какой-то левой фрилансовской компании.
Правда это было достаточно давно, что бы Яндекс не мог засудить меня за разглашение, ибо соглашение о неразглашении истекло.

Меня не взяли водителем беспелоднега хотя я идеально соответствую требованиям вакансии. Про алгоритмы, с.ка, даже не спросили...

Ходил на DevOps'a собесится. Было ТРИ собеса по алгоритмам, одно по админству и ни одного по ci/cd и профильным сервисам. Там оч странно
Подскажи плиз, как и зачем собесить по ci/cd, если это учиться за неделю-две и в Яндексе свои велосипеды?
Хочешь сказать чтобы писать эти велосипеды вообще не надо ничего уметь?

Работаю девопс-инженегром. Ни разу за 6 лет не понадобились знания алгоритмов сортировки или слияния массивов. Скрипты пишу постоянно…
Расскажи, пожалуйста, как ты видишь идеальное собеседование на DevOps'a.
в 2018 собеседовался на продажника в яндекс. Задавали алгоритмический задачки))
И еще кучу беспонтовых вопросов
А мне понравились алгоритмические задачки в яндексе. Первым делом в голову приходит простой алгоритм с большой сложностью. А потом при помощи подсказок собеседующего и всяких хитростей он доводится до сложного, но с малой сложностью. Но у меня, конечно, таких задачек было штуки 4 на двух собеседованиях. На остальных проверяли уже не алгоритмы.

Задачки нормальные, но зачем столько? Трёх-четырёх достаточно. Я бы уже на втором таком интервью вежливо распрощался, если я захочу порешать задачки, я пойду на hackerrank или leetcode.

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

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

Внезапно, кандидат тоже работает, собеседование ему никто не оплачивает (а часто это во время рабочего дня) => вылазка для него может оказаться достаточно проблематичной.

Ну значит поток кандидатов с высокой самооценкой поредеет и это частично тоже решит задачу "снизить поток заявок до приемлемого уровня".

А почему им его должно быть жалко? Это ж не их время. Вот времени своих разрабов — наверняка жалко.
Ну так если вам нравятся, то и решайте их на leetcode)
Они созданы, чтобы проверять знание кандидатом базового синтаксиса. Конечно, немного думалка тоже проверяется, но алго-думалка с обычной не совсем коррелирует и даже скорее совсем не коррелирует.
Я бы сказал так – в промышленной разработке очень полезно знать, как устроены алгоритмы, но крайне плохо, если их приходится писать самому.
Это крайне плохо, да. Пока вы не сталкиваетесь с масштабами Яндекса. Когда вам нужен хэш-тейбл на миллиард элементов, то внезапно оказывается что стандартная реализация не такая уж и хорошая.
Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)

Но там не задают задачу на написание хеш таблицы. Максимум на использование. И полностью рабочее бинарное само-балансирующееся дерево — тоже не задают. Максимум тривиальное дерево. Просто для проверки, что кандидат может представить структуру и хоть чуть-чуть понимает, как работают указатели.

Вот именно. То есть зачем они ищут тех, кто пишет алгоритмы а не программы — непонятно.
А как проверить? Алгоритмы хороши тем что не умея программировать их не выучишь наизусть за 3 месяца. В отличии от баззвордов и 100 типовых вопросов по любой технологии.
И на софт скилах не выедешь, как можно сделать в разговоре за жизнь.
И можно разных кандидатов сравнивать друг с другом. По формализуемым признакам.

Предложите альтернативный вариант. Чтобы не хуже было хотя бы по этим критериям.
Ну народ за несколько месяцев мощно насобачивается на решение задач с leetcode.
Да. Народ уже умеющий нормально программировать. Не случайные люди с улицы после курсов вайти.

Какой варинат решения прелагаете? Спрашивать еще сложнее? Рюкзак модифированный так чтобы его случайный человек не узнал пойдет? Так отсеются вообще все. Случайный мидл даже после сидения на литкоде не справится же.
Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.

Более-менее нормальный подход — давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить (то есть надрочиться на литкоде не поможет), а головой подумать, плюс и прикладной смысл чтобы был, и дать человеку ее решать в привычной среде — просто расшарив экран. Пусть гуглит что хочет (кроме прямого решения задачи, конечно), вообще разрешено все (как и что человек гуглит — это вообще о многом сразу говорит!). И посмотреть, КАК человек это все делает. Такое, типа, парное программирование.

Тут, конечно, формальных баллов не начислишь, все субъективно. Но уровень сразу виден, уже через пять минут на самом деле.
давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить

Ну посмотрите же задачи из статьи. Где там хоть одна, где надо алгоритмы помнить? Максимум, знать, что есть такая структура данных — хеш-таблица.

А примерчик ещё проще чем в статье можно? Там все еще проще вырождается в однострочник или физзбазз.


IDE или не IDE дискуссионно.

Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.

Ну так в отличие от ИДЕ от вас не требуется написать компилируемый код, а иногда не требуется и брать существубщий ЯП — достаточно просто набросать алгоритм, чтобы было понятно что куда и как. Вангую что никто не будет докапываться если в каком-нибудь SelectMany букву забудете или порядок аргументов какой-нибудь функции перепутаете. Главное как вы будете рассуждать и какие уточняющие вопросы задавать.

Код запускается и проверяется. Но это по моему опыту и знакомых.

Если от вас требуют написать без ИДЕ на бумажке идеально компилирующийся код без ошибок — то это вполне хороший фактор чтобы туда не идти. Так что не вижу ничего плохого в том чтобы получить на такое отказ.

Это где? Особенно с вайтбордом интересно — по-вашему, интервьюер потом сидит и перепечатывает код?
В яндексе, но не у всех. Зависит от интервьюера.
Умение писать алгоритмы, и умение работать в команде, знать фреймворки и другие вещи — вообще не особо связано.

Но вопрос в основном в театре абсурда, когда тебе на 10 интервью задают то одни то другие алгоритмы И НИЧЕГО по технологиям

А в разговоре за жизнь можно много чего узнать. Что человек сделал, зачем, почему.
пишет алгоритмы а не программы

Что? По определению, любая программа — алгоритм. Если вы придираетесь к тому, что там на интервью спрашивают заумные алгоритмы, которые в реальной работе не пригодятся — то вы не правы.


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


Я за свою недолгую пока карьеру в гугле много раз использовал и математику и писал хитрую структуру данных, и динамическое программирование. Не каждый день конечно, но эти вещи реально пригождаются. И самое печальное, что если этого всего не знать, то даже мысль не возникнет о том, что вот тут можно было "алгоритм" впендюрить и получить более быстрый и простой код. До этого немного поработал в яндексе, и там пришлось, например, использовать trie для ускорения процесса в несколько раз. Этой структуры нет в stl. Про нее надо хотябы знать, иначе как вообще ее нагуглить?

Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.

Так ведь в каждой конкретной ситуации надо смотреть и думать, что нужно. Не может быть универсального решения, т.к. где-то очень важен lookup-time (не асимптотика, а чистое время), где-то важен объём памяти, занимаемый данной структурой. Вы, кажется, не понимаете, что когда речь идёт о миллиардах, то начинает быть важна каждая мелочь.

А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)

Ну всем подряд и не задают. У вас тут типичная ошибка выжившего. Те, у кого интервью прошло нормально — они на хабре статей не пишут. Тут не принято писать о том, что в Яндексе хорошие собеседования, за такое можно и минусов отгрести. Поэтому вы со стороны видите только те собесы, которые прошли отстойно. Или прошли нормально, но человеку не хватило компетенции понять, что его вообще спрашивали и какие скиллы проверяли.
Всё это помешательство на алгоритмах может объясняться, гипотетически, двумя возможными причинами:
— это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),
— это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.
Бардак с «деревом» собеседующих (изоляция процесса найма от реальных задач, как результат этого), размер компании, а также некоторые решения, которые ранее использовались Яндексом, склоняют меня к тому, что более вероятно второе. Ваш же аргумент косвенно исходит из первого, а возможность второго — игнорирует.
— это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),

О, ну тут всё просто. Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива». Потому что им на практике нигде не надо было работать работать с большими данными и, соответственно, задумываться про асимптотику и т.п. Поэтому к «реальным» задачам далеко не все могут перейти. Но они есть, вполне себе интересные.

это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.

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

Есть ещё интересное соображение: если давать много простых задач, то можно не успеть дать сложные (и недооценить кандидата). И это действительно правда, изредка так и бывает. Но если дать сразу сложную задачу и кандидат её не решит — тут всё намного хуже. Т.к. если кандидат не решил сложную задачу — это не значт, что он не подходит, мб он пойдёт на должность ниже. Надо разибраться с причиной того, почему конкретно человек не смог решить задачу — а это ну очень сложно. Я видел как люди на собесе очень хорошо всё рассказывают по плану задачи, но не хватает времени написать код. Их берут в штат, и оказывается, что люди и код-то толком писать не умеют. Это было бы отлично видно, если бы дали простую задачу, но т.к. дали сложную — то подумали, что «перемудрили с задачей, давайте просто дадим ему не сениора, а мидла».
Вы налили тонну воды, но ответ все же дали — две задачи должно быть достаточно для общего случая. А теперь перечитайте статью и посчитайте, сколько дали автору. Я не знаю, о чем тут можно спорить.
Все перечисленные нюансы — реальность, но другого порядка.
Вы налили тонну воды, но ответ все же дали — две задачи должно быть достаточно для общего случая.

Я не дал ответ который вы хотели услышать. Но если вы читали невнимательно, то вот мой ответ:
сколько нужно — не знаю.
Две задачи достаточно, если один интервьювер на всех и он абсолютно объективен/непоколебим.
На деле же, когда у компании 1000 кандидатов, а нанять надо 50-100, то интервьеров будет человек 100. Из них части попадутся знакомые знакомых, часть окажется олимпиадниками, которым ничьих знаний не будет достаточно, части будет не жалко нанимать всех, кто решит простую задачу, которую решают на первом курсе любого вуза. А ещё кандидат может одному интервьюеру понравиться, а другому нет визуально, может разволноваться с одним интервьюером, а с другим — нет и т.п. Получится рандом, усугубленный тем, что сильных кандидатов меньшинство.

Для примера пусть из 100 собеседующих 25 не наймут никого, 25 наймут любого, а 50 наймут сильного кандидата и не наймут слабого.
Пусть из 1000 кандидатов 100 сильных (кого в идеале хотел бы нанять Яндекс; каждый 10й).

Тогда при одном собеседовании на каждого кандидата будет нанято 25% (шанс попасть на лёгкого собеседующего) * 900 = 225 слабых кандидатов и 75%*100 = 75 сильных. А надо бы, чтобы соотношение было 0 на 100.
Вот и делают дублирующие собеседования.
Если на каждого кандидата по две секции и нанимают только тех, кто прошел обе, будет нанято 56 (900*0,25*0,25) слабых кандидатов и 56 сильных. Уже лучше, но соотношение всё равно плохое. Даже один слабый прогер уровня миддла может уронить продуктивность команды из 3-5 сильных мидлов.
Делаем третье собеседование. Наняли 14 слабых и 42 сильных. Ещё лучше, но большая часть сильных будет отсеяна.
Делаем четвертое и разрешаем одно собеседование провалить. Получаем 900 * (0,25 ** 4 + 0,25 ** 3 * 0,75 * 4) = 45 слабых и 73 сильных.
Много слабых. Добавляем пятое собеседование на ту же тему (одно можно завалить)
Получаем 14 слабых и 63 сильных.

Если сделать 6е, получим 4 слабых кандидата и 54 сильных.
Примерно поэтому в Яндексе обычно 6 секций +- одного и того же. В Гугле аналогично.
Нормально, что среди 942 отсеянных находятся те, кто пишет статьи на хабр о том, какие неадекваты в Яндексе. Согласно модели шанс, что это подходящий Яндексу прогер, процентов 5.
Но по подходу автора (писать квадратичную асимптотику вместо линейной, потому что так привычнее) видно, что тут к Яндексу только один вопрос — зачем было тратить время кандидата и интервьюеров на секции после 2й-3й.

Вы меня поразили прям в мозг. Ну добавьте тогда в ваш зоопарк интервьюеров, которые выдают результат в зависимости от дня недели, и интервьюера, который убивает кандидатов с шансом 50%… В моём понимании интервьюер — это функция, которая принимает на вход знания кандидата и выдаёт 0 или 1. Если этот интервьюер выдаёт много FP или FN, значит это паршивый интервьюер и нафига он нужен. Если есть шанс ошибки, то поставьте 3-4 интервьюера рядом и пусть они исправляют друг друга. Добавьте ещё штуки 4 теста для быстрого вылета кандидатов, типа если напишут O(n^2) или если ник начинается с k, то сразу отлуп. Всё.


Судя по тому, что я видел, Яндекс не парится и берёт пулл кандидатов, пулл сотрудников, и как на той картинке с игрушечными собачками скрещивает их. А ведь эту кучу часов, которые рекрутеры тратят на кандидатов, можно было потратить, чтобы — внезапно — улучшить рекрутеров самих и весь процесс в целом.


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

Да, Яндекс рандомно назначает кандидатам собеседующих из пула. Есть внутрянняя система фидбека, куда интервьюеры пишут, что спрашивали, что ответил кандидат и оценку. Другие интервьюеры (если секция не в тот же день), обычно проверяют, чтобы не спрашивать повторно те же задачи.
Не очень понятно, как вместо того, чтобы собеседующие проводили по 6 секций с каждым кандидатом, пустить их время на улучшение процесса. Сажать по 6 человек на кандидата — не уменьшит времязатраты интервьюеров, но уменьшит точность за счёт меньшего числа вопросов.
Есть ли примеры крупных IT-компаний (1000+ разработчиков, не бодишоп), где быстро собеседуют и быстро могут дать положительный фидбек?
В гугле с момента подачи резюме до оффера проходит 3-6 месяцев. В Яндексе 1-2 месяца. Да, не неделя, как в небольших компаниях, но раз недостатка в кандидатах нет и акции растут, значит всё работает норм.
раз недостатка в кандидатах нет

спорное утверждение.
Ко мне рекрутеры Яндекса обращаются с завидной регулярностью. Причем уже доходило до того, что мои данные «передавали» в КА/РА, которое работает на Яндекс.
Ко многим знакомым — тоже.
Да, не спорю, туда все еще многие мечтают попасть, но есть ли прямо очереди? Чё-т не уверен.
Основной признак недостатка кандидатов — снижение планки найма.
Активность HRов, это вполне предсказуемый процесс. Яндекс хочет нанимать самых подходящих специалистов на рынке. При этом сильный кандидат может и не подозревать, что его примут в Яндекс. Поэтому Яндексу в целом выгодно множество HRов, которые ходят по рынку и холодными звонками выцепляют людей на собеседования.
И HRы эти далеко не всегда сотрудники Яндекса. В целом есть распространённая модель партнёрства, когда ты заключаешь с компанией договор о том, что она с каждого трудоустроенного от тебя кандидата платит тебе процент. А дальше ты сам себе хозяин и ищешь кандидатов где только можешь. В результате да, бывают эксцессы, а люди могут сокрушаться в комментариях, мол «мне написывал HR из яндекса, как же они задолбали», но это не признак недостатка желающих пройти собеседование.
Мне, например, когда я работал в Яндексе, в Линкедине писали такие HRы предлагая прийти на собеседование в Яндекс. Бывает, что уж
Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива».

Если инплейс то можете подсказать как? Потому что так-то ничего сильно лучше arr.Where(x => x != 0).ToArray() и не придумывается.


Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).

Можно тоже пример? По опыту в маленьких компаниях это отлично работает, не очень понятно что именно должно сломаться в случае большой. Или у вас в маленьких тоже не работает? Тогда тем более хотелось бы услышать ответ.

Если инплейс то можете подсказать как?

Примерно так:


function remZero(arr) {
    var p = 0;
    for (var i = 0; i < arr.length; ++i) {
        if (arr[i] !== 0) {
            arr[p++] = arr[i];
        }
    }
    arr.length = p;
}

А ну да, логично, даже странно что я про это не подумал. Мне почму-то показалось что мы можем элементы местами менять и нарушить относительный порядок. Немного не в ту сторону подумал.


В целом это и есть arr.Where(x => x != 0).ToArray() только копируем прям на месте вместо свободных нулей. Да, спасибо, тупанул чет

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

По прошлому опыту это ведь не просто "наврите нам покрасивее" а вопросы по этому опыту. Почему сделали так, а не иначе. А вот зачем этот компонент. И так далее.


Плюс можно гитхаб посмотреть если есть, если нет — то все же какую-нибудь задачку разминочную на 10 минут тоже можно. Это не дрючить 10 алгоритмическими задачками на 5 раундах собеседований, но какое-то видение дает. Вкупе с вопросами по арихектуре можно делать выводы.

Уже сейчас есть в интернете куча платных и бесплатных курсов, задрачивающих людей решать задачи. Т.е. человек без опыта может научится решать задачки и пройти интервью.


Если FAANG будет спрашивать массово про опыт и профиль на гитхабе, то будут курсы, которые будут учить людей складно рассказывать про "прошлый опыт" и объяснять по этому чужому профилю на гитхабе, почему сделали так, а не иначе.


В текущей ситуации имеем людей, возможно вайтишников, которые научились решать алгоритмические задачи. Значит перекладывать json они точно смогут, ибо это проще. В гипотетической ситуации будем иметь кучу вайтишников, очень слабо программирующих, но складно говорящих.


Вторая проблема: поговорить про опыт и посмотреть гитхаб — слишком субъективные оценки. Такое не годится для крупных компаний, которых пытаются засудить за дискриминацию, потому что интервьювер посмел спросить про размер байта в битах.


А еще это на порядок сложнее для интервьюверов. Сходу вот так глядя на неизвестный вам проект понять, что вот такое решение было лучшим, невероятно сложно. Это потребует невероятно много времени подготовки у интервьювера. Когда как задачки можно спрашивать одни и те же, пока они не утекут в сеть.


Вот и получается, что спрашивать задачки — единственно подходящее решение для интервью в FAANG/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.

Интересно, когда появятся курсы, которые учат работать.

Они уже есть. Но научится работать же сложнее чем только научится скилам прохождения интервью. Люди ленивые и стремятся облегчить себе жизнь.

«There is no compression algorithm for experience» by Andy Jassy
Научиться работать и не пройти интервью(или пройти на заниженную зарплату) — тоже такое себе
Если FAANG будет спрашивать массово про опыт и профиль на гитхабе, то будут курсы, которые будут учить людей складно рассказывать про "прошлый опыт" и объяснять по этому чужому профилю на гитхабе, почему сделали так, а не иначе.

Складно рассказать про прошлый опыт по-моему невозможно не прожив этот самый опыт. Шаг влево-вправо от "рассказывали на курсах" и провал. По крайней мере мне слабо представляется как можно составить решебник на все возможные вопросы.


Вторая проблема: поговорить про опыт и посмотреть гитхаб — слишком субъективные оценки. Такое не годится для крупных компаний, которых пытаются засудить за дискриминацию, потому что интервьювер посмел спросить про размер байта в битах.

Ну это да, но мне показалось выше сказали что и для маленьких такой способ не подходит.


А еще это на порядок сложнее для интервьюверов. Сходу вот так глядя на неизвестный вам проект понять, что вот такое решение было лучшим, невероятно сложно. Это потребует невероятно много времени подготовки у интервьювера. Когда как задачки можно спрашивать одни и те же, пока они не утекут в сеть.

Так что сложного? Все непонятные места адресуются кандидату — по его ответам будет понятно, думал он про это или нет, какие варианты отбросил и т.п. Не надо додумывать — надо спрашивать (если конечно есть у кого), наверное одна из первых вещей которые я понял когда начал работать: быстрый фидбек с короткими циклами — залог успеха.


Вот и получается, что спрашивать задачки — единственно подходящее решение для интервью в FAANG/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.

Ну задачки отбирают либо студентов которые недавно их проходили либо сверхмотивированных людей которые в свободное время прорешивают литкод чисто ради фаанга. Пробовал так сделать в прошлом году — после пары десятков задач задолбался и забил.


Я не предлагаю никаких альтернатив, просто рассматриваю минусы текущего подхода. Вполне вероятно это лучшее из худшего.

лучшее из худшего.

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

Ужасный метод. Но лучшего, на мой взгляд, нет.

Есть. Даёте задачу и для неё штуки 3-4 решения готовых, и пусть интервьюируемый посмотрит их и скажет какое лучше и почему. Меньше затрат времени на собеседование, и плюс не будет каких-то глупых ошибок из-за спешки, стресса, неудобства написания кода в блокноте, на бумажке, или на доске.

Тут в соседнем треде мне другой товарищ доказывал, что эти алгоритмические интервью — ужасны, потому что их проходят легко "профессора" знающие наизусть О-большое всех-всех алгоритмов и умеющие доказывать заумные абстрактные утверждения, но вообще нисколько не умеющие писать код.


В отличии от текущих интервью, ваш вариант как раз подвержен такой проблеме.


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

Подавляющее большинство обычных задач в наше время — это как раз необходимость «выбрать из нескольких предложенных вариантов». Уже много раз упоминалось, что «всё давно уже написано», если не в стандартных библиотеках, так на стековерфлоу, нужно просто посмотреть где лучше и выбрать самый подходящий вариант.

Нет. Вам не даны несколько вариантов. В реальной жизни у вас есть только задача. Вам надо эти варианты еще найти. Как понять, что вот этот вот ответ на стекоферфлоу — хороший? Надо ли искать дальше? Или подобно задаче о привередливой невесте, ищем 4 ответа и берем лучший, надеясь, что среди этих 4-х есть нужный?


Теперь про стандартные библиотеки: 99% всего что вы делаете — нет в библиотеках! Вы можете прикрутить стандартную структуру данных, или найти какой-то фреймворк, который надо как-то потыкать, и часть вашей задачи будет решена. Но практически все, что вы делаете — это решение одной частной ВАШЕЙ задачи. Магической функции "сделать хорошо" нет ни в одной библиотеке.


Это нормально понимать, что вам тут нужно сбалансированное дерево поиска, и взять готовую реализацию из библиотеки. Но если вы не знаете, что вам тут нужно именно дерево, то что вообще искать?

пусть интервьюируемый посмотрит их и скажет какое лучше и почему

Этим вы проверите лишь умение кандидата анализировать, а проверять надо как анализ, так и синтез. Из первого умения никак не следует второе.
Кстати да — это ОЧЕНЬ видно хорошо, когда человек сам делал (и шел доблестно по граблям набивая все свои шишки) и когда рядом стоял или «ключи подавал» в лучшем случае.

Поэтому мой совет соискателям — не делайте так.
«Ну ок, хотят проверить знание каких-то базовых вещей»
По-моему, родился новый мем на хабре(=
Такие задачи хороши когда нанимаешь студента без опыта с которым больше поговорить не о чем, ну или алгоритмиста.
ну или алгоритмиста.

Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.


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


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


В итоге получается, что выделенный алгоритмист должен ревьювить вообще весь код в компании. С потоком кандидатов FAANG/Яндекса эффективнее, дешевле и удобнее сразу нанимать только "алгоритмистов".


с которым больше поговорить

С "поговорить" большая проблема — это очень субъективно. Мелкой компании, где условный CTO сам проводит интервью и решает: кого брать, кого нет — это работает. В крупной типа яндекса и FAANG — уже нет. Плюс, если язык хорошо подвешен, можно тупо заболтать интервьюера в процессе этого "поговорить".

Нет, выделенный алгоритмист должен вместе с архитекторами решать как будет работать самые высоконагруженные компоненты.
А почти всегда есть не очень простой, понятный и очень эффективный наивный метод — правильно применить готовую библиотеку/фреймворк.
Плюс, если язык хорошо подвешен, можно тупо заболтать интервьюера в процессе этого «поговорить».
Без знаний особо не заболтаешь, если человек подходит ответственно к интервью: можно же спросить технические детали/особенности, да и github человека можно посмотреть.
Нет, выделенный алгоритмист должен вместе с архитекторами решать как будет работать самые высоконагруженные компоненты.

А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.

Внезапно — маркетинг провел рекламную компанию и пришли люди. Эти люди прочитали какую-то статью и пользуются системой не так как ожидали разработчики.

Ну уронит и уронит. Кто-то не сможет дошик себе через лавку заказать в моменте или реклама не прогрузится. Ой кошмар какой

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

Отвечу словами здесь https://youtu.be/NwEuRO_w8HE?t=2180 (там всего на 40 секунд вопрос и ответ). Если вас парит о-сложность до того, как вы запустили код, прогнали бенчмарки и обозначили SLA пользователям, вы занимаетесь преждевременной оптимизацией. В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку, пусть об этом парятся люди, которые контрибьютят в ядро линукса или пишут низкоуровневые системные библиотеки.

А как проверить, что человек сможет исправить найденную после запуска плохую часть?


В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит.

А потом такие "вот сайт тормозит, пользоваться невозможно!!!". Или у людей игра грузится по 10 минут на пустом месте. При чем там наверняка такая же мысль была: Ну насрать, что там в чтении одного мелкого конфига O(n^2), клиент все стерпит. А потом n, внезапно, выросло и все стало плохо.

А потом такие "вот сайт тормозит, пользоваться невозможно!!!". Или у людей игра грузится по 10 минут на пустом месте. При чем там наверняка такая же мысль была: Ну насрать, что там в чтении одного мелкого конфига O(n^2), клиент все стерпит. А потом n, внезапно, выросло и все стало плохо.

Нет, "потом" такого не будет. Вы просто взяли и пропустили фразы про бенчмарки, SLA и так далее. Если в SLA не было оговорено условное время загрузки сайта, то что там оговорено было вообще?


Просто обычно программный код имеет столько внутренних нюансов, что замена алгоритма с O(n^2) на более оптимальный может замедлить скорость работы, если это делать в слепую.


Вы игнорируете константу, вы игнорируете наиболее полулярные N и так далее.


Что лучше, что бы у большинства пользователей корзина покупок грузилось секунду, а у кого-то 5 или что бы у всех грузилась по 3 секунды?

Только и константы там одинаковые.


Обычно сделать более быстрый (асимптотически) код ничего не стоит. Классический пример который вижу в дотнете: foos.OrderBy(x => x.Something).First().Bar. Если это на старте приложения 1 раз делается или там в какой-нибудь режкой ручке — то как бы и плевать. А когда элементов достаточно много да и код выполняется довольно часто — то как бы не очень.


При том что решение — загуглить за 5 секунд любую из библиотек-расширений LINQ (либо написать свой хелпер за 5 секунд), и заменить это на foos.MinBy(x=>x.Something).Bar — почти те же буквы и те же константы, только уже за линию.

Только и константы там одинаковые.

Зависит от контекста. Всегда люблю приводить в пример перемножение матриц)


Обычно сделать более быстрый (асимптотически) код ничего не стоит.

Зависит от контекста. В вашем примере — не стоит. В каком-то случае это ухудшение читаемости и поддерживаемости кода. В каком-то случае это написание своего более оптимального велосипеда, который потом надо поддерживать.


Я не спорю, что в каких-то случаях вы просто улучшаете точность и все работает, но это явно не 100% и, скорее всего, даже не 50% случаев.

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

Обычно небольшие куски кода с медленными алгоритмами размазываются по всему программному комплексу тонким слоем. Тут линейный поиск, вместо хеш-таблицы, там ненужный вложенный цикл, увеличивающий сложность до О^2. И после некоторого количества итераций, всё просто начинает медленно работать без каких-то явных ботлнеков. И тут, зачастую, остаётся только всё переписать с нуля.

Сколько не работал с кодом, обычно существует одно место, которое тормозит больше всего, и это место отвечает за какую-то io работу в духе "сходи забери из базы что-то с кривым запросом". Переписываешь запрос и все работает :)


Даже во всяких cpu-bound задачах довольно часто спасает кеширование или исправление конкретного места.

«1. существует одно место, которое тормозит больше всего
2. Переписываешь запрос и все работает
3. goto 1»
Так лучше.

Буквально на днях столкнулся с "возросшей нагрузкой" — есть корпоративный портальчик, ничего супер-пупер нагруженного, состряпали, запустили, пользуемся… через пару лет начинаются жалобы — тормозит. Автор портальчика к тому моменту уже потерялся, полез смотреть сам (я не программист) — оказывается, при каждом действии, ajax шерстит историю сообщений, чтобы в случае чего новенького отрисовать "колокольчик", а сообщений накопилось уже немало, а в алгоритме почему-то был линейный перебор с "ручным" анализом "новое/прочитанное" (таблица ID прочитанных сообщений была у каждого пользователя своя, а таблицы сообщений шли сплошной простынёй)… казалось бы — сделай запрос к базе по JOIN с "объединением по NULL", чтобы отобрать только непрочитанные, но автор решил несколько иначе — выбирал все сообщения, а потом искал их ID в "личной" таблице, и если не находил — высвечивал оповещение.
Вроде рабочий алгоритм, но вот с масштабированием совсем боль.

Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.

Так, стоп! Это кто там такие принципы напридумывал? Те же самые люди, которые придумали триггеры и хранимые процедуры? Ок, у меня к ним есть только одно пожелание, и оно связано с адом и огнём.
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)

Ну так это ровно то же, что вы пишите. Выборка данных + расчет производных данных на их основе (преобразование функциями, сумма, вот этот весь треш).


Если вы фильтруете или преобразовываете данные потом на бекенде, то тут что-то немного не так. Иногда это ваша вина, иногда бд.

… иногда даже вина человека, который занимался выбором БД. Просто потому что колоночные БД и, например, теперь уже бесплатный кликхауз, это могут делать на порядки быстрее.
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
Потом заходишь такой в интернет-магазин (мобайл-фёрст), открываешь с мобилы список товаров, он тупит, но через минуту всё-таки подгружает всё что нужно, и наконец нажимаешь «отсортировать по ...» и обычный обывательский мобильник на snapdragon 4хх (6хх) вешается. Без шанса на спасение.

Я на самом деле очень люблю оптимизировать. Я несколько лет работал научным сотрудником в сфере, где широко использовалась wolfram mathematica. Я очень заморачивался над вещами типа сведения интеграла к сумме по элементам массива, над вставками на C, которые работали быстрее, итд. Но я это делал уже сильно после того, как написал первый прототип программы, который работал нормально, а потом захотелось больше отзывчивого UI. Я не считаю, что рядового кодера в стрессовых условиях собеса нужно мучать на оптимальные алгоритмы. Для этого давно есть библиотеки и только в редких случаях возникнет реально проблемный боттлнек, где придётся оптимизировать код. Если такое случится — ну, ок, сядет разраб и в спокойной обстановке поищет, в чём там проблема.

Почему сразу не думать в категориях нормального кода? Второй раз может и не захотеться переписывать, жалко времени, кончились деньги и т.д.
Типа, сначала строим дом, потом смотрим, что получилось неплохо, но нужно сделать канализацию, затем снова поднимаем краном и прокладываем водопровод. Разматываем электрические провода вокруг дома, снимаем обои и начинаем штробить стены.
Говорят, code is clay, имея в виду, что код обычно не надо переделывать заново, как какую-нибудь шестеренку, если в процессе изготовления допущена ошибка. Чаще всего изменение обходится малой кровью.
Так и в исправлении неправильного ремонта ничего «слоного» нет. Проштробил стену, потом обратно замазал.

При строитенльстве домов теже проблемы, только в меньшем масштабе. Возьмите типичную квартиру и посмотрите как расположены там розетки, используются ли вские тройники и удлинители. А ведь это все можно было решить на этапе ремонта. Вот только для этого нужно точно знать где какая мебель будет стоять, какие у неё будут размеры, какие электроприборы и где будут стоять и использоваться. Точно это предугадать невозможно, поэтому и возникают все эти удлинители или абсурдно огромные группы розеток "на всякий случай".


Так же и в разработке софта. Мы зачастую не знаем сколько у нас будет пользователей конкретной фичи, не знаем какие фичи будут добавлены завтра, а какие убраны. Мы даже не знаем кто будет завтра с этим кодом работать. То что мы знаем точно — так это то что проект точно будет меняться или умрет. Но что именно будет меняться — можно лишь гадать. И правильно угадывать мы будем далеко не всегда. Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем, пытаться предсказать что может поменяться, а что нет. А еще, чтобы его могли понять другие разработчики, желательно без необходимости вникания во всю историю проекта. Хороше же оптимизированный код зачастую сложно читать, сложно расширять. В итоге приходится балансировать между расширяемостью, читаемостью и оптимизацией. Хороший разработчик — не тот кто упарывается в одну из этих крайностей, а тот, кто умеет находить баланс в каждом конкретном случае. Когда надо — писать хорошо оптимизированный write only код, а когда надо — медленный, но легкочитаемый и/или легкомодифицируемый, а в большинсте случаев — что-то среднее.

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

Это только если упарываться микрооптимизациями. Если просто использовать нормальный алгоритм или структуру данных — то код часто даже проще и понятнее. Что легче — полный перебор через рекурсивную функцию с откатами и неочевидными отсечениями, или динамическое программирование, которое все — 2 вложенных цикла и тривиальная формула для пересчета одной ячейки массива через соседние?

Осталось только найти границу где "просто использовать нормальный алгоритм или структуру данных" переходит в "упарываться микрооптимизациями".

Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем,

Спасибо, вы меня поняли. Заморочиться и написать fast inverse square root всегда можно потом.

Справедливости ради стоит заметить, что если подходить к ремонту серьезно, то уже после второго ремонта (в смысле, при планировании третьего) не будет ни лишних розеток, ни удлинителей. Это если себе делать.
Если же Вы прораб и делаете ремонт «другим», то тут грубо говоря два варианта: 1) прораб м###к не является профессионалом и без комментариев и продолжений выполняет требования по количеству розеток заказчика; 2) даже небольшого жизненного опыта достаточно, чтобы вовремя спросить «а робот-пылесос где парковаться будет?»/«а в шкафу подсветки не будет что-ли?»/«думаете на вашу столешницу больше двух электроприборов за раз поместиться?»/«ну это новая зубная щетка заряд держит, а потом как вы ещё заряжать будете, когда тут бритва на зарядке и фен нужен?»

Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…
Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…

это вы как выяснили?
Опыт показывает, что нет ничего более постоянного, чем временное.
Рефакторинг отнимает кучу ресурсов, больше, чем было бы потрачено на изначально грамотное проектирование. В конечном итоге рефакторинг откладывается до лучших времен, баги митигируются костылями, мейнтенанс и дев луп растут.
заходишь такой в интернет-магазин… и обычный обывательский мобильник вешается.
Зашёл я как-то на один технический новостной сайт с обычного пользовательского мобильника…
Впрочем, ходят слухи, что уже ведётся работа над новым движком для комментариев, и к осени он будет готов. К какой осени — источник умалчивает.
Что там телефон — у меня ноут еле тянет.
Это вы так лихо Хабр новостным ресурсом обозвали или я чёт не понял?

С возможностью комментирования и элементами социальной сети)

Можно подумать это не так. Нормальных технических статей практически нет.
В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку

Браузер стерпит. Пользователь может и не стерпеть.

Не смог удержаться...
image
Или все такси в России на час перестанет работать. Остальные нагрузку не тянут, и ложатся под ней.

И как такси без Яндекса работало сотни лет? Пришел случайный Джун, отсортировал массив пузырьком и нагнул отрасль, ну да

И как люди без интернета сотни лет жили?
И как люди без электричества сотни лет жили?

Раньше работало, плохо но работало. Сейчас если Яндекс падает такси в России перестает работать. Надо теперь с этим жить.

А конкуренты куда делись?

Нагрузку не тянут.
В прошлом году полдня Яндекс такси лежало, все конкуренты легли под нагрузкой сразу же.

https://habr.com/ru/news/t/487130
При этом сервисы Яндекса и так регулярно падают. В Яндекс.коннект или в метрике или в Яндекс Недвижимости регулярно натыкаюсь на «ваш запрос не может быть выполнен», на несохранение каких-либо действий или просто на неверную выдачу.

И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.

Никто не гоняет нагрузочне тестирование по всем апишкам после каждого релиза.
Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.

Критический путь можно так проверять. И иногда проверяют. Но это даже близко не все методы.
Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.

Не согласен с вами.
Мы поддерживали целый стенд для людей, занимающихся автоматизацией нагрузочного тестирования. Биллинг.
Нагрузочное тестирование — чрезвычайно нетривиальная вещь, особенно для stateful сервиса. В больших компаниях за этим стоят отдельные сервисы со своими командами. И то даже в Яндексе и FAANG'е это далеко не для любого сервиса отлажено хорошо. Не панацея, в общем.
упадёт потому что NPE, и тут никакой алгоритмист не поможет ))

А вы не пишите на языках с null-ами

А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.
Я ведь верно понимаю, что любой алгоритмист, при устройстве на работу, гарантирует своему работодателю некий аналог sla с несколькими девятками, и полной компенсацией в случае падения прода? Или алгоритмисты только говорить могут, а на деле роняют прод примерно так же часто, как и обычные инженеры?
А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.

Если он сделан прям «так жутко», то он просто код ревью не пройдет.
Хочется верить.
Всегда есть вероятность что какой-то код написали в тестах. А кто же внимательно ревьюит тесты?
Потом этот же код скопировали в метод нужный в админке. Кто же внимательно ревьют скопированный код на который не будет нагрузки и пользователи все свои?
А потом его вызвали из любого пользовательского метода на который не должно быть нагрузки. Кто же внимательно ревьют не тот код что написан только что, а какой-то там метод? Тем более нагрузки же нет.

А потом пришла нагрузка. И все легло. И никто не виноват.
Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.

Под "алгоритмистами" чаще всего понимают рисерч-инженеров… давайте расскажите, как компаниям не нужен R&D и все можно порешать на уровне понимания "сейчас пройдемся по списку и сложим два числа"...

Судя по контексту ("алгоритмические" задачки на интервью) тут под "алгоритмистами" вполне себе подразумеваются обычные программисты, которые умеют в структуры данных, О-большое и всякие алгоритмы.

Будто бы база для алгоритмиста чем-то отличается. Вопрос в глубине экспертизы и решаемых задачах.

ну или алгоритмиста

Выделенный алгоритмист не нужен.
У нас был проект, где были выделенные аналитики для увеличения производительности (прям такие математики-предметники). Которые в код реально не лазили.

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

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

В смысле копия? Это вы так резко опустили всех разработчиков FAANG?
Если же вы имеете в виду, что копия в плане собеседований, то флаг им в руки. Зачем нужно проходить это все в Яндекс, когда можно то же самое все пройти в любую из FAANG?
А зачем, например, уежать работать за границу, когда можно не уежать? А зачем вообще что-то делать, когда можно не делать? Таким вопросом можно много чего обесценить.
Все люди разные. Кто-то захочет в Я. работать, кто-то в FAANG захочет. Статьи «какие в Я. глупые алгоритмические собеседования» пишутся время от времени, но даже сейчас, конкретно в этой статье, в опроснике есть люди, которые всё равно выбрали бы Я.

А что не так? В Яндексе нет настолько умных людей как в FAANG? Или они не делают нормальные сервисы?

В Яндексе нет настолько умных людей как в FAANG?
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.

Или они не делают нормальные сервисы?
Ну, не знаю, огромная доля сервисов Яндекса со стороны кажется банальным симптомом болезни «а во. такая штука появилась на рынке, значит, надо делать свой клон». Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
Его уже несколько лет убивают, по другому описать не могу.

А ведь какая стюардесса была...

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

Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
Ну, так сказать, вот они — крутые олимпиадники в действии
негативных отзывов на поведение контор из избранного списка

Чего чего сделали?

Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
Ну, так сказать, вот они — крутые олимпиадники в действии…

Ой это действительно боль, все еще пользуюсь яндексом по инерции, но заставить его найти именно то что я хотел а не то что он выдумал, это тот еще квест. Особенно весело, учитывая что я работаю с вещами по которым 1.5 статьи и из них одна на английском. Все чаще открываю гугл или утку.
Чего чего сделали?
Для тех, кто доставляет через яндекс (покупка на маркете) — отзыв сделать нельзя, только метрики яндекса как шустро те доставляют и сколько возвратов. Что гарантия будет хз где, а магазин будет всячески пытаться тебя обмануть — ты уже отписать не сможешь…
Если контора отдельно оставила возможность покупать у неё миную яндекс, то там отзывы есть и много всяких в духе «кинули с заказом, отменив оплаченный», «ради гарантии пришлось переться в жопу мира несколько раз» и т.п.
PS. И да, это я виноват. Наехал на яндекс за то, что их «проверенные поставщики» (то, что было ДО этого изменения) массово кидали перед нг народ, отменяя даже оплаченные заказы. Вот, олимпиадники в яндексе решили проблему — нет отзывов, нет возможности доказать, что их проверенные поставщики так делают
Вот это жесть и как интересно можно было додуматься до такого.

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

Ну а причина в подобных отзывах, которые не к лицу тем, с кем работает яндекс и кому вешает плашечки «проверенных поставщиков». А у тех, кто не доставляет через яндекс.покупки отзывы и звёзды так и остались снизу под названиями.
PS. Кстати, очень интересно, что никто из отписавшихся яндексоидов в такие ветки не заглядывает. Им явно нечего ответить на такие вопросы про передовую техническую компанию
Вот это жесть, это же постараться надо чтобы ТАК работать. А по задумке яндекса можно просто уйти к ним в партнеры и такого никто никогда не увидет? Прикольно.

Ну ок, значит будем людям объяснять что на я.маркете отзывы смотреть нельзя, пусть фламп развивают.
Так я и говорю, уже несколько лет яндекс начал бороться с пользователями. В связи с чем ушёл с стринг, поиск разнообразил другими, цену ищу на екталоге, в вебверсию почты не захожу (только сторонние клиенты, в том числе на смартфоне). С ужасом жду, что они сделают с яндекс.метро на смартфонах, нафигатор уже снёс в пользу карт, да и то чаще в 2гис на месте бегаю. Гоу с момента переименовывания ни разу не юзал.
А ведь была такая удобная и хорошая экосистема, блин
Курс на это можно было предположить уже тогда, когда вместо покупной картосновы они стали разрабатывать собственную путем покупки конторы, нанимающей пионеров для рисования по спутниковым снимкам, и когда в сервисах погоды и отслеживания общественного транспорта стали алгоритмически дорисовывать несуществующие данные.
Не то чтобы я хочу сказать, что это именно вина олимпиадников, но олимпиадники — такой народ, который скорее будет беспокоиться больше об алгоритмах и меньше — о, гхм, поворачивании к клиенту задницей. В этом смысле, они — идеальные исполнители для таких начальников.
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.

С чего бы это? В сам FAANG конечно больше кандидатов, но вот и мест там значительно больше.
При этом для выпускников местных топовых вузов, как мне объяснял один знакомый из Долины, пойти в Гугл, это не как для москвича после МГУ / МФТИ пойти в Яндекс. Скорее как для москвича пойти в какой-нибудь банк, разгребать несвежее легаси, поскольку местные успешные разработчики стараются идти в стартапы за долей в компании.
В стартапы, доля которых уже осязаемо чего-нибудь стоит, а не может быть будет стоить через Х лет при лучшем раскладе, отбор и конкуренция строже, чем и в фаангах, и в яндексе, при прочих равных.

А ещё планета не выглядит как «Россия и Долина», между делом. :)
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.

Среднее по больнице на то и среднее, что на больших числах размеры конторы перестают влиять на средний IQ там работающих. )

ps Советую не обожествлять фаанг. Судя по рассказам, локального бардака и бюрократии там куда как больше.
Божественный? Да он был таким пару лет назад, пока из него магазин не догадались сделать. Теперь в нём нет сортировки по цене и отзывы обо всех модификациях фигачат в одну позицию.
т.е. вы считаете, что что и крупнейшие западные топовые компании и создатели литкода, да и наверное все вокруг идиоты?) и только вы один светоч знаний
Крупнейшие западные компании заигрались в литкод, потому что не в состоянии придумать нормальный процесс, адекватно оценивающий кандидатов. И да, там тоже работают люди, а не боги, и они тоже ошибаются. Так же как они раньше в Гугле спрашивали «сколько теннисных мячиков помещается в боинг 737?» и все, как обезьяны, за ними повторяли. Потом признали, что подобные вопросы — идиотизм. Так и сейчас, Гугл на собеседованиях спрашивает всё меньше литкода, а больше более приземлённых, более адекватных для будущей позиции, задач. Так же как и с мячиками, пройдёт лет 10 и слоупоки-подражатели типа Яндекса тоже сменят пластинку и начнут подражать новым веяниям из Кремниевой Долины
Согласен — хорошо вести бизнес, хорошо создавать продукт, хорошо собеседовать кандидатов, хорошо <что-то еще> — это совершенно разные задачи.
С топовыми компаниями тут ошибка выжившего — не они топовые по тому что у них эффективная система найма сотрудников, а неэффективная система найма сотрудников не мешает им процветать потому что они топовые (много денег и многие хотят там работать).
пройдёт лет 10 и слоупоки-подражатели типа Яндекса тоже сменят пластинку и начнут подражать новым веяниям из Кремниевой Долины

А мне кажется, что они не слоупоки и совсем не подражатели. Просто «отличники» или около того, в большинстве своем. Ну привыкли просто так со школьной скамьи… по другому не умеют. Им бы, наоборот, поучиться у гугла с майкрософтом или у других, более адекватных к собесам российских контор. Вон ниже Emil983 о них [google/ms] рассказывает.

Я уже раза три за последние 15 лет, устраивался в подобных топик-стартеру условиях в топовые компании. Слава богу, попадались адекватные интервьюеры и будущие коллеги. Работа-то далеко не из задачек на классические алгоритмы состоит. )
Поправлю: Яндекс в этом смысле повторяет не за условным Гуглом, а за самим собой во времена первичного расцвета. А сейчас это превратилось в культ карго.
НЛО прилетело и опубликовало эту надпись здесь
Я думаю, правильный ответ — это как-то адекватно порассуждать на тему, прикинуть. Ну ошибешься на пару порядков, думаю, оценивать будут не это.
Ни одного — у него люки закрыты! (не знаю)
Так в Яндексе никто про тенисные мячики не спрашивает. А почему вы решили, что задаваемые задачи не имеют практического применения в Яндексе? Вы там работали или хорошо знаете как работают в компании? Я вообще не понимаю такого негодования. Не нравится процесс собеседования, ну так не ходите на них в подобные компании. Почему вы считаете, что процесс правильного собеседования может быть только 1, а все другое ложно?
Спрашивали, спрашивали про мячики. Ещё году в 2007, когда это и в гугле могло сойти за новинку. Ну и, собственно, да — в общем, вряд ли я в Яндекс пойду. В прошлый раз пока их рекрутёр расщедрился договориться о собеседовании, у меня уже другой оффер был. И не один.
Бред. Собеседовался в MS на Software Engineer и дважды в гугл на Software Engineer Manager за последние 3 года. В MS никаких тупых задач для студентов не было, были задачи приближенные к реальному миру и после их решения каждый раз говорили (ну вот примерно вот так у нас хранение прав устроено), в гугле аналогично: только одно собеседование по кодингу из 5 такое на «базовые вещи» и то это не просто «покажи дао алгоритмов» а вот тебе интересная задачи и реши её, а потом мы обсудим её сложность и как можно улучшить.

А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
Бред. Собеседовался в MS на Software Engineer и дважды в гугл на Software Engineer Manager за последние 3 года. В MS никаких тупых задач для студентов не было, были задачи приближенные к реальному миру и после их решения каждый раз говорили (ну вот примерно вот так у нас хранение прав устроено), в гугле аналогично

В каком году вы проходили собеседования? Я выше написал, что гугл (ну ни наверное остальные ФААНГи) уже осознали идиотизм литкода и задают более адекватные задачи. Но мелкие подражатели продолжают тупо долбить литкодовские задачи. Особенно если бывший инженер гугла уходит в другую контору и там все на него молятся, он будет ещё лет 15 применять (давно устаревшие) гугловские практики на новом месте. Я недаром про мячики вспомнил — буквально на прошлой неделе на собеседовании в Verizon был задан вопрос «как взвесить школьный автобус». Угадайте кто его спросил? Правильно, менеджер, который 12 лет сидит в Verizon, а до этого работал в гугле
Проходил/прохожу в 2021, 2020, 2019. в 2019м в MS оставшееся время беседовали об этом с одним из интервьюеров и он посмеялся над этим тоже, сказал что такие задачи они давно дают только людям без опыта, читай студентам, у которых-то и спросить больше нечего. Согласен, есть и люди которые бездумно перенимают то что они считают лучшим. Даже на логику есть куда более адекватные задачи.
Ну я вот собеседования в прошлом году в Фейсбук и в этом в Амазон. Задачи, внезапно, с литкода.
Окей, в Гугле на первой итерации попросили сдизайнить шедулер тасков, не совсем типичная с литкода, но такие там тоже есть.
Аналогично, в 2020-м Гугл, Фейсбук и Амазон спрашивали алгоритмические задачки. Это при том, что в Гугл, например, требовался формошлеп на ангуляре.
Не, не эта — надо сделать возможность выполнить коллбек через Х времени в будущем. И чтобы была возможность отмены.
Типа надо сделать 2 метода
TaskId enque(Task task, Time time);
void cancel(TaskId taskId);

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

Вообще, стандартное решение этой задачи — с использованием priority_queue.


В очереди хранится пара {время, TaskId}, упорядоченная по минимуму времени. Еще нужен map TaskId->время. При enqueue создается новая задача и помещается в очередь. При cancel соответствующая запись из очереди удаляется.


Не надо даже писать очередь, можно использовать stl-овскую, например. Правда, могут спросить, а представляете ли вы как эта структура данных работает.


Другой поток просыпается при любом enqueue или по таймеру. При просыпании он смотрит, пора ли выполнять следующую задачу и выполняет ее. Если рано — ставит таймер до следующей задачи.


По-моему, при написании от кандидата не требуют знаний системных вызовов для таймеров, событий и потоков. Обертки над всем этим и так есть в любой большой компании. Достаточно сказать: ну пусть у нас есть Event, у которого есть метод Wait(timeout), который усыпляет поток, пока не выйдет таймаут или кто-то не вызовет у этого объекта метод signal. Тут интервьюер может даже подсказать, если только кандидат скажет, что надо усыплять потоки. Если кандидат знает про select — это плюс.


Потом могут быть дополнительные вопросы, а что делать, если какая-то задача выполняется дольше, чем дедлайн до следующей? (запускать следующую сразу и не засыпать). Можно ли выполнять задачи в несколько потоков? (можно. Один поток все так же спит, отсчитывает таймеры и работает с очередью, а другие спят пока не получат задание на выполнение).


Еще надо помнить про всякие крайние случаи — типа enque задачи в прошлом времени.


Колеса времени

В очереди хранится пара {время, TaskId}, упорядоченная по минимуму времени. Еще нужен map TaskId->время. При enqueue создается новая задача и помещается в очередь. При cancel соответствующая запись из очереди удаляется.

Тогда уж нужно TaskId -> Node, чтобы можно было из очереди за О(1) удалить, иначе для удаление задачи с конца нужно долго и упорно пёхать по всей очереди (если она в виде связного списка реализована).

Из priority_queue за время О(1) удалить не получится. По крайней мере, если это priority_queue на основе "пирамиды".


Хотя если брать "в среднем", то да, О(1) и выходит… Но в любом случае для нужно время, а не Node.
Впрочем, если есть Node, то его можно не удалить, а "задизаблить".

Еще можно std::set использовать в качестве очереди.

А откуда у вас данные у Гугле?
Я собеседующий в Гугл. За последние пару лет в процессе собеседования не поменялось принципиально ничего. Те же задачи, похожие на литкод. Да, хорошим тоном считается завернуть их в обёртку реального мира. Например, не строку ААААВВВ преобразовать в А4В3, а что-то, что вы военный радист и получаете донесения с передовой для дальнейшей передачи в штаб. Вам надо раз в день собранный поток сообщений как-то уменьшить в объёме, но сохранить порядок. Ещё известно, что часто подряд приходит много однотипных сообщений. Вопрос — как будете преобразовывать? Тут с помощью интервьюера дойдёте до исходного условия и дальше напишете тот же алгоритм (ну или не напишете).
многие знакомые/друзья собеседовались и делились опытом и задачками. Последний вот месяц назад собеседовался, сказал что очень вменяемые практические задачи были, непохожие на литкод. Я именно в гугл даже не пробую, ничего плохого не имею против таких контор, но я по жизни не бегу туда куда все бегут :) Надеюсь мой стартап взлетит и в итоге получится даже больше чем обычно в фаангах зарабатывают :)
И придется уже вам задавать соискателям задачки :)
В 2008 году в Яндексе такого алгоритмического маразма на собеседовании не было. Да, алгоритмы были, но не в таком количестве, и с очень хорошей привязкой к внутренней механике Яндекс-поиска.

P.S. я — бывший сотрудник.

Нет, они довели до абсурда худшие практики, которые в FAANG постепенно уходят из повестки собеседований.


Несколько лет назад, когда я проходил свои 4 собеседования в Яндекс, они всё же были другими. Там про архитектуру и проектирование систем спрашивали, про устройство Linux, распределённые системы и т.п. интересные вещи. А то, о чём написал автор — это квинтэссенция идиотизма. Бессмысленная трата времени и очень плохой алгоритм фильтрации и проверки кандидатов.

В начале собеседования с Гуглом, вас потребуют подписать NDA, что ни какие подробности интервью вы не можете разглашать. Какие последствия? Наверное через суд, заставят оплатить издержки, например, потратили время на 1000 кандидатов, которые уже знали заранее ответы, или оплатить 100 часов на переделку всех контрольных билетов. :-)

Ну ок, пусть оплачивают время собеседника через временный контракт с доступом к коммерческой тайне.
В России это так не работает, даже для работника оформить коммерческую тайну тот ещё квест. В США не знаю, может, с этим намного хуже.
Собеседовался в Гугл в Цюрихе — ничего подписывать не просили.
Какие были задачи?
Например, найти через сколько рукопожатий знакомы два человека в большой социальной сети типа G+.
двунаправленный поиск в ширину?
Похоже, но я не знаю точного ответа. Я рассуждал про разные датацентры и репликацию данных, не знаю насколько это было нужно.
У кандидата в Google есть возможность отказаться от подписания NDA, при этом собеседование все равно происходит, просто на беджике появляется красная клякса «NO NDA».
Ему дают другие задачи или просто не особо откровенничают?
Не откровенничают на этапе, когда можно задавать вопросы про Google.
Все подробности интервью давно есть в комментах на Glassdoor, «ищущий — да обрящет»
common = set(a).intersection(set(b))  # найдём общие элементы
for el in common:
    occurs = min(a.count(el), b.count(el))  # и посчитаем, сколько они встречаются

Простите, не смог пройти мимо. Если a и b — один и тот же набор из 1000 различных чисел, то эта программа пройдет по каждому из списков по 1001 разу. Получится пара миллионов сравнений и прибавлений счётчиков. Короче получилось O(n²).

Ага, сам знаю. Но именно так я и написал бы в проде. Это легко читается, достаточно быстро на небольшом количестве элементов (а сколько их обычно будет в реале, 10-20?), легко пофиксить, если станет боттленеком. Preliminary optimization — зло, как по мне.

если бы можно было весь collections юзать, то я бы такой варик предложил:
list((Counter([1, 2, 3, 2, 0]) & Counter([5, 1, 2, 7, 3, 2])).elements())


правда не знаю какое тут О
O(n) для конструкторов Counter, O(n) для операции перечечения, O(n) для получения элементов и O(n) для конструктора списка. Итого O(n).
так что получается, чтобы не позориться с N^2 придется либо дерево писать либо хеш таблицу

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


Ну, на худой конец, можно отсортировать и слить 2 списка. Будет O(n log n) вместо O(n). Если сказать, что можно и хештаблицей, но я боюсь, что не напишу ее за интервью.

Если числа маленькие по модулю, то можно их как индекс массива использовать (и хеш таблицу не писать), а если большие, то сортировать мердж сортом?

Сортировать можно чем угодно. А потом в двух отсортированных списках можно найти общие элементы двумя указателями также, как делается операция слияния.

))\n — скобки закрывать надо!

Dawson’s first law of computing: O(n^2) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall down once it gets there.


https://randomascii.wordpress.com/2021/02/16/arranging-invisible-icons-in-quadratic-time

Я разок такое написал, а потом процесс в проде видел по много часов там, где после оптимизации справлялся за 10 минут.
а сколько их обычно будет в реале, 10-20?

20 уже много. Вот если 3-5. Причём нужно очень хорошо понимать, какие реальные объёмы могут встретиться на проекте. Не только самые типовые. А то потом получится как на gitlab-е, или ikea. На gitlab-е открываешь большой MR и оно едва ворочается. Или вот в ikea видимо тоже примерно так подумали — сколько человек товаров может заказать? 5? 10? Нормааально. Заказываем 14 и страница зависает на любое действие на секунды.


Не шутите с квадратами. Мы, программисты, очень часто далеки в своих оценках от реальности.


P.S. а ещё всякие катастрофические regexp-ы, убивающие поток на минуты попадись им строка чуть длиннее обычного.

Или вот в ikea видимо тоже примерно так подумали — сколько человек товаров может заказать? 5? 10? Нормааально. Заказываем 14 и страница зависает на любое действие на секунды.

Ситуации вида "ваш сайт дико тормозит" в коде вполне могут быть выражены ситуацией "наш код прекрасен и работает за O(1). Тормозит что-то? Ну, это проблема не на нашей стороне, а какой-нибудь там реакт редакс браузер виноват, но не мы (с)". Это, опять же — тоже реальный личный опыт из разгребания не вполне рабочих фронтовых проектов, созданных руками чудо-алгоритмистов.


Скажем, уже больше 10 лет назад меня попросили "оживить" проект-презенташку очень важных данных в виде таблички, где у чудо-алгоритмистов, написавших чудо-бэкэнд, вдруг возникли сложности с презентованием результатов. Я пришел, увидел код, который на примерно любое действие пользователя собирал огромнейшую строку (всю страницу вместе с большой-пребольшой таблицей в основе) и фигачил её в корневой элемент презенташки через innerHTML. Когда я немного пришел в себя и поинтересовался, как такое вообще могло появиться — мне было сказано, что тут всё реализовано через минимальную алгоритмическую сложность O(n), и это всё так и надо и правильно. А что тормозит (браузеры немного выпадали в осадок и потребление памяти дико скакало, с ожидаемыми тормозами в моменты, когда она вся выжиралась) — так это просто браузеры плохие. И вообще этот ваш веб новомодный отстой.

Я ни разу не спорю с тем, что базовые алгоритмы это только один из многих необходимых навыков :)

собирал огромнейшую строку (всю страницу вместе с большой-пребольшой таблицей в основе) и фигачил её в корневой элемент презенташки через innerHTML
Так дело именно в том, что это были не алгоритмисты, а ровно наоборот — люди, не имеющие представления об алгоритмической сложности. Уж алгоритмисты-то обязательно для начала поинтересовались бы, каково это — добавить здоровенное поддерево в dom. Сделали это как раз те, кто говорит и пишет в каждой подобной теме, как же это тупо — проверять кандидата на понимание алгоритмической сложности. Самому регулярно приходилось и приходится ликвидировать последствия подобного кода. А все потому, что люди даже не видят, не замечают, не понимают, что они на самом деле постоянно сталкиваются с оценкой сложности в повседневных задачах, вот о чем важно говорить.
Ну, использовать готовые библиотеки (нумпу какую-нибудь) умеют математики, физики и химики, в чем ваша ценность как программиста-то? Чем вы лучше девочки с химфака которая освоила пару питоновских библиотек и хреначит код для своих исследований? Почему должны нанять вас, а не ее?
Почему нужно брать инженера, а не физика, чтобы разрабатывал трансмиссию для автомобиля?

Инженерное искусство состоит в умении хорошо скомпоновать готовые решения, сделать конечный продукт поддерживаемым и простым в расширении, а так же в умении видеть необходимость оптимизации, когда нужно делать что-то новое. Если готового решения не существует, пойти и разработать свое собственное. Если не хватает экспертизы — посоветоваться с кем-то.
Потому что её нет на собеседовании, а остальные кандидаты ещё хуже.
Так мой поинт обратный — вот к вам на собеседование пришли химичка, физик, математик и автор поста, которые освоили использование itertools. Как выбрать одного из них на вакансию? Ну например, можно взять того, кто в дополнение к itertools знает про О-нотацию. Можно еще по цвету глаз или галстука выбирать (я про такое в том же Гугле слышал). Вам что лучше, угадать цвет галстука (удачи) или за 15 минут прочитать статью на вики про О-нотацию?
Вам что лучше, угадать цвет галстука (удачи) или за 15 минут прочитать статью на вики про О-нотацию?

Как по мне, лучше завести гитхаб и порешать задачки хоть с того же литкода, нежели чем пытаться проскочить на позицию, для которой у меня не хватает знаний, чтобы потом с треском пролететь на испытательном сроке.
Я комментарием выше достаточно емко показал, что ваш поинт — абсурд, но вы проигнорировали. Ясно-понятно.
Вы привели пример, когда от «инженера» требуется, скажем, умение крутить гайки. Я не инженер, но гайки крутить умею. Как понять, что я инженер, а не токарь Вася с завода? Мы оба умеем крутить гайки.
Вы описали какие-то абстрактные требования, вопрос-то в том — КАК понять, что кандидат ими обладает? Я встречал кучу кандидатов (в тч когда побеседовал работников Яндекса в других конторах), которые молоть языком горазды — и расскажут как они сделали «конечный продукт поддерживаемым и простым в расширении» и что у них есть «умение видеть необходимость оптимизации, когда нужно делать что-то новое», но вот беда — hello world написать не могут. Как отсеять болтунов?
> от «инженера» требуется, скажем, умение крутить гайки.
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.

> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.

> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
> Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше

Ну вот я общался с кандидатами — красиво стелят, якобы делали то, сё, пятое, десятое, а hello world написать не могут. Что с такими делать? Поверить на слово что он реально это делал? Тогда почему не может hello world написать? Или включить презумпцию виновности и решить что он балабол и просто сидел на зарплате глядя как другие вот это все описанное делают, а сам JSONы два года перекладывал?

> Как отсеять болтуна-физика, прикидывающегося инженером?
Я не знаю, вы мне скажите=) Для программистов вот есть задачки с литкода — если человек потратил недельку на подготовку к собесу, он их решит. Если не потратил — то точно ли он хочет новую работу или просто так с улицы зашел? Как быть для инженеров — хз, не моя тематика.
> Как быть для инженеров — хз, не моя тематика
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.

Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.

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

Всё же механика часть физики.

Как хорошие собеседующие отличают опытного специалиста от специалиста разговорного жанра?
А раньше как отличали? Беседой. И никто не умирал при этом, и кандидаты успешно находились. Как же это как, интересно? Потому что это было собеседование, а не вступительный экзамен, как сейчас. Но да, собеседование в таком режиме требует от интервьювера соответствующих навыков и опыта, а не сравнивания ответов задач.
Посмотреть гитхаб? У некоторых там вполне красноречивые доказательства, почему их (не) надо брать на работу.
Я тот самый человек, который стелит, делает и пишет, но на собеседовании не может hello world. Вот такое у меня свойство организма, я предполагаю что глубокая травма экзаменами в институтах. За 15 лет опыта я прошел сотни собеседований, могу довольно складно рассказывать о прошлых проектах и достижениях, честно рассказывать, без вранья, но как только начинается разговор о том чтобы под строгим взглядом экзаменатора собеседующего деревья разворачивать и списки склеивать, я тут-же выключаюсь, мямлю, в голове включается гифка с обезьянкой с литаврами, и я не могу вспомнить как правильно переменные объявлять. Вот так вот я устроен, если дать мне проблему, комп в темном углу, и отстать, я напишу работающий код. Если встать у меня за плечом и смотреть, я напишу ровным счетом ничего. И я такой не один, нас таких достаточно много.
И я такой не один, нас таких достаточно много.

В абсолютных цифрах — возможно. А в потоке людей — очень и очень мало. Ну представьте себе что человек проходит какие-нибудь 3-недельные курсы на ютубе, его научили правильно отвечать на "что такое солид" и какие-нибудь киты ООП, но он реально не программист, а какой-нибудь дворник который попал на таргетированную рекламу "заработай 100500 на ~~джойказино ~~яндексе".


И вот на одного такого вас 19 вот таких фот "типа программистов".
Если в маленькой компании с вами могут нормально поговорить по душам и распознать одно от другого (это не трудно, если уделить достаточно времени) — то в компании "на потоке" кроме как собсвтенно попросить кодить это не проверить.

А у вас есть источник этой статистики? А то у меня вот опыт исключительно личный, и за 15 лет опыта работы в различных больших и маленьких компаниях, проведения и прохождения собеседований, тех кого вы описываете видел только на джун вакансиях (куда им, собственно, и место), а вот таких как я навидался до черта.
А вот ужастиков через третьи руки слышал, да, вот только ни разу не видел подтверждений, сколько не спрашивал

Увы, тоже пример личный. Один человек вообще себя искренне называл "Аватар тестирования" (я иногда принимаю участие в собеседовании QA, рассказываю про архитектуру и прочие вопросы по компании с точки зрения разработки).


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

Я заметил, что у меня курса с 3-го — 4-го тоже появилась такая проблема. Хотя в школе без проблем решал на доске различные задачи. К счастью хороших предложений сейчас много. Можно позволить себе отсеять компании с кодингом на интервью.
+1 почти ровно такая же ситуация. Путаю синтаксис for в php и js, просто потому, что IDE сама подставляет нужный уже когда напечатаешь «for», остаётся только нужные имена переменных подставить, в результате код на собесе может не заработать тупо потому что где-то поставил запятую вместо точки-запятой.
Путаю синтаксис for в php и js

Так он же абсолютно одинаковый, кроме требования знака $ в PHP. Вы с forEach не путаете?
Да, скорее с forEach, вы правы
Эти собеседования нужны как раз для отсечения людей, которые мало того, что не привыкли работать с оглядкой на миллионы запросов в секунду (потому что «ну сколько реально запросов может быть-то?»), но и не понимают, что иногда размер данных больше, чем цифр в их номере телефона. А, ну и забыл мантру: «стандартная библиотека реализована эффективно, её можно использовать в любых высоконагруженных системах» (нет)
Это очень-очень плохой подход — сразу видеть квадратичную сложность и, имея ввиду лёгкий фикс, всё равно уповать на «может быть срастётся»
Вот тут человек тоже плюс минус того же разлива и количества задачи решал часами на пролет, на стажера… Мне кажется им все равно какая позиция, главное с хорошим человеком порешать задачки! -)
Последняя задача прям детская по градации литкода (который тебе не зря посоветовали)
А у этой задачи есть решение, кроме полного перебора?

Если числа не очень большие по модулю — то динамическое программирование, как в задаче о рюкзаке. Будет решение за O(n*M), где M — сумма всех чисел по модулю.


Если числа — любые инты, то только пере