Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 1283
Стиль изложения — огонь. Жду продолжения истории
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
Бедные курьеры...
Не курьеры, а коммивояжеры.
И решали задачу о рюкзаке?
Это та же задача, что и о коммивояжерах
Коммивояжёр решает рюкзак, наоборот нет.
Авторитетно, как яндекс-курьер получивший оффер, заявляю.
ПС
: sarcasm:
Авторитетно, как яндекс-курьер получивший оффер, заявляю.
ПС
: sarcasm:
Я не настоящий сварщик, я маску нашёл, но насколько я понимаю, под словами "задача коммивояжёра" и "задача о рюкзаке" могут подразумеваться несколько разные вещи, в том числе NP-полные задачи, так что сведение одной к другой неочевидно в таком простом заявлении, как ваше :)
вы слишком многого хотите от курьера яндекс-яды.
Но если брать формулировку по «knapsack problem» и «travelling salesman problem» в английской вики — то я не вижу как решение второго свести к решению первого (без многократного повторения или увеличения размерности задачи).
Но если брать формулировку по «knapsack problem» и «travelling salesman problem» в английской вики — то я не вижу как решение второго свести к решению первого (без многократного повторения или увеличения размерности задачи).
Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)
Руку на отсечение не дам, но вроде бы, в обоих случаях задачи разрешимости NP-полны, и не всегда ясно, когда говорят просто про рюкзак (коммивояжёра), имеются ли в виду оптимизационные задачи или речь про разрешимость.
Насколько я вижу по вики (да и всегда думал) — задачи имеют разное название потому что это разные задачи. Там где задачи явно сводятся к другим обычно это пишут, например тут
The knapsack problem is a generalization of subset-sum.
Если не пишут значится что не сводится одно к другому
NP-полнота как раз и означает «любая NP-задача сводится к этой».
Рюкзак и коммивояжёр оба NP-полные, значит оба сводятся друг к другу.
Рюкзак и коммивояжёр оба NP-полные, значит оба сводятся друг к другу.
Не согласен с такой формулировкой. Если на си можно написать компилятор идриса а а на идрисе компилятор си это не означает что между ними нет разницы.
Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)
Если вы чистите трубы только тем, кто не может прочистить их сам, у меня к вам есть один вопрос. :)
Я не настоящий курьер, я рюкзак нашёл! У подъезда, вместе с велосипедом
Ветка огонь. Теперь финальная задача. Обойдите все дерево комментов не заржав ни разу) Стандартной библиотекой пользоваться нельзя)
Сколько теннисных мячей поместится в сумку
Они ее распараллеливают, отправляют сразу 100500 курьеров одновременно, кто-то да дойдет.
В голос, спасибо! :)
Они думают, что так и будут по алгоритмам бегать, а после приема на работу приходится бегать по городу.
Это не шутка, ну или почти не шутка. Давно проходил собеседование на позицию Project-manager — первым вопросом было: «Какие алгоритмы сортировки вы знаете?»
Через много лет, когда стал Solution Architect, также было интервью по этой позиции, и угадайте каким был первый вопрос?:)
Через много лет, когда стал Solution Architect, также было интервью по этой позиции, и угадайте каким был первый вопрос?:)
Да я и второй угадаю: «А можно быстрее?».
> Какие алгоритмы сортировки вы знаете?
Не, ну это ещё можно вытерпить. Хуже, когда хрюша идёт по опроснику и спрашивает «Какой алгоритм сортировки лучший?».
Не, ну это ещё можно вытерпить. Хуже, когда хрюша идёт по опроснику и спрашивает «Какой алгоритм сортировки лучший?».
Это ещё что... Когда проходил собеседование на менеджера продукта, для какой-то важной оптимизированной операции решил использовать бинарный поиск по постоянно поддерживаемому сортированному набор строк (вполне умещались в RAM). А собеседовавший меня менеджер проекта (хотя там ещё был аналитик, не считая HR) завернул мой вариант, обосновав, что тогда потребуется индекс, а операции над ним дорогие при таких объёмах данных и требованиях к производительности. И что характерно, аналитик его не поправил. После этого я уже не стремился в их команду, потому что либо каждый должен заниматься своим делом, либо должен хотя бы знать то, о чём говорит, и понимать, что говорят другие, либо не участвовать в решении при недостатке компетенции. А уж с чем-то минимально сложным с максимальным приближением к реальному практическому решению тот товарищ вообще не совладал (это уже из опыта их приёма выполненного мною тестового задания для самостоятельной работы).
бинарный поиск по постоянно поддерживаемому сортированному набор строк
какая по вашему будет сложность вставки в такой список? и устроит ли она вас? мне кажется, что вас хоть и не поняли, но вариант вы предложили так себе. хотя и возможно, что если уточнить задачу и ваше предложение, то окажется, что всё хорошо
Так и есть, гоняют будь здоров, всегда. До 12 собеседований по алгоритмам доходит, а то и больше. И статья, про яндекс беспредел, уже далеко не первая и не последняя, но они имеют тенденцию удаляться. Люди на таком собеседовании разные попадаются, одни тебя пропустят, другие завалят на одних и тех же задачах. Ладно бы это было только в онлайне, а то и приехать просят, а это уже 4 часа только на одно такое собеседование. А если с возрастом давление шалит, то и не на каждом собеседовании блеснуть получается.
И ради чего?.. свет клином же не сошелся на Яндексе… Уж лучше какой-нить европейский стартап.
При всех минусах такого найма, там работают отличные разработчики. Так что могут себе позволить. Желающих много. Да и найм у них в основном с вузов, где живут олимпиадными задачками.
Это плохая тенденция — считая себя великим, позволять себе «неадекватность». И потом, отличные разработчики работают практически везде, даже дворниками. Тем более что желающих много, каждого так собеседовать по 6-12 часов — это как то жирно, больше похоже на практику для уже работающих. А уж олимпиадными задачами не кормиться только ленивый, они в открытом доступе и даже нашему коллективу филиала из «откуда-то» удалось попасть в полуфинал мирового чемпионата. И все же, больше вопросов возникает к отдельным личностям, а не к общему маразму.
Да, только вот толку от всего этого мало. И подход найма такой весьма спорный, а точнее далеко не всегда оправдан, даже в таких конторах как Яндекс. Понты и глупость.
Ищут крепких середнячков. А настоящие таланты проявляются если даже и в процессе стресса, но стресса свободного, творческого, уже в работе, а не в рамках экзамена под страхом его провалить-) Экзамены подобного типа раскрывают несколько иные навыки, но мало когда именно таланты. Многие таланты от воздействия стресса наоборот теряют эффективность и работодатель теряет многих реально крутых людей. Не все к сожалению это осознают. Но это факт. Чистый совок, и не только в российских реалиях, в том же гугле примерно то же самое, нужны крепкие и послушные рабы, конвеер. Почему сейчас еще модны так называемые гибкие технологии, внедряемые везде где ни попадя, загубливая на корню многое полезное.
К сожалению, это не шутка…
И ЗП меньше среднего, прям как в Яндекс доставке!
Ну кстати неизвестно. до ковидлы ходил к ним на тех.манагера собеседоваться. на входе просил немного больше среднего по рынку (хотя хз может оно срденее или ниже, а я не знал)), но они не отказались общаться
Работал в Яндексе техническим менеджером, в итоге предложили зп сильно ниже того, что озвучивал. Но я уже прошел все собеседования, потратил кучу времени и в итоге решил рискнуть) Через год уволился)
А они так и делают всегда, но в конце будет меньше всё-равно.
Ну и тем более, зачем они тогда нужны, такие красивые. Да еще и с нарочито похабным отношением к кандидатам и людям в целом. Было бы еще оправдано рвать задницу за хотя-бы полляма деревянных по нынешнему курсу в месяц. А если еще и ниже рынка-идут лесом однозначно. Экзамены можно и в других местах пройти-)
Это не шутка
Собеседовался пару раз на девопса в Яндекс, первый раз года 3-4 назад, поговорили даже нормально половину интервью, потом дрочево алгоритмов, второй раз года полтора назад, всё проходило 1в1 как тут описано, готовился не менее ответственно, чем автор поста.
После прочтения предыдущих комментов и поста, а потом вашего коммента, в голове само всплыло название следующего сервиса: Яндекс.Девопс. Ну, знаете, сдача админов, которые почти прошли собеседование, в аренду клиентам Я.Облака.
Ну, чтобы просто результаты собеседований хоть как-то применить, даром, что они по алгоритмам!
В большинстве случае требуемые ими знания и даже формат мышления в реальной работе не нужен, а иногда даже вредит. Так как помимо алгоритмов есть ряд других навыков, которые в процессе муштрования кандидатов по алгоритмам, которые безусловно важна как часть основы, просто упускаются из виду, например в части просто логического мышления в других прикладных областях. По алгоритмам достаточно задать не более двух вопросов, остальное-явный перебор.
Примерно то же самое проходил перед нг, но у меня сложилось впечатление, что у яндекса девопс это бекендер на дежурствах. Прошел первый такой этап, но настойчиво порекомендовали порешать больше задач на алгоритмы. Продолжать эти круги собеседований я не захотел и просто слился.
Несколько лет назад собеседовался на разработчика в Облако. Ожидал, что будет много вопросов по алгоритмам, но завалили вопросами по «железкам» и всему, что около них, а потом дали пару задач на лайвкод на любом удобном языке.
На многие вопросы из первой части я ответил с большим трудом, а на некоторые ответов вообще не знал, что наверняка и послужило поводом меня слить)
На многие вопросы из первой части я ответил с большим трудом, а на некоторые ответов вообще не знал, что наверняка и послужило поводом меня слить)
Напомнило: когда в 2008 (или 2009) на заре карьеры я устраивался в яндекс тоже просили проверить на корректность какое-то дерево и возмущались, что я знаю Руби: не то что пишу на нем, тестовое задание делал на C++, а именно что вообще знаю — интервьюер говорил с презрением «что это за Руби?», «какой-то учебный язык?», «какой-то школьный что-ли?».
Такое впечатление, что в яндексе хорошо умеют проверять знание алгоритмов — вот и ищут специалистов где светлее, а не за углом где потеряли.
Такое впечатление, что в яндексе хорошо умеют проверять знание алгоритмов — вот и ищут специалистов где светлее, а не за углом где потеряли.
Это неправда. В данном случае просто не повезло с подрядчиком, кому заказали рекрутирование. В моем случае все было лучше, глушил уже сотрудник Яндекса на последнем этапе, противореча собственным же инструкциям. Правда даже пройдя все этапы, нет уверенности, что вы будете работать в Яндексе, а не на Яндекс в какой-то левой фрилансовской компании.
Правда это было достаточно давно, что бы Яндекс не мог засудить меня за разглашение, ибо соглашение о неразглашении истекло.
Правда это было достаточно давно, что бы Яндекс не мог засудить меня за разглашение, ибо соглашение о неразглашении истекло.
Меня не взяли водителем беспелоднега хотя я идеально соответствую требованиям вакансии. Про алгоритмы, с.ка, даже не спросили...
Ходил на DevOps'a собесится. Было ТРИ собеса по алгоритмам, одно по админству и ни одного по ci/cd и профильным сервисам. Там оч странно
Подскажи плиз, как и зачем собесить по ci/cd, если это учиться за неделю-две и в Яндексе свои велосипеды?
Хочешь сказать чтобы писать эти велосипеды вообще не надо ничего уметь?
Работаю девопс-инженегром. Ни разу за 6 лет не понадобились знания алгоритмов сортировки или слияния массивов. Скрипты пишу постоянно…
Работаю девопс-инженегром. Ни разу за 6 лет не понадобились знания алгоритмов сортировки или слияния массивов. Скрипты пишу постоянно…
для того чтобы уметь и быстро выучить все эти смешные ci/cd, при хорошем понимании основ работы вычислительных систем-нужно немного времени. и наоборот, если вы будете знать ci/cd примочки, но не будете знать основ, основы вы освоить быстро не сможете, да и знания этих примочек будут почти бесполезны. вот в чем ошибка всех этих новомодных собеседований по ci/cd.
и еще, справедливости ради, те кто знает алгоритмы, пусть даже интуитивно, те пишут всегда еще лучше. но конечно не до абсурда как делают порой в Яндексе, по признанию очевидцев разумеется.
для того чтобы уметь и быстро выучить все эти смешные ci/cd, при хорошем понимании основ работы вычислительных систем-нужно немного времени
ну да ну да
и наоборот, если вы будете знать ci/cd примочки, но не будете знать основ, основы вы освоить быстро не сможете, да и знания этих примочек будут почти бесполезны.
примеры основ в студию, без которых практически невозможно освоить ci/cd
и еще, справедливости ради, те кто знает алгоритмы, пусть даже интуитивно, те пишут всегда еще лучше
какая вообще взаимосвязь между алгоритмами и ci/cd ? Правильный ответ - около нулевая. Видел я как девелоперы написали ci/cd на nodejs, обнять и плакать
если это учиться за неделю-две и в Яндексе свои велосипеды?
так и хочется посмотреть как ты за неделю освоишь gitlab/github actions c тераформом, поверх которого argocd. Удачи )))
Расскажи, пожалуйста, как ты видишь идеальное собеседование на DevOps'a.
как обычное собеседование на сисадмина, ничуть не больше. остальное-легко догоняется в процессе. тем более что процессы везде различные.
главное знание и понимание базовых вещей, а умение выстраивать и сопровждать ci/cd - это все равно что слесарю-сантехнику выбирать гаечный ключ нужного размера и крутить гайку в нужном направлении. но суть работы самой сантехники от этого понятна не будет.
в 2018 собеседовался на продажника в яндекс. Задавали алгоритмический задачки))
И еще кучу беспонтовых вопросов
И еще кучу беспонтовых вопросов
В моем случае это правда: соискал позицию тестера. Правда, отшили после двух и "зошто" не случилось.
Они проверяют не эрудицию (знания) а ум - умение думать
А мне понравились алгоритмические задачки в яндексе. Первым делом в голову приходит простой алгоритм с большой сложностью. А потом при помощи подсказок собеседующего и всяких хитростей он доводится до сложного, но с малой сложностью. Но у меня, конечно, таких задачек было штуки 4 на двух собеседованиях. На остальных проверяли уже не алгоритмы.
Задачки нормальные, но зачем столько? Трёх-четырёх достаточно. Я бы уже на втором таком интервью вежливо распрощался, если я захочу порешать задачки, я пойду на hackerrank или leetcode.
В свое время я не успел решить одни задачки на время, честно сказал интервьюеру, что если им так нравится, они могут сами решать олимпиадные. В ответ получил оффер.
Так там разные люди собеседуют. Друг другу не доверяют, вот и перепроверяют каждый раз… как в Яндекс.Толока. А вы как думали?
Так могли бы все в одно время поприсутствовать на решении этих алгоритмических задачек… А то время кандидата получается вообще им не жалко.
Ну как бы меркантильно это ни звучало, но время кандидата дешевле, чем время разработчика. Потому что большинство кандидатов отсеются с нулевым результатом, а разработчик время-то потратит всё равно.
А почему им его должно быть жалко? Это ж не их время. Вот времени своих разрабов — наверняка жалко.
Если это так, столько собеседуют потому что якобы не доверяют-то это уже кризис управления и в конторе бардак, следовательно делать там нечего. Но скорее что это чушь и байка(про собеседования из-за недоверия внутри конторы), все там четко выверено в плане механизма собеседований. А бардака там и так полно, это его никак не исключает кстати. По качеству их сервисов это видно.
Ну так если вам нравятся, то и решайте их на leetcode)
Они созданы, чтобы проверять знание кандидатом базового синтаксиса. Конечно, немного думалка тоже проверяется, но алго-думалка с обычной не совсем коррелирует и даже скорее совсем не коррелирует.
Они созданы, чтобы проверять знание кандидатом базового синтаксиса. Конечно, немного думалка тоже проверяется, но алго-думалка с обычной не совсем коррелирует и даже скорее совсем не коррелирует.
Я бы сказал так – в промышленной разработке очень полезно знать, как устроены алгоритмы, но крайне плохо, если их приходится писать самому.
Это крайне плохо, да. Пока вы не сталкиваетесь с масштабами Яндекса. Когда вам нужен хэш-тейбл на миллиард элементов, то внезапно оказывается что стандартная реализация не такая уж и хорошая.
Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
Но там не задают задачу на написание хеш таблицы. Максимум на использование. И полностью рабочее бинарное само-балансирующееся дерево — тоже не задают. Максимум тривиальное дерево. Просто для проверки, что кандидат может представить структуру и хоть чуть-чуть понимает, как работают указатели.
Вот именно. То есть зачем они ищут тех, кто пишет алгоритмы а не программы — непонятно.
А как проверить? Алгоритмы хороши тем что не умея программировать их не выучишь наизусть за 3 месяца. В отличии от баззвордов и 100 типовых вопросов по любой технологии.
И на софт скилах не выедешь, как можно сделать в разговоре за жизнь.
И можно разных кандидатов сравнивать друг с другом. По формализуемым признакам.
Предложите альтернативный вариант. Чтобы не хуже было хотя бы по этим критериям.
И на софт скилах не выедешь, как можно сделать в разговоре за жизнь.
И можно разных кандидатов сравнивать друг с другом. По формализуемым признакам.
Предложите альтернативный вариант. Чтобы не хуже было хотя бы по этим критериям.
Ну народ за несколько месяцев мощно насобачивается на решение задач с leetcode.
Да. Народ уже умеющий нормально программировать. Не случайные люди с улицы после курсов вайти.
Какой варинат решения прелагаете? Спрашивать еще сложнее? Рюкзак модифированный так чтобы его случайный человек не узнал пойдет? Так отсеются вообще все. Случайный мидл даже после сидения на литкоде не справится же.
Какой варинат решения прелагаете? Спрашивать еще сложнее? Рюкзак модифированный так чтобы его случайный человек не узнал пойдет? Так отсеются вообще все. Случайный мидл даже после сидения на литкоде не справится же.
Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.
Более-менее нормальный подход — давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить (то есть надрочиться на литкоде не поможет), а головой подумать, плюс и прикладной смысл чтобы был, и дать человеку ее решать в привычной среде — просто расшарив экран. Пусть гуглит что хочет (кроме прямого решения задачи, конечно), вообще разрешено все (как и что человек гуглит — это вообще о многом сразу говорит!). И посмотреть, КАК человек это все делает. Такое, типа, парное программирование.
Тут, конечно, формальных баллов не начислишь, все субъективно. Но уровень сразу виден, уже через пять минут на самом деле.
Более-менее нормальный подход — давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить (то есть надрочиться на литкоде не поможет), а головой подумать, плюс и прикладной смысл чтобы был, и дать человеку ее решать в привычной среде — просто расшарив экран. Пусть гуглит что хочет (кроме прямого решения задачи, конечно), вообще разрешено все (как и что человек гуглит — это вообще о многом сразу говорит!). И посмотреть, КАК человек это все делает. Такое, типа, парное программирование.
Тут, конечно, формальных баллов не начислишь, все субъективно. Но уровень сразу виден, уже через пять минут на самом деле.
давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить
Ну посмотрите же задачи из статьи. Где там хоть одна, где надо алгоритмы помнить? Максимум, знать, что есть такая структура данных — хеш-таблица.
А примерчик ещё проще чем в статье можно? Там все еще проще вырождается в однострочник или физзбазз.
IDE или не IDE дискуссионно.
Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.
Ну так в отличие от ИДЕ от вас не требуется написать компилируемый код, а иногда не требуется и брать существубщий ЯП — достаточно просто набросать алгоритм, чтобы было понятно что куда и как. Вангую что никто не будет докапываться если в каком-нибудь SelectMany букву забудете или порядок аргументов какой-нибудь функции перепутаете. Главное как вы будете рассуждать и какие уточняющие вопросы задавать.
Код запускается и проверяется. Но это по моему опыту и знакомых.
Если от вас требуют написать без ИДЕ на бумажке идеально компилирующийся код без ошибок — то это вполне хороший фактор чтобы туда не идти. Так что не вижу ничего плохого в том чтобы получить на такое отказ.
Это где? Особенно с вайтбордом интересно — по-вашему, интервьюер потом сидит и перепечатывает код?
Умение писать алгоритмы, и умение работать в команде, знать фреймворки и другие вещи — вообще не особо связано.
Но вопрос в основном в театре абсурда, когда тебе на 10 интервью задают то одни то другие алгоритмы И НИЧЕГО по технологиям
А в разговоре за жизнь можно много чего узнать. Что человек сделал, зачем, почему.
Но вопрос в основном в театре абсурда, когда тебе на 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й.
На деле же, когда у компании 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 месяца. Да, не неделя, как в небольших компаниях, но раз недостатка в кандидатах нет и акции растут, значит всё работает норм.
Не очень понятно, как вместо того, чтобы собеседующие проводили по 6 секций с каждым кандидатом, пустить их время на улучшение процесса. Сажать по 6 человек на кандидата — не уменьшит времязатраты интервьюеров, но уменьшит точность за счёт меньшего числа вопросов.
Есть ли примеры крупных IT-компаний (1000+ разработчиков, не бодишоп), где быстро собеседуют и быстро могут дать положительный фидбек?
В гугле с момента подачи резюме до оффера проходит 3-6 месяцев. В Яндексе 1-2 месяца. Да, не неделя, как в небольших компаниях, но раз недостатка в кандидатах нет и акции растут, значит всё работает норм.
раз недостатка в кандидатах нет
спорное утверждение.
Ко мне рекрутеры Яндекса обращаются с завидной регулярностью. Причем уже доходило до того, что мои данные «передавали» в КА/РА, которое работает на Яндекс.
Ко многим знакомым — тоже.
Да, не спорю, туда все еще многие мечтают попасть, но есть ли прямо очереди? Чё-т не уверен.
Основной признак недостатка кандидатов — снижение планки найма.
Активность HRов, это вполне предсказуемый процесс. Яндекс хочет нанимать самых подходящих специалистов на рынке. При этом сильный кандидат может и не подозревать, что его примут в Яндекс. Поэтому Яндексу в целом выгодно множество HRов, которые ходят по рынку и холодными звонками выцепляют людей на собеседования.
И HRы эти далеко не всегда сотрудники Яндекса. В целом есть распространённая модель партнёрства, когда ты заключаешь с компанией договор о том, что она с каждого трудоустроенного от тебя кандидата платит тебе процент. А дальше ты сам себе хозяин и ищешь кандидатов где только можешь. В результате да, бывают эксцессы, а люди могут сокрушаться в комментариях, мол «мне написывал HR из яндекса, как же они задолбали», но это не признак недостатка желающих пройти собеседование.
Мне, например, когда я работал в Яндексе, в Линкедине писали такие HRы предлагая прийти на собеседование в Яндекс. Бывает, что уж
Активность 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/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.
Если 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 задачах довольно часто спасает кеширование или исправление конкретного места.
Буквально на днях столкнулся с "возросшей нагрузкой" — есть корпоративный портальчик, ничего супер-пупер нагруженного, состряпали, запустили, пользуемся… через пару лет начинаются жалобы — тормозит. Автор портальчика к тому моменту уже потерялся, полез смотреть сам (я не программист) — оказывается, при каждом действии, ajax шерстит историю сообщений, чтобы в случае чего новенького отрисовать "колокольчик", а сообщений накопилось уже немало, а в алгоритме почему-то был линейный перебор с "ручным" анализом "новое/прочитанное" (таблица ID прочитанных сообщений была у каждого пользователя своя, а таблицы сообщений шли сплошной простынёй)… казалось бы — сделай запрос к базе по JOIN с "объединением по NULL", чтобы отобрать только непрочитанные, но автор решил несколько иначе — выбирал все сообщения, а потом искал их ID в "личной" таблице, и если не находил — высвечивал оповещение.
Вроде рабочий алгоритм, но вот с масштабированием совсем боль.
Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.
Так, стоп! Это кто там такие принципы напридумывал? Те же самые люди, которые придумали триггеры и хранимые процедуры? Ок, у меня к ним есть только одно пожелание, и оно связано с адом и огнём.
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
Ну так это ровно то же, что вы пишите. Выборка данных + расчет производных данных на их основе (преобразование функциями, сумма, вот этот весь треш).
Если вы фильтруете или преобразовываете данные потом на бекенде, то тут что-то немного не так. Иногда это ваша вина, иногда бд.
… иногда даже вина человека, который занимался выбором БД. Просто потому что колоночные БД и, например, теперь уже бесплатный кликхауз, это могут делать на порядки быстрее.
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать 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) даже небольшого жизненного опыта достаточно, чтобы вовремя спросить «а робот-пылесос где парковаться будет?»/«а в шкафу подсветки не будет что-ли?»/«думаете на вашу столешницу больше двух электроприборов за раз поместиться?»/«ну это новая зубная щетка заряд держит, а потом как вы ещё заряжать будете, когда тут бритва на зарядке и фен нужен?»
Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…
Если же Вы прораб и делаете ремонт «другим», то тут грубо говоря два варианта: 1) прораб
Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…
Опыт показывает, что нет ничего более постоянного, чем временное.
Рефакторинг отнимает кучу ресурсов, больше, чем было бы потрачено на изначально грамотное проектирование. В конечном итоге рефакторинг откладывается до лучших времен, баги митигируются костылями, мейнтенанс и дев луп растут.
Рефакторинг отнимает кучу ресурсов, больше, чем было бы потрачено на изначально грамотное проектирование. В конечном итоге рефакторинг откладывается до лучших времен, баги митигируются костылями, мейнтенанс и дев луп растут.
заходишь такой в интернет-магазин… и обычный обывательский мобильник вешается.Зашёл я как-то на один технический новостной сайт с обычного пользовательского мобильника…
Впрочем, ходят слухи, что уже ведётся работа над новым движком для комментариев, и к осени он будет готов. К какой осени — источник умалчивает.
В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку
Браузер стерпит. Пользователь может и не стерпеть.
Не смог удержаться...
Или все такси в России на час перестанет работать. Остальные нагрузку не тянут, и ложатся под ней.
И как люди без интернета сотни лет жили?
И как люди без электричества сотни лет жили?
Раньше работало, плохо но работало. Сейчас если Яндекс падает такси в России перестает работать. Надо теперь с этим жить.
И как люди без электричества сотни лет жили?
Раньше работало, плохо но работало. Сейчас если Яндекс падает такси в России перестает работать. Надо теперь с этим жить.
А конкуренты куда делись?
Нагрузку не тянут.
В прошлом году полдня Яндекс такси лежало, все конкуренты легли под нагрузкой сразу же.
https://habr.com/ru/news/t/487130
В прошлом году полдня Яндекс такси лежало, все конкуренты легли под нагрузкой сразу же.
https://habr.com/ru/news/t/487130
При этом сервисы Яндекса и так регулярно падают. В Яндекс.коннект или в метрике или в Яндекс Недвижимости регулярно натыкаюсь на «ваш запрос не может быть выполнен», на несохранение каких-либо действий или просто на неверную выдачу.
И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.
Никто не гоняет нагрузочне тестирование по всем апишкам после каждого релиза.
Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.
Критический путь можно так проверять. И иногда проверяют. Но это даже близко не все методы.
Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.
Критический путь можно так проверять. И иногда проверяют. Но это даже близко не все методы.
Нагрузочное тестирование — чрезвычайно нетривиальная вещь, особенно для stateful сервиса. В больших компаниях за этим стоят отдельные сервисы со своими командами. И то даже в Яндексе и FAANG'е это далеко не для любого сервиса отлажено хорошо. Не панацея, в общем.
упадёт потому что NPE, и тут никакой алгоритмист не поможет ))
А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.Я ведь верно понимаю, что любой алгоритмист, при устройстве на работу, гарантирует своему работодателю некий аналог sla с несколькими девятками, и полной компенсацией в случае падения прода? Или алгоритмисты только говорить могут, а на деле роняют прод примерно так же часто, как и обычные инженеры?
А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.
Если он сделан прям «так жутко», то он просто код ревью не пройдет.
Хочется верить.
Всегда есть вероятность что какой-то код написали в тестах. А кто же внимательно ревьюит тесты?
Потом этот же код скопировали в метод нужный в админке. Кто же внимательно ревьют скопированный код на который не будет нагрузки и пользователи все свои?
А потом его вызвали из любого пользовательского метода на который не должно быть нагрузки. Кто же внимательно ревьют не тот код что написан только что, а какой-то там метод? Тем более нагрузки же нет.
А потом пришла нагрузка. И все легло. И никто не виноват.
Всегда есть вероятность что какой-то код написали в тестах. А кто же внимательно ревьюит тесты?
Потом этот же код скопировали в метод нужный в админке. Кто же внимательно ревьют скопированный код на который не будет нагрузки и пользователи все свои?
А потом его вызвали из любого пользовательского метода на который не должно быть нагрузки. Кто же внимательно ревьют не тот код что написан только что, а какой-то там метод? Тем более нагрузки же нет.
А потом пришла нагрузка. И все легло. И никто не виноват.
Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.
Под "алгоритмистами" чаще всего понимают рисерч-инженеров… давайте расскажите, как компаниям не нужен R&D и все можно порешать на уровне понимания "сейчас пройдемся по списку и сложим два числа"...
ну или алгоритмиста
Выделенный алгоритмист не нужен.
У нас был проект, где были выделенные аналитики для увеличения производительности (прям такие математики-предметники). Которые в код реально не лазили.
В итоге (у них было достаточно «веса» чтобы настоять на включении доп.оптимизаций) схема разработки превращалась в старый анекдот про филина и мышей: «я вам решение сказал, а как вы будете это делать — это уже технические (не волнующие меня) детали».
В смысле копия? Это вы так резко опустили всех разработчиков FAANG?
Если же вы имеете в виду, что копия в плане собеседований, то флаг им в руки. Зачем нужно проходить это все в Яндекс, когда можно то же самое все пройти в любую из FAANG?
Если же вы имеете в виду, что копия в плане собеседований, то флаг им в руки. Зачем нужно проходить это все в Яндекс, когда можно то же самое все пройти в любую из FAANG?
А что не так? В Яндексе нет настолько умных людей как в FAANG? Или они не делают нормальные сервисы?
В Яндексе нет настолько умных людей как в FAANG?Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.
Или они не делают нормальные сервисы?Ну, не знаю, огромная доля сервисов Яндекса со стороны кажется банальным симптомом болезни «а во. такая штука появилась на рынке, значит, надо делать свой клон». Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
негативных отзывов на поведение контор из избранного списка
Чего чего сделали?
Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
Ну, так сказать, вот они — крутые олимпиадники в действии…
Ой это действительно боль, все еще пользуюсь яндексом по инерции, но заставить его найти именно то что я хотел а не то что он выдумал, это тот еще квест. Особенно весело, учитывая что я работаю с вещами по которым 1.5 статьи и из них одна на английском. Все чаще открываю гугл или утку.
Вот это жесть и как интересно можно было додуматься до такого.
Но справедливости ради это не вина олимпиадников, это вина их начальников. У меня вообще складывается ощущение, что я последний адекватный руководитель на планете, ну что за треш то кругом а.
Но справедливости ради это не вина олимпиадников, это вина их начальников. У меня вообще складывается ощущение, что я последний адекватный руководитель на планете, ну что за треш то кругом а.
Вот это жесть, это же постараться надо чтобы ТАК работать. А по задумке яндекса можно просто уйти к ним в партнеры и такого никто никогда не увидет? Прикольно.
Ну ок, значит будем людям объяснять что на я.маркете отзывы смотреть нельзя, пусть фламп развивают.
Ну ок, значит будем людям объяснять что на я.маркете отзывы смотреть нельзя, пусть фламп развивают.
Курс на это можно было предположить уже тогда, когда вместо покупной картосновы они стали разрабатывать собственную путем покупки конторы, нанимающей пионеров для рисования по спутниковым снимкам, и когда в сервисах погоды и отслеживания общественного транспорта стали алгоритмически дорисовывать несуществующие данные.
Не то чтобы я хочу сказать, что это именно вина олимпиадников, но олимпиадники — такой народ, который скорее будет беспокоиться больше об алгоритмах и меньше — о, гхм, поворачивании к клиенту задницей. В этом смысле, они — идеальные исполнители для таких начальников.
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.
С чего бы это? В сам FAANG конечно больше кандидатов, но вот и мест там значительно больше.
При этом для выпускников местных топовых вузов, как мне объяснял один знакомый из Долины, пойти в Гугл, это не как для москвича после МГУ / МФТИ пойти в Яндекс. Скорее как для москвича пойти в какой-нибудь банк, разгребать несвежее легаси, поскольку местные успешные разработчики стараются идти в стартапы за долей в компании.
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.
Среднее по больнице на то и среднее, что на больших числах размеры конторы перестают влиять на средний IQ там работающих. )
ps Советую не обожествлять фаанг. Судя по рассказам, локального бардака и бюрократии там куда как больше.
Божественный? Да он был таким пару лет назад, пока из него магазин не догадались сделать. Теперь в нём нет сортировки по цене и отзывы обо всех модификациях фигачат в одну позицию.
т.е. вы считаете, что что и крупнейшие западные топовые компании и создатели литкода, да и наверное все вокруг идиоты?) и только вы один светоч знаний
Согласен — хорошо вести бизнес, хорошо создавать продукт, хорошо собеседовать кандидатов, хорошо <что-то еще> — это совершенно разные задачи.
С топовыми компаниями тут ошибка выжившего — не они топовые по тому что у них эффективная система найма сотрудников, а неэффективная система найма сотрудников не мешает им процветать потому что они топовые (много денег и многие хотят там работать).
С топовыми компаниями тут ошибка выжившего — не они топовые по тому что у них эффективная система найма сотрудников, а неэффективная система найма сотрудников не мешает им процветать потому что они топовые (много денег и многие хотят там работать).
пройдёт лет 10 и слоупоки-подражатели типа Яндекса тоже сменят пластинку и начнут подражать новым веяниям из Кремниевой Долины
А мне кажется, что они не слоупоки и совсем не подражатели. Просто «отличники» или около того, в большинстве своем. Ну привыкли просто так со школьной скамьи… по другому не умеют. Им бы, наоборот, поучиться у гугла с майкрософтом или у других, более адекватных к собесам российских контор. Вон ниже Emil983 о них [google/ms] рассказывает.
Я уже раза три за последние 15 лет, устраивался в подобных топик-стартеру условиях в топовые компании. Слава богу, попадались адекватные интервьюеры и будущие коллеги. Работа-то далеко не из задачек на классические алгоритмы состоит. )
Поправлю: Яндекс в этом смысле повторяет не за условным Гуглом, а за самим собой во времена первичного расцвета. А сейчас это превратилось в культ карго.
Так в Яндексе никто про тенисные мячики не спрашивает. А почему вы решили, что задаваемые задачи не имеют практического применения в Яндексе? Вы там работали или хорошо знаете как работают в компании? Я вообще не понимаю такого негодования. Не нравится процесс собеседования, ну так не ходите на них в подобные компании. Почему вы считаете, что процесс правильного собеседования может быть только 1, а все другое ложно?
Бред. Собеседовался в MS на Software Engineer и дважды в гугл на Software Engineer Manager за последние 3 года. В MS никаких тупых задач для студентов не было, были задачи приближенные к реальному миру и после их решения каждый раз говорили (ну вот примерно вот так у нас хранение прав устроено), в гугле аналогично: только одно собеседование по кодингу из 5 такое на «базовые вещи» и то это не просто «покажи дао алгоритмов» а вот тебе интересная задачи и реши её, а потом мы обсудим её сложность и как можно улучшить.
А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
Проходил/прохожу в 2021, 2020, 2019. в 2019м в MS оставшееся время беседовали об этом с одним из интервьюеров и он посмеялся над этим тоже, сказал что такие задачи они давно дают только людям без опыта, читай студентам, у которых-то и спросить больше нечего. Согласен, есть и люди которые бездумно перенимают то что они считают лучшим. Даже на логику есть куда более адекватные задачи.
Ну я вот собеседования в прошлом году в Фейсбук и в этом в Амазон. Задачи, внезапно, с литкода.
Окей, в Гугле на первой итерации попросили сдизайнить шедулер тасков, не совсем типичная с литкода, но такие там тоже есть.
Окей, в Гугле на первой итерации попросили сдизайнить шедулер тасков, не совсем типичная с литкода, но такие там тоже есть.
Аналогично, в 2020-м Гугл, Фейсбук и Амазон спрашивали алгоритмические задачки. Это при том, что в Гугл, например, требовался формошлеп на ангуляре.
Эта leetcode.com/problems/task-scheduler? Классная задачка, на мой взгляд.
Не, не эта — надо сделать возможность выполнить коллбек через Х времени в будущем. И чтобы была возможность отмены.
Типа надо сделать 2 метода
Больше вводных вроде бы не было. В целом достаточно творческая, есть над чем подумать, не супер сложная (это фон скрин был), но и не «разверните строку».
Типа надо сделать 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, а что-то, что вы военный радист и получаете донесения с передовой для дальнейшей передачи в штаб. Вам надо раз в день собранный поток сообщений как-то уменьшить в объёме, но сохранить порядок. Ещё известно, что часто подряд приходит много однотипных сообщений. Вопрос — как будете преобразовывать? Тут с помощью интервьюера дойдёте до исходного условия и дальше напишете тот же алгоритм (ну или не напишете).
Я собеседующий в Гугл. За последние пару лет в процессе собеседования не поменялось принципиально ничего. Те же задачи, похожие на литкод. Да, хорошим тоном считается завернуть их в обёртку реального мира. Например, не строку ААААВВВ преобразовать в А4В3, а что-то, что вы военный радист и получаете донесения с передовой для дальнейшей передачи в штаб. Вам надо раз в день собранный поток сообщений как-то уменьшить в объёме, но сохранить порядок. Ещё известно, что часто подряд приходит много однотипных сообщений. Вопрос — как будете преобразовывать? Тут с помощью интервьюера дойдёте до исходного условия и дальше напишете тот же алгоритм (ну или не напишете).
В 2008 году в Яндексе такого алгоритмического маразма на собеседовании не было. Да, алгоритмы были, но не в таком количестве, и с очень хорошей привязкой к внутренней механике Яндекс-поиска.
P.S. я — бывший сотрудник.
P.S. я — бывший сотрудник.
Нет, они довели до абсурда худшие практики, которые в FAANG постепенно уходят из повестки собеседований.
Несколько лет назад, когда я проходил свои 4 собеседования в Яндекс, они всё же были другими. Там про архитектуру и проектирование систем спрашивали, про устройство Linux, распределённые системы и т.п. интересные вещи. А то, о чём написал автор — это квинтэссенция идиотизма. Бессмысленная трата времени и очень плохой алгоритм фильтрации и проверки кандидатов.
В начале собеседования с Гуглом, вас потребуют подписать NDA, что ни какие подробности интервью вы не можете разглашать. Какие последствия? Наверное через суд, заставят оплатить издержки, например, потратили время на 1000 кандидатов, которые уже знали заранее ответы, или оплатить 100 часов на переделку всех контрольных билетов. :-)
Собеседовался в Гугл в Цюрихе — ничего подписывать не просили.
Все подробности интервью давно есть в комментах на 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-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 минут прочитать статью на вики про О-нотацию?
Я комментарием выше достаточно емко показал, что ваш поинт — абсурд, но вы проигнорировали. Ясно-понятно.
Вы привели пример, когда от «инженера» требуется, скажем, умение крутить гайки. Я не инженер, но гайки крутить умею. Как понять, что я инженер, а не токарь Вася с завода? Мы оба умеем крутить гайки.
Вы описали какие-то абстрактные требования, вопрос-то в том — КАК понять, что кандидат ими обладает? Я встречал кучу кандидатов (в тч когда побеседовал работников Яндекса в других конторах), которые молоть языком горазды — и расскажут как они сделали «конечный продукт поддерживаемым и простым в расширении» и что у них есть «умение видеть необходимость оптимизации, когда нужно делать что-то новое», но вот беда — hello world написать не могут. Как отсеять болтунов?
Вы описали какие-то абстрактные требования, вопрос-то в том — КАК понять, что кандидат ими обладает? Я встречал кучу кандидатов (в тч когда побеседовал работников Яндекса в других конторах), которые молоть языком горазды — и расскажут как они сделали «конечный продукт поддерживаемым и простым в расширении» и что у них есть «умение видеть необходимость оптимизации, когда нужно делать что-то новое», но вот беда — hello world написать не могут. Как отсеять болтунов?
> от «инженера» требуется, скажем, умение крутить гайки.
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.
> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.
> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.
> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.
> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
> Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше
Ну вот я общался с кандидатами — красиво стелят, якобы делали то, сё, пятое, десятое, а hello world написать не могут. Что с такими делать? Поверить на слово что он реально это делал? Тогда почему не может hello world написать? Или включить презумпцию виновности и решить что он балабол и просто сидел на зарплате глядя как другие вот это все описанное делают, а сам JSONы два года перекладывал?
> Как отсеять болтуна-физика, прикидывающегося инженером?
Я не знаю, вы мне скажите=) Для программистов вот есть задачки с литкода — если человек потратил недельку на подготовку к собесу, он их решит. Если не потратил — то точно ли он хочет новую работу или просто так с улицы зашел? Как быть для инженеров — хз, не моя тематика.
Ну вот я общался с кандидатами — красиво стелят, якобы делали то, сё, пятое, десятое, а hello world написать не могут. Что с такими делать? Поверить на слово что он реально это делал? Тогда почему не может hello world написать? Или включить презумпцию виновности и решить что он балабол и просто сидел на зарплате глядя как другие вот это все описанное делают, а сам JSONы два года перекладывал?
> Как отсеять болтуна-физика, прикидывающегося инженером?
Я не знаю, вы мне скажите=) Для программистов вот есть задачки с литкода — если человек потратил недельку на подготовку к собесу, он их решит. Если не потратил — то точно ли он хочет новую работу или просто так с улицы зашел? Как быть для инженеров — хз, не моя тематика.
> Как быть для инженеров — хз, не моя тематика
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.
Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.
Вы — не гугл. Вы не можете пользоваться этой методикой. Гугл ее использует, потому что богат и может себе позволить найти задротов, нанять их, а потом спустя год работы отсеять тех, кто не имеет инженерных навыков. Вы за год работы этих самородков потеряете деньги и получите малоподдерживаемое глючное дерьмо в продакшне.
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.
Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.
Вы — не гугл. Вы не можете пользоваться этой методикой. Гугл ее использует, потому что богат и может себе позволить найти задротов, нанять их, а потом спустя год работы отсеять тех, кто не имеет инженерных навыков. Вы за год работы этих самородков потеряете деньги и получите малоподдерживаемое глючное дерьмо в продакшне.
Всё же механика часть физики.
Как хорошие собеседующие отличают опытного специалиста от специалиста разговорного жанра?
А раньше как отличали? Беседой. И никто не умирал при этом, и кандидаты успешно находились. Как же это как, интересно? Потому что это было собеседование, а не вступительный экзамен, как сейчас. Но да, собеседование в таком режиме требует от интервьювера соответствующих навыков и опыта, а не сравнивания ответов задач.
Посмотреть гитхаб? У некоторых там вполне красноречивые доказательства, почему их (не) надо брать на работу.
Я тот самый человек, который стелит, делает и пишет, но на собеседовании не может hello world. Вот такое у меня свойство организма, я предполагаю что глубокая травма экзаменами в институтах. За 15 лет опыта я прошел сотни собеседований, могу довольно складно рассказывать о прошлых проектах и достижениях, честно рассказывать, без вранья, но как только начинается разговор о том чтобы под строгим взглядом экзаменатора собеседующего деревья разворачивать и списки склеивать, я тут-же выключаюсь, мямлю, в голове включается гифка с обезьянкой с литаврами, и я не могу вспомнить как правильно переменные объявлять. Вот так вот я устроен, если дать мне проблему, комп в темном углу, и отстать, я напишу работающий код. Если встать у меня за плечом и смотреть, я напишу ровным счетом ничего. И я такой не один, нас таких достаточно много.
И я такой не один, нас таких достаточно много.
В абсолютных цифрах — возможно. А в потоке людей — очень и очень мало. Ну представьте себе что человек проходит какие-нибудь 3-недельные курсы на ютубе, его научили правильно отвечать на "что такое солид" и какие-нибудь киты ООП, но он реально не программист, а какой-нибудь дворник который попал на таргетированную рекламу "заработай 100500 на ~~джойказино ~~яндексе".
И вот на одного такого вас 19 вот таких фот "типа программистов".
Если в маленькой компании с вами могут нормально поговорить по душам и распознать одно от другого (это не трудно, если уделить достаточно времени) — то в компании "на потоке" кроме как собсвтенно попросить кодить это не проверить.
А у вас есть источник этой статистики? А то у меня вот опыт исключительно личный, и за 15 лет опыта работы в различных больших и маленьких компаниях, проведения и прохождения собеседований, тех кого вы описываете видел только на джун вакансиях (куда им, собственно, и место), а вот таких как я навидался до черта.
А вот ужастиков через третьи руки слышал, да, вот только ни разу не видел подтверждений, сколько не спрашивал
А вот ужастиков через третьи руки слышал, да, вот только ни разу не видел подтверждений, сколько не спрашивал
Увы, тоже пример личный. Один человек вообще себя искренне называл "Аватар тестирования" (я иногда принимаю участие в собеседовании QA, рассказываю про архитектуру и прочие вопросы по компании с точки зрения разработки).
Есть и другие истории, но их пожалуй приберегу, не все из них хочется в паблик писать, мало ли увидят и обидятся.
Я заметил, что у меня курса с 3-го — 4-го тоже появилась такая проблема. Хотя в школе без проблем решал на доске различные задачи. К счастью хороших предложений сейчас много. Можно позволить себе отсеять компании с кодингом на интервью.
+1 почти ровно такая же ситуация. Путаю синтаксис for в php и js, просто потому, что IDE сама подставляет нужный уже когда напечатаешь «for», остаётся только нужные имена переменных подставить, в результате код на собесе может не заработать тупо потому что где-то поставил запятую вместо точки-запятой.
Эти собеседования нужны как раз для отсечения людей, которые мало того, что не привыкли работать с оглядкой на миллионы запросов в секунду (потому что «ну сколько реально запросов может быть-то?»), но и не понимают, что иногда размер данных больше, чем цифр в их номере телефона. А, ну и забыл мантру: «стандартная библиотека реализована эффективно, её можно использовать в любых высоконагруженных системах» (нет)
Это очень-очень плохой подход — сразу видеть квадратичную сложность и, имея ввиду лёгкий фикс, всё равно уповать на «может быть срастётся»
Вот тут человек тоже плюс минус того же разлива и количества задачи решал часами на пролет, на стажера… Мне кажется им все равно какая позиция, главное с хорошим человеком порешать задачки! -)
Последняя задача прям детская по градации литкода (который тебе не зря посоветовали)
А у этой задачи есть решение, кроме полного перебора?
Если числа не очень большие по модулю — то динамическое программирование, как в задаче о рюкзаке. Будет решение за O(n*M), где M — сумма всех чисел по модулю.
Если числа — любые инты, то только перебор.
А вообще, я невнимательно прочитал задачу. Там надо не подмножество чисел взять, а отрезок из массива. Решается за линию. Идем по массиву считая частичную сумму (до начала). Поддерживаем хешмап уже известных сумм. Смотрим, есть ли там target-<текушая сумма>. Если есть — мы нашли отрезок. Потом кладем текущую сумму в мап.
В смысле, все частичные суммы до начала? Для третьего элемента, например, это 3, 3+2, 3+2+1, затем для четвёртого 4, 4+3, 4+3+2, 4+3+2+1 и так далее? Не врубился) Есть HR-ы в треде?)
Нет, просто частичные суммы. От начала до текущего элемента.
Основная идея решения: сумма на отрезке — это разность двух частичных сумм. Поэтому если для каждой частичной суммы достаточно проверить, что левее есть нужная частичная сумма.
Вот набросок кода:
pair<int, int> FindRange(const vector<int>& v, int target) {
std::unordered_map<int, int> sums;
int current_sum = 0;
for (size_t i = 0; i < v.size(); ++i) {
current_sum += v[i];
if (current_sum == target) return std::make_pair(0, i+1);
auto it = sums.find(current_sum - target);
if (it != sums.end()) {
return std::make_pair(it->second+1, i+1);
}
sums[current_sum] = i;
}
return std::make_pair(-1, -1);
}Можно избавиться от одного случая, если изначально впихнуть в map {0, -1}, но понятнее без этого, мне кажется.
Конечно через хештаблицы.
Вот в псевдокоде:
Сложность O(n)
int[] nums = {1,-2,4,8,....whatever}
hashtable(int) h;
int target = 9;
for(I: nums)
if(h.contains(9-i))
{
print «решение = », 9-i, I;
}
else
map.insert(i)
итерируемся по массиву заданных чисел.
если в хештабле есть искомое-текущее значение итератора, значит решение найдено, иначе кладем текущее в таблицу и итерируемся дальше
Вот в псевдокоде:
Сложность O(n)
int[] nums = {1,-2,4,8,....whatever}
hashtable(int) h;
int target = 9;
for(I: nums)
if(h.contains(9-i))
{
print «решение = », 9-i, I;
}
else
map.insert(i)
итерируемся по массиву заданных чисел.
если в хештабле есть искомое-текущее значение итератора, значит решение найдено, иначе кладем текущее в таблицу и итерируемся дальше
У меня аналогичный опыт. Было 5 или 6 собеседований, после которых, я окончательно потерял интерес к собеседованиям в Яндексе. Правда, есть и отличия:
— один из рекрутеров пользовался компилятором. Просто я что-то нестандартное написал, и без прогона через тесты сложно было понять, во всех ли случаях будет работать.
— на последнем интервью вообще вышло разногласие. Я опять попытался изобрести свой алговелосипед (но не успел), и мнение по поводу работоспособности такого алгоритма у нас с рекрутером разделились. :)
P.S. leetcode крут. Иногда хожу туда за интересными задачками
— один из рекрутеров пользовался компилятором. Просто я что-то нестандартное написал, и без прогона через тесты сложно было понять, во всех ли случаях будет работать.
— на последнем интервью вообще вышло разногласие. Я опять попытался изобрести свой алговелосипед (но не успел), и мнение по поводу работоспособности такого алгоритма у нас с рекрутером разделились. :)
P.S. leetcode крут. Иногда хожу туда за интересными задачками
Знаете что самое забавное, когда кажды йраз читаю про алгоритмы и сложности, а потом берусь за какой нить direct.api и через неделю кидаю пяток багрепортов, в которых суть примерно такова «выша песочница не работает, совсем, вообще» и жду полгода пока они ее починят, а манипулировать деньгами клиентво мне предлагается прямо наживую, агаа…
ЗЫ ну если им по ставке 200к так не жалко своего и кандидата времени, видимо нужно просить 400 с порога
ЗЫ ну если им по ставке 200к так не жалко своего и кандидата времени, видимо нужно просить 400 с порога
У них часто элементарно форма обратной связи не работает.
Видимо чуваки, бодро решающие алгоритмические задачки, не в состоянии написать форму обратной связи.
Видимо чуваки, бодро решающие алгоритмические задачки, не в состоянии написать форму обратной связи.
Она не часто, она почти всегда не работает. Я перестал им что либо писать по этой причине. Ее найти еще часто — целый квест. А еще у них очень часто на этой форме при выборе пунктов такие жуткие тормоза и ошибки, что до кнопки отправить вообще не добраться. Я даже квест как то проходил, победить форму чтобы зарепортить форму, час угрохал но цели не достиг.
Им некогда чинить форму обратной связи им библиотеки алгоритмов переписывать надо.
Или КиноПоиск HD, который абсолютно безобразно работает на Playstation и тупо отсутствует на Xbox (собирайте подписи, угу). И ладно было бы какое-то ядро сильных алгоритмистов, которые бы писали им внутренний API для инфраструктуры. Так нет же, ищут таких же оторванных от реальности олимпиадников для решения проблем бизнеса. Особенно это явственно при работе с фронтэндом (с чем пользователь и сталкивается бо́льшую часть времени).
Да, можно достучаться. Причем они довольно вменяемые временами и потом присылают уведомления что мол починили/нет.
Во первых у меня есть disclaimer под письмом. Действует магически, проверено на куче тп 8).
Во вторых писал я с действительно серьезными ошибками по их api/интерфейсам.
По более мелким типо отсутствия заливки фона в firefox, да, бесполезно.
Памятка сотрудникам техподдержки:
Это письмо составлено не потому что проблему у Автора, а потому, что проблема у Вас
Это письмо составлено потому, что Автор уважает труд разработчиков и считает что фидбек лишним не бывает.
Автор сам может справиться любой проблемой или прекратить использование продукта.
Если вас устраивает, что ваши пользователи будут сталкиваться с вышеописанной проблемой, просьба проигнорировать это письмо или в ясной форме озвучить свою позицию в ответе.
Во вторых писал я с действительно серьезными ошибками по их api/интерфейсам.
По более мелким типо отсутствия заливки фона в firefox, да, бесполезно.
Такие же наблюдения. Не понимаю где они берут специалистов с таким подходом?
Создалось мнение, что хорошие спецы попадают в большие компании будучи купленными в стартапах, а там где стартапов нет, там одни задроты-алгоритмены.
Но может это тоже работает? Нанимаешь абстрактного алгоритмена в вакууме и расширяешь необходимыми методами
Хотя, глядя на современный софт, и, даже фреймворки, разрабатываемые корпорациями, (привет гуглу и фейсбуку), которые, вообще, должны быть эталоном кода, понимаешь, что и там квалификация вайтишников на донышке.
ЗЫ опыт работы с пхп чуть больше года, уже три тикета на гитхабе aws php sdk создавал, и объяснял как им надо их баги исправлять… Мир катится в ад
Потому что вместо наема людей, которые решают практические задачи, компании нанимают гениальных сортирователей списков. В некоторых случаях алгоритм-мен оказывается квалифицированным, но в остальных… Нет ничего хуже кода, написанного абстрактным олимпиадником.
Ну тут есть важный нюанс: «алгоритм-мен» всегда может решить практическую задачу. Если захочет, конечно же. Последнее — важный момент, т.к. реально бывают кадры, которым это скучно, и они просто забивают болт на работу, но тем не менее, если человек в состоянии придумать алгоритм, то как реализовать что-то на конкретном фрейморке, он даже и не зная, уж точно способен нагуглить и правильно применить.
А вот обратное — уже проблема. Если человек владеет инструментами, но алгоритмы сочинять не умеет, то он застрянет на вполне себе практических задачах вида «отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты», которые не лежат в готовом виде на SO.
А вот обратное — уже проблема. Если человек владеет инструментами, но алгоритмы сочинять не умеет, то он застрянет на вполне себе практических задачах вида «отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты», которые не лежат в готовом виде на SO.
Ну возьмите одного такого на 50 человек в качестве консультанта, чего ж в этом плохого? Конечно, иногда и список развернуть надо, но с чего бы такое внимание именно на этом аспекте?
Три собеседования на одну тему, это и правда перебор, но можно и на одном погонять по умению собственно программировать, и никто от этого не помрёт, честно говоря. Зачем брать одного и заставлять его бегать за всей командой, если можно набрать почти всю команду людей, которые умеют программировать, благо, вышеуказанные задачки когда-никогда бывают у каждого.
Ну тут сразу два перебора получается: 1) спрашиваем три раза про одно и то же; 2) не спрашиваем больше ни о чём.
В некотором смысле каждый кулик своё болото хвалит — неудивительно, что люди, которые сильны в алгоритмах, считают, что это и есть самый важный и незаменимый навык. Но человек хорошо разбирающийся в железе или в особенностях того или иного языка/фреймворка /архитектуры тоже может доказать, что его навык самый главный. Тем более, что требования к алгоритмической задаче хорошо формализуются, и всегда можно найти если не своего, так внешнего консультанта, который это решит за лайки или за пиво.
Алгоритмы безусловно один из главных необходимых навыков, но далеко не достаточный, особенно когда он полностью оторван от прикладной области.
А собесы в Яндексе, по примерам очевидцев, создают впечатление, что с прикладной частью не сильно дружат. И для понимания и решения 90% прикладных задач среднего ИТ специалиста-программиста достаточно просто знания и понимания трех основных алгоритмов на пальцах. И основных структур данных. Что кстати не менее важно. И главное-их отображения и отработки системами. Остальное - доучивается в процессе работы и по мере необходимости, на опыте.
И почти по всем этим задачкам есть четкие рекомендации: не делать так, используйте стандартные средства языка.
Нужны совсем-совсем другие наыки, например, научиться использовать свое приложение. Знаете по моему сотни програмеров по миру делали рандомный лут в играх. Помню ровно одну игру с нормализацией на матожидание игрока и еще помню в диабло фикси на эту тему, все, в остальных «корейский рандом». Умные книжки на эту тему кстати есть.
Нужны совсем-совсем другие наыки, например, научиться использовать свое приложение. Знаете по моему сотни програмеров по миру делали рандомный лут в играх. Помню ровно одну игру с нормализацией на матожидание игрока и еще помню в диабло фикси на эту тему, все, в остальных «корейский рандом». Умные книжки на эту тему кстати есть.
А не подскажете, где можно почитать про оптимизацию лута? Интересно, не слышал об этом.
Например gdcuffs.com/unfr-rndm
Но в целом, это проблема постановки ТЗ со стороны геймдизайнера. Т.к. плотно сцеплено с UX, монетизацией и прочими вещами вне основной проблемной области программиста.
Но в целом, это проблема постановки ТЗ со стороны геймдизайнера. Т.к. плотно сцеплено с UX, монетизацией и прочими вещами вне основной проблемной области программиста.
Спасибо за ссылку, а может есть статейка о best practice с подробным техическим описанием?
Тут ничем помочь не смогу. Скорее всего опять же на геймдизайнерских ресурсах.
Потому что вот это «честное распределение» — оно опирается на субъективность восприятия и геймдизайнерам приходится с коэффициентами играться, чтобы с точки зрения игрока всё было как надо (ну и чтобы киты в итоге побольше донатили, куда без этого)
Потому что вот это «честное распределение» — оно опирается на субъективность восприятия и геймдизайнерам приходится с коэффициентами играться, чтобы с точки зрения игрока всё было как надо (ну и чтобы киты в итоге побольше донатили, куда без этого)
оно опирается на субъективность восприятия
Я понимаю. Но кроме того, если бы я лично, в своей игре, увидел провал заточки 10 раз подряд, при шансе 75%. Я бы разработчика конкретно этой части заставил эти шмотки сутками точить, до просветления.
(ну и чтобы киты в итоге побольше донатили, куда без этого
Нуда, кто же сейчас игры то хорошие делать будет, главноеж китовый донат, точно, я забыл)
провал заточки 10 раз подряд, при шансе 75%
А сколько раз максимум можно? 4? А почему не 3 и не 5? :)
Я бы сказал что в среднем для опыта игрока должно получаться 3. Если один игрок за свой игровой опыт многократно сталкивается с провалом 10 попыток из 10 — о каком 75% шансе вообще может идти речь?
Поймите, я понимаю проблематику, но я встречал разные реализации и оцениваю игру еще по такому показателю как «комфорт».
Поймите, я понимаю проблематику, но я встречал разные реализации и оцениваю игру еще по такому показателю как «комфорт».
для опыта игрока должно получаться 3.
Не для "опыта", а для "эмоциональных ожиданий". Игрок, имевший опыт бросания монетки или изучения теорвера, как раз имеет опыт что серии — это ожидаемое поведение. И если их нет — значит рандом "накручен", и ещё вопрос в какую конкретно сторону.
А вот эмоционально можно ожидать и что "5% шанс сломать не выпадет никогда, а 75% сработает точно".
как раз имеет опыт что серии — это ожидаемое поведение.
Все верно, и многократное 0 из 10 в это ожидание не вписывается от слова никак
в это ожидание не вписывается от слова никак
Да, это популярное заблуждение. С точки зрения эмоций — не вписывается. С точки зрения теорвера — это поведение рано или поздно обязано случиться. С точки зрения псевдорандомного генератора(а других не завезли) — оно случиться может.
Остаётся только делать не "честный рандом"(как того требуют эмоционирующие игрока) — а накручивать специальные "сбросы серий" и прочий мухлёж(да) чтоб эмоциональное ощущение не страдало.
Все верно, иначе никак.
При наивных реализациях нюансов слишком много и комфорт игры резко падает, да что там я в некоторых играх умудрялся вычислять временной диапазон, когда ГПСЧ работает на меня (энтропии видимо не хватает).
Кстати мы с вами говорим о достаточно высоких шансах, при низких такой треш начинается…
И на эту тему есть даже примеры:
— У La2 как раз был «не честный рандом» и шанс модифицировался в зависимости от попыток, в итоге даже шансы типо 1/65000 были вполне переживемы
— У LostArk судя по всему наивная реализация, наиболее показательный пример одна из коллекций собираемая шансово с ресурсов, она оказалась далеко за пределами матожидания для 95% игроков.
При наивных реализациях нюансов слишком много и комфорт игры резко падает, да что там я в некоторых играх умудрялся вычислять временной диапазон, когда ГПСЧ работает на меня (энтропии видимо не хватает).
Кстати мы с вами говорим о достаточно высоких шансах, при низких такой треш начинается…
И на эту тему есть даже примеры:
— У La2 как раз был «не честный рандом» и шанс модифицировался в зависимости от попыток, в итоге даже шансы типо 1/65000 были вполне переживемы
— У LostArk судя по всему наивная реализация, наиболее показательный пример одна из коллекций собираемая шансово с ресурсов, она оказалась далеко за пределами матожидания для 95% игроков.
А я бы сказал, что как раз апологеты подкручиваний в итоге привели ситуацию к тому, что публика начинает жаловаться на нейтральный ГПСЧ без подкручиваний.
В играх Blizzard нейтральный ГПСЧ остался только в серии Diablo, а остальные игры крутили его так дико, что особо умные игроки даже эксплуатировали это. Или вон при создании пользовательских карт в Warcraft 3, надо было использовать формулу пересчета вероятностей, чтоб обеспечить реальное статистическое соответствие между заданным значением, например, срабатывания абилки, и шансом появления этого в реальности. Задавать значение в 50% и ожидать срабатывания в половине случаев — было крайне наивно.
А нынче при столкновениях с нейтральным ГПСЧ в играх а-ля XCOM — у солидной части публики вдруг начинает пригорать. Ну как так, промах с 99% шансом попадания? Быть такого не может (с).
А я бы сказал, что как раз апологеты подкручиваний в итоге привели ситуацию к тому, что публика начинает жаловаться на нейтральный ГПСЧ без подкручиваний.
Низкие шансы позволяют тонко контролировать экономиу игры, ну и собственно редкие вещи должны быть редкими, но шмотка с шансом 1/100000 может и не выпасть вообще никогда, нам это не нужно. Кроме того я сам лично ходил в том же еверкест2 120 раз в данж за нужной мне шмоткой, я бы не назвал это приятным опытом. Или вон в том же лостарке сделали перенос доп эффектов на скилы с шансом, 2 уровень 30% (60 с расходкой) 4ый 0.5% — ничего более раздражающего давно не видел, особенно учитывая что это тупое и топорное решение для растягивания игры. Ну а про опыт в танках/кораблях я уже выше писал, опять же нет ничего более раздражающего чем какойто совершенно дикий разлет, не зависящий от твоего скила от слова совсем, который повторяется снова и снова.
В играх Blizzard нейтральный ГПСЧ остался только в серии Diablo
Не было его там никогда. У D2 лут строго привязан к локациям/боссам, а у д3 при инициализации игровой сессии усекалась лут таблица, выше описывал.
статистическое соответствие
А вот в том то и нюанс, выше по ссылке объяснение почему именно. Во первых нужно быть очень вниматньным к проверкам, потому что вам нужно линейное распределение. Во вторых: на какой дистанции? Никому даром не нужна игра где шмотка случайным образом падает 1 из 1000000 игроков.
А нынче при столкновениях с нейтральным ГПСЧ в играх а-ля XCOM — у солидной части публики вдруг начинает пригорать. Ну как так, промах с 99% шансом попадания? Быть такого не может (с).
Один — да ради бога, но только если он один из ста выстрелов. Но я думаю там далеко не так, раз игроки возмущаются.
Кстати у некоторых ГПСЧ на серверах я очень часто встречаю явно различимые временные интервалы в которых он ведет себя (не)предсказуемым образом. Тоже стоит учитывать откуда береться энтропия.
Не было его там никогда. У D2 лут строго привязан к локациям/боссам, а у д3 при инициализации игровой сессии усекалась лут таблица, выше описывал.
Тем не менее, сам ГСПЧ нейтральный. В том же варкрафте3 именно ГСПЧ постоянно "подкручивает" свои шансы в зависимости от предыдущих результатов.
Тем не менее, сам ГСПЧ нейтральный.
А никто и не говорит что только лишь им единым. Изза того что расчет выпадения лута в д2 ведется по локальным лут-таблицам с разумным шансом, гпсч не мешает. Так же точно в еверквесте мы никогда не парились насчет лута в рейд инстах, какая к черту разница если в списке 10-16 шмоток и каждый раз падает две. Но как только мы переходим к общим лут таблицам и маленьким шансам — вот тут и начинается веселье.
Задача — сделать хорошую игру, в которую играть приятно, комфортно. Какими средствами — вам решать. Но 95% современных разработчиков не понимает что это значит, потому что в свои игры не играет.
За промах по цели с угловым размером меньше прицела нужно руководителя разработки пытать, причем страшно и противно.
XCOMовсякая пошаговая война это шорткат. В «реальности»-то персонажи это испытывают как бы в реальном времени, а в реальном времени, вчерашнему рекруту, промахнуться в упор по страшному инопланетянену, который на тебя бежит в темноте из-за угла раз плюнуть.
Или попробуйте в какой-нибудь контре из снайперки в упор стрелять, рейт будет сильно ниже 95%
Или попробуйте в какой-нибудь контре из снайперки в упор стрелять, рейт будет сильно ниже 95%
Потому я играл не в контру а в кваку, где из рельсы в упор ты не можешь промахнуться — никак. Я вообще таких доводов не понимаю. Я могу промах понять на 100 метрах, на 20 понять могу, но когда мне нужно специально отвернуться чтобы промахнуться — нет не понимаю уже, потому что вчерашний рекрут даже закрыв глаза все равно попадет в район противника при таких угловых размерах.
Хотите делать промаху в упор? Смотрите в сторону d&d и спасбросков, «противник схватил винтовку за ствол и отвернул ее от себя!» с шансом на определенной дистанции, не будет так бесить и заставит держать стрелков на дистанции. (хотя схватить за ствол винтовку когда палец на спусковом крючке — ну такое, но это я на вскидку)
Хотите делать промаху в упор? Смотрите в сторону d&d и спасбросков, «противник схватил винтовку за ствол и отвернул ее от себя!» с шансом на определенной дистанции, не будет так бесить и заставит держать стрелков на дистанции. (хотя схватить за ствол винтовку когда палец на спусковом крючке — ну такое, но это я на вскидку)
Ну так там не 45% потому что. Это люди почему-то думают что 95% это 100%, когда это вообще-то 1 промах на 20 выстрелов. Но у нас же confirmation bias, мы неприятные промахи запоминаем, а предшествующие этому 19 попаданий нет, потому что считаем их нормой. Оттуда и идут эти разговоры.
О господи, ну я вам даже дал в пример другую игру, погуглите что ли, прежде чем рассуждать.
Включите JA2 в какой-нибудь «режим железной руки» и сыграйте там.
После чего включите xcom современный с их постоянными промахами при 95% чуть ли не в упор и расскажите мне, что это игроки играть не умеют и проценты не понимают.
Я играл. И я по прежнему нахожу ваш confirmation bias невероятно забавным. Вполне возможно, что вы просто относитесь к "не могущим в статистику" людям.
В JA2 при использовании того оружия, которое стреляет по разу за действие — всё то же самое. Более того, движок JA2 оперирует (как и XCOM) именно процентами успеха, а не "физической моделью", из-за чего криворукий наёмник вполне мог не попасть большей частью очереди из автомата в упор.
Но именно обилие стрельбы делает JA2 на вид "более честным", чем XCOM: когда ты в ход можешь выстрелить раза 2-3 даже из снайперки, один промах тебя не особо будет беспокоить. И уж тем более тебя не будет волновать промах пары выстрелов из очереди.
В XCOM же выстрелы — это очень ценные действия, и неудивительно, что каждая ситуация с промахом 5% поджигает определенные чувствительные части тебя некоторых людей.
Дааа. Именно. Криворукий.
Ну вот, а в XCOM меткий оперативник, достигающий шансов попадания в 100% — не мажет. Вообще никогда.
Другое дело, что у продвинутых элиенов есть всякие свойства, минусующие шансы попадания по ним.
Только берём спеца, то даже очередями промахи снижаются весьма сильно.
Ну так и в XCOM нуб со базовым шансом попасть в 65% и профи — с 110% — это очень разные вещи.
Там и одиночные промахи бывают, при высокой вероятности попасть. Но это именно что несистемные случаи.
Ну то есть в JA2 "несистемные", а в XCOM "системные". Понятно. Так и запишем.
Только в искоме очередь вся улетает в молоко.
Потому что очереди не моделируются. "Выстрел" в терминах механики XCOM всегда один, а как он там анимируется — дело десятое.
Но претензии к условностям механики пошагового боя меня очень забавляют. Это пошаговый бой, уже дикая условность, которая абсолютно никак не натягивается на реальность. И при этом вас беспокоит отсутствие честной симуляции очередей? Ну-ну.
Это как придти жаловаться шахматистам, что ладья как-то нереалистично ходит.
патчи таки были, но 100% — это обратный идиотизм.
разговор про 95%, хватит пытаться уводить в сторону.
Эм. В XCOM:EU и XCOM2 шансы попадания не ограничены сверху. Там нет потолка в 95%.
Вот стоит группа и стреляет по одному. Все имеют большие шансы попасть, все промахиваются.
Пруфы? Давайте начнем хотя бы с 4 5% промахов в ряд — это целых 0.000625% шансов, вполне вероятно, что среди всех сыграных партиий в XCOM за всё время такая ситуация возникала, и кто-то выложил её в интернет, а то и может быть даже и не одну. Если же у вас "всё реализовано неправильно", то таких ситуаций должно быть по-вашему — сколько? Тысячи? Десятки тысяч? Короче, выложить сюда хотя бы пару дюжин не должно составить для вас никакого труда.
О, люблю предметный разговор!
Итак:
Видео №1: нубы или около того (средняя базовая меткость: 65%) стреляют в овервотче (x0.7 от финального шанса попасть) по солдату в half-cover (-20%, многие думают, что в overwatch бонусы от укрытия не применяются, но это не так) в упор из винтовок (+19-20%). Это если конечно там модами что-нибудь из этого не переделано.
Итого у каждого шанс попасть — около 45%. Три раза подряд промахнуться — ~16%.
Видео №2:
Ну да, это full cover. В ванильке нет никаких бонусов за "частичный" фланг. Плюс, судя по времени видео, это совсем ванилька, с её приятной механикой критов (это когда при, допустим 15% шансах попасть и 15% крита любое попадание становилось критом). Потом эту механику переделали в WoTC, кстати.
Видео №3:
В XCOM:EU отображаемые шансы попадания псионикой всегда жили своей жизнью. Это баг, который долго и мучительно устраняли из Long War, я c этой историей лично сталкивался. А в ванильке его никто не чинил, по-моему.
Видео №4:
Ну и что такого? Это вероятности в районе 0.1% (а не 0.000625%, как я вам предложил найти), с учётом объемов сыграных игр таких видосиков легко могут быть сотни.
Видео №5:
Ничего необычного, классическая нубоошибка на гейткрашере — сидеть в half-cover, которое дает всего лишь -20% и надеяться на овервотч, который х0.7 к финальному шансу попадания и в силу этого даже с крыши работает так себе. И да, я нахожу панику в ванилле XCOM2 реализованной невероятно тупо, это про дальнейшее.
Ну а уж мемасики «xcom симулятор промахов»
Люди в среднем не могут в статистику, ага.
Было бы наоборот удивительно, если б при популярности XCOM таких мемасиков бы не было.
И да, я тоже нахожу симуляцию тактического боя в джаге — гораздо более цельной и приятной, чем в XCOM:EU и особенно в XCOM2.
(AI там нисколько не лучше, но именно с точки зрения отсутствия странных правил и формул всё намного лучше)
Просто это всё ортогонально честности ГПСЧ. Рандом абсолютно честный и там и здесь. Вернее, в XCOM он нечестен (на легких сложностях) как максимум в пользу игрока, и никогда наоборот.
При этом так же есть ксенонавты, где такого убожества нет.
Так что это не «люди не запоминают», это просто отмазки, что раз типа теория вероятности позволяет делать серии из промахов при 90%, то это нормально такие серии получать постоянно. Неа, тервер говорит, что если у вас 99 постоянных решек, то скорей всего проблема в монете.
Нет, тервер говорит что монета не имеет памяти, а 90% попадание означает что каждый 10й будет промах. Но если люди попадали с 90% вероятность 100 раз подряд а 101-110 промахивались — они побегут доказывать что игра сломана и подставляет их чтобы они не могли выиграть. Хотя зачем разработчикам это делать — непонятно. Видимо чтобы всех побесить побольше
вероятность серии из нескольких промахов подряд подсчитайте при 95%? а теперь вероятность такую серию получать периодически? Ну, когда у вас отряд из 5-8 человек выстрелили и при хороших шансах все промахнулись
Она не ноль — вот и все.
Тем, что у них AI врагов отсутствует как класс. В JA2
Для этого можно было бы ограничить абсолютную точность для людей в 70% например а не врать что она 95.
Пока что все "пруфы" что я видел — от непонимания теорвера. У людей если монетка 10 раз орлом падает — это невозможно и монетка кривая. Все же знают забавную задачку на подбросить монетку и потом записать результаты бросков на бумажку — хороший профессор теорвера всегда знает какой студент правда бросал, а какой просто от балды написал "типа случайные броски".
Не знаю, вот в RF Online зависело от загруженности серверов — рано утром точится, вечером сгорает, в среднем по больнице нужные проценты, но о каком случайном распределении тут можно говорить?
Если хотите генератор псевдослучайных чисел близкий к идеальному нужно использовать криптографические оценки «случайности» последовательностей.
Если хотите генератор псевдослучайных чисел близкий к идеальному нужно использовать криптографические оценки «случайности» последовательностей.
Это не только в рф это много где так. Вы думаете средний разработчик в курсе как выглядит энтропия у рандомизатора под капотом? Да я думаю слов они не знают таких. И, по сути, они не виноваты, им просто нужен талантливый, умный, увлеченный руководитель.
Просто как seed нужно использовать младшие разряды нагрузки, а не старшие.
Да, я думал это все в институте проходят.
Да, я думал это все в институте проходят.
Или генератор белого шума, и не забывать про нормальное распределение.
Ну я в институте не проходил, но это никак не мешает литературу читать. Хотя о чем мы, сейчас расплодилось аналитиков/пм как грязи, вот только от первых я регулярно вижу блоки условий с кучей веток и отсутсвием внятного описания сравнений, а вторые почтив се тупо играют в передастов. Профильную литературу никто даже не пытается изучать.
Ну я в институте не проходил, но это никак не мешает литературу читать. Хотя о чем мы, сейчас расплодилось аналитиков/пм как грязи, вот только от первых я регулярно вижу блоки условий с кучей веток и отсутсвием внятного описания сравнений, а вторые почтив се тупо играют в передастов. Профильную литературу никто даже не пытается изучать.
Программный генератор белого шума нужно еще оценить по критериям «случайности», и, кстати, распределение не обязательно должно быть нормальным — тут уж как гейм дизайнер видит.
Новые менеджеры это боль — модно стало считать, что менеджеру/руководителю не нужно понимать предметную область. Рука-лицо.
Новые менеджеры это боль — модно стало считать, что менеджеру/руководителю не нужно понимать предметную область. Рука-лицо.
Зачем программный? Вроде в современных процессорах есть аппаратный.
С нормальным распределением все проверки должны его учитывать, иначе вы вероятность сосем не ту получите какую планировали.
Вот тото и оно, почему то вдруг все решили что могут руководить чем угодно. Теперь модные термины «цифровизация», «гипотезы», «верхний уровень» и прочий булшит. А на самом деле как пытались перестроить сарай в международный аэропорт, так оно все и осталось.
С нормальным распределением все проверки должны его учитывать, иначе вы вероятность сосем не ту получите какую планировали.
Вот тото и оно, почему то вдруг все решили что могут руководить чем угодно. Теперь модные термины «цифровизация», «гипотезы», «верхний уровень» и прочий булшит. А на самом деле как пытались перестроить сарай в международный аэропорт, так оно все и осталось.
Тут еще проблема в чём — если сделать неаккуратно, открывается широкое поле для багоюза.
Например точим дешевые палки-копалки пока 3 раза подряд не сломается, а потом затачиваем мифрильные трусы +8. Ура, мы порушили экономику.
Значит придется более сложные данные хранить и мы только что на ровном месте усложнили всю систему. А глобальный беспристрастный рандом такой проблемы иметь не будет :)
Например точим дешевые палки-копалки пока 3 раза подряд не сломается, а потом затачиваем мифрильные трусы +8. Ура, мы порушили экономику.
Значит придется более сложные данные хранить и мы только что на ровном месте усложнили всю систему. А глобальный беспристрастный рандом такой проблемы иметь не будет :)
Да ладно вам чего мы там усложнили, у многих игр итак есть 100% ная заточка после Н попыток, прям с отображением игроку.
При заточке предмет ломается. Так что когда 10 раз подряд фейлится 75% шанс — ломается 10 разных (одного типа) предметов.
Значит для каждого игрока придется заводить записи в БД: «неудачных заточек медных мечей», "«неудачных заточек железных мечей» и т.п.
Ну чтобы когда у него 7й медный меч сломается на 8й раз точно получилось, но при этом он не мог мифрильный меч проточить с 100% гарантией.
Значит для каждого игрока придется заводить записи в БД: «неудачных заточек медных мечей», "«неудачных заточек железных мечей» и т.п.
Ну чтобы когда у него 7й медный меч сломается на 8й раз точно получилось, но при этом он не мог мифрильный меч проточить с 100% гарантией.
При заточке предмет ломается. Так что когда 10 раз подряд фейлится 75% шанс — ломается 10 разных (одного типа) предметов.
В моем примере нет, не ломается. Вообще механика слома все реже появляется нынче.
Просто в LostArk есть тн «фетранит» который как раз «точится» красиво так, в рядочек, с уменьшением шанса на каждую попытку и сам я встречал и у знакомых и у стримеров можно найти где заходишь и так ррраз всю полосочку зафейлил.
Оох, сходу не скажу, я когда эмулятор сервера l2 лет 15 назад писал, много литературы перечитал и оказалось что очень многое уже изучено и описано, с тех пор почитываю но у меня память на названия такая себе.
Попробую найти, если получиться — кину, но не гарантирую. А вообще я пря мотчетливо помню, что была статья по лут в d3. Там был интересный нюанс, что разработчики при инициализации игровой сессии усекали лут-таблицу и соответственно вышло так, что если тебе не повезло и твоя шмотка не в списке этой сесии то ты можешь хоть запроходится рифты, шмотка нужная тебе просто не упадет. Это стало совсем очевидным когда за осколи стало можно конкретную часть доспеха покупать, вот тут то и выпустили фикс, насколько я помню фиксом была периодическая реинициализация лут-таблиц в рамках игровой сессии.
Вообще я бы с удовольствием почитал сам о наилучших практиках работы с ГПСЧ. Мало кто вообще об этом задумывается, но ГПСЧ подбирать нужно под конкретные цели. Самый яркий пример: отреверсил в одной игрульке как раз такую проверку и прогнал 100 симуляций на матожидании игрока (ну пусть будет 100 попыток), выяснилось что фактический шанс в 10 раз ниже заявленного, хотя по коду это совсем не очевидно.
В этом плане меня варгейминг веселят «вот посмотрите, мы сделали 100 выстрелов на нашем тестовом контролируемом сервере, 80% как и заявлено попадает в круг.» Вот только мишень плоская и вертикальная, сервер тестовый, а количество выстрелов сильно завышено. Я что в танках что в кораблях попадал в игры где в течении игры _каждый_ выстрел летит куда попало. Да можно сказать что шансы все такое и «неповезло» но когда вы разрабатываете игры вы должны такие вещи находить и устранять, поскольку нет ничего более раздражающего и демотивирующего.
Попробую найти, если получиться — кину, но не гарантирую. А вообще я пря мотчетливо помню, что была статья по лут в d3. Там был интересный нюанс, что разработчики при инициализации игровой сессии усекали лут-таблицу и соответственно вышло так, что если тебе не повезло и твоя шмотка не в списке этой сесии то ты можешь хоть запроходится рифты, шмотка нужная тебе просто не упадет. Это стало совсем очевидным когда за осколи стало можно конкретную часть доспеха покупать, вот тут то и выпустили фикс, насколько я помню фиксом была периодическая реинициализация лут-таблиц в рамках игровой сессии.
Вообще я бы с удовольствием почитал сам о наилучших практиках работы с ГПСЧ. Мало кто вообще об этом задумывается, но ГПСЧ подбирать нужно под конкретные цели. Самый яркий пример: отреверсил в одной игрульке как раз такую проверку и прогнал 100 симуляций на матожидании игрока (ну пусть будет 100 попыток), выяснилось что фактический шанс в 10 раз ниже заявленного, хотя по коду это совсем не очевидно.
В этом плане меня варгейминг веселят «вот посмотрите, мы сделали 100 выстрелов на нашем тестовом контролируемом сервере, 80% как и заявлено попадает в круг.» Вот только мишень плоская и вертикальная, сервер тестовый, а количество выстрелов сильно завышено. Я что в танках что в кораблях попадал в игры где в течении игры _каждый_ выстрел летит куда попало. Да можно сказать что шансы все такое и «неповезло» но когда вы разрабатываете игры вы должны такие вещи находить и устранять, поскольку нет ничего более раздражающего и демотивирующего.
Интересно было бы почитать про рандом из мира CS. Такое ощущение, что там коэффициент удачливости устанавливался на запуске игры, потому что было проще перезапустить CS, чем мучиться с не попадающими никуда пулями))
Контра же? Пули летят по 2 параметрам, условно, отдаче и разбросу. Отдача — алгоритм смещения без рандома, зависит от непрерывности огня и вида оружия(глушителя). Делится на 2 части, одна — просто кривой подъём вверх, вторая — особенности смещения оружия.
Разброс относительно точки последнего выстрела с поправкой отдачи, рандомный, обычно на много меньше отдачи. Зависит от движения и положения, непрерывности огня, вида оружия, глушителя. Последний обычно на много меньше отдачи, возможно раз в 10, возможные исключения — пулемёт, снайперка без прицела.
Вообще, в CS норма — минимально зависеть от рандома, отдачу контролировать заранее(смещать прицел вниз ~ по траектории отдачи), и даже разброс. Последнее вполне контролируется, т.к. следующий выстрел не заново рассчитывается в большом радиусе, а идёт относительно предыдущего в довольно маленьком радиусе.
PS: всё это отличается от версии, хотя база +- похожа. Потому и не люблю CS — повторение одной и той же механики как путь к победе.
Разброс относительно точки последнего выстрела с поправкой отдачи, рандомный, обычно на много меньше отдачи. Зависит от движения и положения, непрерывности огня, вида оружия, глушителя. Последний обычно на много меньше отдачи, возможно раз в 10, возможные исключения — пулемёт, снайперка без прицела.
Вообще, в CS норма — минимально зависеть от рандома, отдачу контролировать заранее(смещать прицел вниз ~ по траектории отдачи), и даже разброс. Последнее вполне контролируется, т.к. следующий выстрел не заново рассчитывается в большом радиусе, а идёт относительно предыдущего в довольно маленьком радиусе.
PS: всё это отличается от версии, хотя база +- похожа. Потому и не люблю CS — повторение одной и той же механики как путь к победе.
Это да, но мне сложно иначе объяснить, что я проигрываю раунд за раундом — перезапускаю CS и начинаю выигрывать так же стабильно. Возможно, какой-то сетевой лаг меняется, но больше похоже, что именно "удачливость" меняется.
Я кстати бросил играть в CS еще на заре его становления ка краз потому, что мы в клубах научились стрелять в голову из АК зная точку прицела под ногами и размер нужной очереди. Очень утомляет такая механика, потому я квакер)
был в солнечном 19-м году в яндексе на собесе по java, было 4 секции — алгоритмы, структуры данных
технологии -sql, networks etc
java core (multithreading, core libraries)
интервью с менеджером и командой
впечатление субъективно такое — спрашивают по технической части по делу, вопросы интересные и полезные для саморазвития, но достаточно тяжело — где-то 4 часа это длится, и мутные параметры найма, видимо все же они ищут звезд, готовых на переработки и не очень задорого (за бренд Яндекс в трудовой), насколько знаю у них зп остает от рынка
технологии -sql, networks etc
java core (multithreading, core libraries)
интервью с менеджером и командой
впечатление субъективно такое — спрашивают по технической части по делу, вопросы интересные и полезные для саморазвития, но достаточно тяжело — где-то 4 часа это длится, и мутные параметры найма, видимо все же они ищут звезд, готовых на переработки и не очень задорого (за бренд Яндекс в трудовой), насколько знаю у них зп остает от рынка
В Яндексе кроме зп ещё программа поощрения RSU, и значительная часть дохода идет от их вестинга.
Где-то слышал/читал, что опционы получает небольшая часть сотрудников ~17%, возможно самые выдающиеся, например здесь https://www.vedomosti.ru/technology/articles/2015/04/02/yandeks-predlagaet-sotrudnikam-otvyazat-optsioni-ot-kapitalizatsii-kompanii
Или есть другая инфа?
И что, этот один будет весь код в компании ревьювить и искать, где разработчик не заметил алгоритмическую задачу?
Если же этих алгоритмистов нанимать несколько, то дешевле всех остальных уволить и пусть алгоритм-мены все сами и пишут.
Ну это называется straw man: я вот, положим не олимпиадник, но уж «не заметить алгоритмическую задачу» — это удел тех, кто ни разу книгу Кормена (или аналог) не открывал и вообще «в танке». Таких брать, конечно, незачем, но для навыка «заметить задачу» планка не столь уж и высока, таким людям по-хорошему даже диплом бакалавра соответствующей специальности не должен был быть выдан.
Ну "алгоритмическая" задача ничем особо не отличается от обычной! Вот надо вам, допустим, найти одинаковые элементы в двух наборах данных. И тут человек не натасканный на эти задачки с интервью вполне может использовать 2 списка и проверять на вхождение через стандартную библиотечную операцию, получая O(n^2). Возникнет ли у него тут позыв послать эту часть алгоритм-мену? Казалось бы все тупо. Надо взять элементы из первого набора, которые есть во втором. Так и сделано.
Ну так любой человек, хоть раз открывавший Кормена (или аналог) знает, что O(N^2) в общем случае получаться не должно — и тут либо он напоролся на известный алгоритм вот с такой сложностью, и тогда страдать, или что-то он действительно делает не так. И понимание «не так» уже тогда должно как-то звякнуть в голове, и придётся попросить помощи, если он сам не понимает, как решить задачу.
Наверно, я идеализирую «среднего» человека, и у слишком многих в голове ничего не звякнет, но всё же по моим понятиям такое «звяканье» — это на порядок менее жёсткое требование, чем быть реальным алгоритмистом. Ну опять-таки, разве хоть кто-то в здравом уме будет против того, чтобы люди умели писать алгоритмы и вообще думать головой? Тут же весь дискурс исключительно в контексте того, что этому умению придаётся 100% важность, а остальному 0%, как будто бы его не существует. Если завтра по каким-то причинам во главе яндекса окажутся знатоки математики, то точно так же будут собеседовать, спрашивая умения брать интегралы в уме или решать задачи трёхмерной геометрии. Ведь понятно, что если человек не может взять интеграл, то он в целом безнадёжен, можно дальше не смотреть. А если может, остальному тоже научится.
Наверно, я идеализирую «среднего» человека, и у слишком многих в голове ничего не звякнет, но всё же по моим понятиям такое «звяканье» — это на порядок менее жёсткое требование, чем быть реальным алгоритмистом. Ну опять-таки, разве хоть кто-то в здравом уме будет против того, чтобы люди умели писать алгоритмы и вообще думать головой? Тут же весь дискурс исключительно в контексте того, что этому умению придаётся 100% важность, а остальному 0%, как будто бы его не существует. Если завтра по каким-то причинам во главе яндекса окажутся знатоки математики, то точно так же будут собеседовать, спрашивая умения брать интегралы в уме или решать задачи трёхмерной геометрии. Ведь понятно, что если человек не может взять интеграл, то он в целом безнадёжен, можно дальше не смотреть. А если может, остальному тоже научится.
Ну хорошо, допустим эти звоночки происходят практически во всех нужных случаях. Тогда неизбежно false positive. Все равно наличие выделенных алгоритм-менов сильно усложняет работу. Они будут завалены заявками. Имея гугловую поток кандидатов гораздо легче тупо нанимать только алгоритм-менов.
Ну мы же обсуждаем некую карикатурную картину, когда наш кодер настолько непроходимо тёмен, что неспособен взять книжку с полочки и скопировать классический алгоритм к себе в программу. С тем же успехом тогда надо представлять себе карикатурного «алгоритмена», который ни в зуб ногой в архитектуре, и потом надо ещё иметь специально обученного человека на него для постоянного рефакторинга, ну и поскольку он в фрейморках/проч. тоже ни в зуб ногой, то в основном он сидит и курит мануалы, вот так и день проходит.
Но это, конечно, так, вырожденный пример, в идеале, конечно, на каком-то уровне надо уметь всякое разное, как мне кажется.
Но это, конечно, так, вырожденный пример, в идеале, конечно, на каком-то уровне надо уметь всякое разное, как мне кажется.
С тем же успехом тогда надо представлять себе карикатурного «алгоритмена», который ни в зуб ногой в архитектуре, и потом надо ещё иметь специально обученного человека на него
И… такой человек как раз есть практически везде. Называется архитектор, technical lead, или еще как-то.
Разность в том, что задачки, "алгоритмические" или нет, постоянно решает любой, кто пишет код. Любой код — это алгоритм. Любые данные — это структура данных. Очень часто тривиальные, да.
Когда надо составить SQL запрос — тут, очевидно, нужен специалист по SQL, можно спросить его. Когда надо придумать, как организовать новый модуль, то очевидно, что это архитектура проекта — надо спросить архитектора.
А когда надо писать код, очевидно, надо спросить алгоритм-мена в команде. s/
Конечно, в идеале все в команде специалисты во всех областях. Но это слишком дорого держать такую команду, да и тогда надо 100500 собеседований проводить и не наберешь столько работников, даже с гугловым потоком кандидатов.
Вообще-то SQL обычно пишут все. И никаких отдельных специалистов по нему нет. В том же Я у меня была секция с вопросами про SQL, когда я устраивался.
Включая фронтов?
К тому же, бэкендеры/фуллстеки на SQL чистом тоже уже довольно давно не пишут — сегодня это всё чаще ORM, который и будет генерировать некую лапшу запроса.
К тому же, бэкендеры/фуллстеки на SQL чистом тоже уже довольно давно не пишут — сегодня это всё чаще ORM, который и будет генерировать некую лапшу запроса.
Эмм, вы тут поосторожнее с такими заявлениями. Если человек работает с ORM, то лучше бы ему знать во что запрос превратится.
Включая фронтов?
Ну давайте еще до уборщиков дойдем с примерами. Статья вообще про бэкенд и Django. Да и фронтенд сейчас тоже может запросы делать иногда — graphQL и тп.
Если человек работает с ORM, то лучше бы ему знать во что запрос превратится.
Чтобы это знать, надо знать как работает конкретный ORM.
Итого, получается, надо проверять эти моменты:
1) человек умеет пользоваться ORM
2) знает, как он устроен и как он делает трансляцию из модели в запрос
3) знает, как работают SQL запросы
4) и умеет их писать, на случай, если ORM'a нет.
Отлично. Я согласен 100% с этим. Но вы мне возразили или согласились?
С тем же Django постоянно приходится залезать внутрь и смотреть как он там это все делает. Каждый запрос надо знать как выполняется, не забывать про транзакции и тп.
Согласился или возразил зависит от того, кого мы нанимаем, на какой участок работы и за какие деньги.
Если у нас вакансия Django dev'a уровня junior'a — достаточно 1 и, желательно, 4. По мере роста — 2 и, желательно, 3.
Почему так? Потому что за 3 отдельные люди получают кучу денег. Не считаю, что рядовой разработчик должен уметь это, да еще и хорошо уметь. К тому же, учитывая что СУБД у нас больше 1 (MS SQL, Oracle, MySQL, PostgreSQL).
Если у нас вакансия Django dev'a уровня junior'a — достаточно 1 и, желательно, 4. По мере роста — 2 и, желательно, 3.
Почему так? Потому что за 3 отдельные люди получают кучу денег. Не считаю, что рядовой разработчик должен уметь это, да еще и хорошо уметь. К тому же, учитывая что СУБД у нас больше 1 (MS SQL, Oracle, MySQL, PostgreSQL).
Прошу прощения. Конечно, я имел в виду "все бэкендеры". А писать SQL, HQL или Criteria собирать — это уже дело десятое. Один фиг, если тормозить будет, то придётся посмотреть, какой SQL генерируется и какой у него план выполнения.
А потом frontend девелопер генерит себе backend JHipster-ом и захреначивает динамический lazy scrolling (тот который SELECT по rownum) и один юзер с мышкой вешает и backend и базу простым движением руки.
Вот после того, как sql-запросы попишут все, и приходит четкое до звона понимание, что специалиста надо было брать сразу, а не когда уже пришла катастрофа.
Ситуация в Яндексе, кстати местами именно такое впечатление и производит. Все умеют проходить алгоритмические секции, а практически любое решение переделывают каждые несколько лет, т.к. оказалось, что архитектура достаточно жёсткая, чтобы проще было с нуля переписать. Или под конец моей там работы был случай, когда ради оптимизации в одном из компонентов решили кардинально поменять его АПИ, чем вынудили всех клиентов этого компонента переписывать довольно много кода. И ни у кого ничего не "звякнуло" ведь. Хотя теоретически, если есть сомнения по архитектуре, то можно сходить на специальный "Архитектурный комитет" и там её обсудить. Просто сомнений обычно нет, да и "зачем время тратить?" — лучше потом два раза переделать)
Вот на чем такие утверждения основаны интересно. Типа я вот щас пошел, посидел три месяца на leetcode и вуаля я готовый сеньор-помидор и знания об архитектуре, базам данных, паттернах программированиях и еще 20+ навыков необходимых для современной разработки у меня автоматически вмонтировались в голову?
Мне это напоминает мем, про то как писатель написал, что занавески синие, а все думают и гадают, что же он имел в виду, может он хотел символизировать тоску и деперессию? Хотя на самом деле ничего кроме того, что занавески были «синие». Так и с яндексом. Ввели они эти собеседования, потому что по ним можно прозрачно оценить прошел ли интервьювер собеседование или нет. Решил задачу лучшим решением, без ошибок написал код — прошел. Нет — не прошел, а то, что к реальному миру эта задача имеет отношение чуть более чем косвенное, ну лучше пока не придумали. А все вокруг бегают и строят теории: да эти задачи показывают как программист мыслит, да яндексу нужны алгоритмисты, да алгоритмисты могут решать любые задачи. Увы нет, всё гораздо проще.
Мне это напоминает мем, про то как писатель написал, что занавески синие, а все думают и гадают, что же он имел в виду, может он хотел символизировать тоску и деперессию? Хотя на самом деле ничего кроме того, что занавески были «синие». Так и с яндексом. Ввели они эти собеседования, потому что по ним можно прозрачно оценить прошел ли интервьювер собеседование или нет. Решил задачу лучшим решением, без ошибок написал код — прошел. Нет — не прошел, а то, что к реальному миру эта задача имеет отношение чуть более чем косвенное, ну лучше пока не придумали. А все вокруг бегают и строят теории: да эти задачи показывают как программист мыслит, да яндексу нужны алгоритмисты, да алгоритмисты могут решать любые задачи. Увы нет, всё гораздо проще.
Вот на чем такие утверждения основаны интересно. Типа я вот щас пошел, посидел три месяца на leetcode и вуаля я готовый сеньор-помидор и знания об архитектуре, базам данных
Типа вот нет. Этого я не утверждал. Одних алгоритмов, естественно, недостаточно для того, чтобы понять набор скиллов кандидата. Не надо искать скрытый смысл в моих словах, там написано ровно то, что я имел в виду: что человек, умеющий составлять алгоритмы, всегда может работать программистом при желании. Человек, не умеющий их составлять, не всегда, ряд задач будут ему недоступны. Поэтому умение придумывать алгоритмы лучше проверять, чем не проверять.
По-моему вы домысливаете. Человек умеющий составлять алгоритмы, может составлять алгоритмы. Человеку не умеющему составлять алгоритмы недоступны задачи на алгоритмы. Умение придумывать алгоритмы лучше проверять, если вам нужно умение составлять алгоритмы, если вам нужно что-то другое, лучше проверять что-то другое.
Речь о том, что умение составлять алгоритмы — это единственный навык для программиста, который нельзя вот так взять и получить в любое время по потребности, просто открыв поисковик.
А что, с ним рождаются? Что за уникальный навык такой, которому нельзя научить?
Умение хорошо понимать, как работает конкретный используемый инструмент — не просто, условно, «ну это база данных, она данные хранит» — тоже нельзя получить, просто открыв поисковик. И уж тем более, просто открыв поисковик, нельзя научиться это знание применять к конкретному вашему проекту.
Ну тут есть важный нюанс: «алгоритм-мен» всегда может решить практическую задачу. [...]Разумеется нет.
А вот обратное — уже проблема. Если человек владеет инструментами, но алгоритмы сочинять не умеет [...]
«Алгоритм-мен» никогда не сможет решить практическую задачу. Потому что он наловчился только списки сортировать. А опыту за пределами алгоритмов откуда взяться?
А вот обратное как-раз таки верно. Если инженеру нужно отсортировать список, он откроет справочник
А опыту за пределами алгоритмов откуда взяться?
Хм. На SO, например. Какой там опыт нужен? Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.
Если инженеру нужно отсортировать список,
Я же прям в моём посте указал пример совершенно обыденной повседневной задачи, решения которой нет в справочнике объемов зелёных резиновых мячей, и на которой запнулся реальный чувак, который не умел писать алгоритмы.
Для решения вашей повседневной задачи не нужны алгоритмы, нужно как раз умение решать повседневные задачи, те поговорить с менеджером, выяснить, что достаточно взять последний звонок клиенту и посмотреть дату следующего прозвона для этого звонка. Какие тут алгоритмы?
те поговорить с менеджером, выяснить
В смысле, менеджер должен рассказать программисту, как ему данные выбирать?
достаточно взять последний звонок клиенту и посмотреть дату следующего прозвона для этого звонка
У последнего, например, дата прозвона может быть не заполнена. Не суть важно, дело в том, что это тоже алгоритм, пусть и нехитрый. Здесь тоже надо включать мозги и думать, как корректнее реализовать.
В смысле, менеджер должен рассказать программисту, как ему данные выбирать?
Конечно, откуда может рядовой разработчик знать о текущем бизнес процессе?
Да, менеджер расскажет что искать, ибо даже в такой постановке задачи есть два варианта что искать — просто максимальную дату прозвона для каждого клиента или все же дату прозвона у последнего звонка. Эти даты могут отличаться. Те это формулирование начальных и граничных (не у всех звонков может быть дата прозвона) условий. Это как раз умение решать практические задачи, а не алгоритмические.
А после формулирования условий остается написать нужный SQL запрос, что во-первых, тоже не алгоритмическая, а практическая задача, а во-вторых при определенном навыке решения практических задач уже ищется в гугле.
Любой код можно назвать алгоритмом, конечно. Только вот под "алгоритм-меном" подразумеваются совсем другие алгоритмы и люди. И вот "алгорим-мен" может не догадаться, что пришедшую задачу нужно обсудить с постановщиком, а так же с тем, кто пользоваться будет. Ему вообще прикольнее задачки на сайтах решать, а не с менеджерами общаться. А практик сделать может не оптимально, зато формочку удобную нарисовать в итоге и больше профита компании доставить.
не буду лезть в ваш спор про то, что лучше, лишь уточню, что на собеседовании помимо правильного решения смотрят на то, какие вопросы задаёт кандидат. Решение может быть неидеальным и иногда даже не до конца правильным, но если кандидат задаёт толковые вопросы по граничным условиям и т.д. — это идёт ему в плюс и может помочь пройти на след этап
Действительно. Нафига нужны архитекторы, нафига нужен опыт? Берем студента, дрочим его пару месяцев на сортировку список и отправляем какую-нибудь распределенную систему писать, со сложной, меняющейся бизнес-логикой и большой нагрузкой. Главное, что он деревья вращать умеет, а остальное на SO найдет.А опыту за пределами алгоритмов откуда взяться?Хм. На SO, например. Какой там опыт нужен?
Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.Хорошая шутка, но я тоже так умею. Назовите задачку на алгоритмы, которую нельзя взять и нагуглить.
Я же прям в моём посте указал пример совершенно обыденной повседневной задачи, решения которой нет в справочнике объемов зелёных резиновых мячей, и на которой запнулся реальный чувак, который не умел писать алгоритмы.Вы стебетесь надо мной сейчас?
Продублирую тут вашу задачу, чтобы далеко не ходить:
>«отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты», которые не лежат в готовом виде на SO.
Какие тут вообще алгоритмы? Мне справочник по SQL за вас нагуглить? Нет проблем: www.postgresql.org/docs/current/sql-select.html
Хорошая шутка, но я тоже так умею. Назовите задачку на алгоритмы, которую нельзя взять и нагуглить.
Напишите алгоритм обхода массива двумерных массивов (трехмерного массива), таким образом, чтобы алгоритм обхода этого массива рисовал круг на проекции 120*120*120.
1) Нагугливаем вычисление, где расположится точка [x, y, z] на проекции 120120120 (это вроде бы изометрическая проекция?)
2) Нагугливаем алгоритм Брезенхэма для окружности.
3) ???
4) PROFIT!
Нужно нагуглить два алгоритма и успешно их скрестить :)
И?
Данная задача — пример того, что нужно а) определить какие алгоритмы подойдут для решения ситуации (непросто, особенно если человек геометрию в последний раз в школе видел) б) найти их (изи, если знать, что искать) в) правильно выстроить взаимодействие между ними, что предполагает хотя бы минимальные практические навыки (чуть сложнее).
Т.е. конкретно для этой задачи нельзя просто так взять и копипастнуть готовое решение со StackOverFlow как FizzBuzz. Там нет решения.
Т.е. конкретно для этой задачи нельзя просто так взять и копипастнуть готовое решение со StackOverFlow как FizzBuzz. Там нет решения.
> Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
Заменить алгоритм jpeg на jpeg-turbo. Обещают быстре 2х-6х в зависимости от платформы и параметров, поддержка arm есть. Есть шанс уложиться даже в один поток.
Хорошая мысль, а если не прокатит?
Иногда можно кадры дропать (ведь можно спросить?), если картинка не очень динамичная (ведь с новой библиотекой не хватает чуть чуть). Или переиспользовать пожатые куски для неизмененных пирамид, которые скорее всего будут. (если контроллер дешевый то вероятно и камера дешевая, следовательно iso и выдержка скорее всего никудышние и такие куски скорее всего будут).
Тоже можно. А еще?)
- Можно в лоб — сделать очередь задачек (одна задача — один кадр) и 3-4 потока (ну, правда, нужны и 3-4 не сильно занятых ядра), которые будут брать кадры из очереди, сжимать и складывать в другую очередь. Будет 30 fps, но с задержкой в те самые 0.08 сек или даже больше. При переполнении очереди задач можно дропать слишком старые кадры.
- Можно потюнить алгоритм (насколько я помню, в jpeg есть разные режимы сжатия, цветовые компоненты могут с меньшим разрешением храниться и сжиматься это тоже будет быстрее). Сюда же выбор компилятора и его опций.
- Можно просто уменьшить картинку в два раза. Это чит и не факт что можно сделать в какой-то конкретной задаче, но площадь упадёт в 4 раза — почему бы и нет, очень простое решение.
- Попробовать другие алгоритмы сжатия вместо jpeg.
- Возможно, есть видеоядро или что-то встроенное для сжатия, и можно часть задачи переложить туда.
- Посмотреть на специфику картинок и ограничений в конкретной задаче и подумать, как это можно использовать. Возможно, сеть быстрая и можно вообще не сжимать картинки. Возможно, картинки друг на друга сильно похожи и можно кодировать разницу между кадрами (или вообще её не кодировать и пропускать кадр). Возможно, 30 fps нужны, но поток кадров может задерживаться на несколько секунд, и с учётом возможности пропускать мало изменившиеся кадры получится, что в среднем нагрузка сильно меньше. Возможно, картинки сильно контрастные, и можно, например, оставить по 4 старших бита в RGB каналах, потом это будет лучше сжиматься (не обязательно в jpeg, а чем-то ещё).
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?Начну с изучения бизнес-требований. Именно бизнес, а не технических — чтобы понять какой результат ожидается, а не как его достичь. Продолжу изучением предметной области — раньше как-то не доводилось работать с изображениями и видео. Изучу, какие алгоритмы для сжатия существуют, их характеристики. Найду нужный — использую его. Если не найду — попробую изменить условие задачи, найти компромисс между требованиями и возможностями.
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.Это главное условие специальной олимпиады — сравнивать вырожденные случаи. На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
> Начну с изучения бизнес-требований.
Все правильно, но давайте попробуем решить именно техническую задачу. Предположим, что от вас хотят получить пачку жопегов в реальном времени с задержкой не более 200ms и максимальным fps.
> На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
Бинго. При этом поклонники собеседования на senior sortirovatel developer считают, что достаточно искать именно вторых, а остальное как-нибудь приложится.
Все правильно, но давайте попробуем решить именно техническую задачу. Предположим, что от вас хотят получить пачку жопегов в реальном времени с задержкой не более 200ms и максимальным fps.
> На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
Бинго. При этом поклонники собеседования на senior sortirovatel developer считают, что достаточно искать именно вторых, а остальное как-нибудь приложится.
Но ведь для этого и были придуманы видеокодеки, чтобы размазывать эволюцией векторного пространства ключевой кадр, пока не придёт новый. При чём часто с хардварным ускорением. А если нужны именно статичные кадры из видеофида, восстановить это состояние можно в любой момент. Визуально для заказчика это можно даже представить как папку с jpeg.
Вам нужно получить вполне конкретный поток jpeg. Вопрос сводится к тому, как вы будете распараллеливать алгоритм, который нельзя распараллелить.
map & reduce
В смысле, нельзя распараллелить? Как раз поток jpeg параллелится элементарно: один кадр — один поток.
Учитывая указанные ранее ограничения, конечно:
Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд
с задержкой не более 200ms и максимальным fps
Но, если вам, по каким-то пропущенным мною ограничениям, это решение не подходит, то сжатие jpeg все-равно можно параллелить: косинусные преобразования, квантование и RLE происходят в блоках независимо. Потом уж и не помню, хаффман применяется ко всем блокам сразу или независимо. Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
> В смысле, нельзя распараллелить?
Имелся в виду один кадр
> один кадр — один поток
Верно, а потом склеивать их, но с сохранением очередности. Или дропать фрейм, если поток не успел в отведенное время и уже был закодирован следующий. Ответ, которого я ждал.
> Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Можно. Или так, как в предыдущем варианте. Но тут бы надо производительность замерить, потому что может быть не слишком большой выигрыш. То есть это не полностью параллельный алгоритм, стадия reduce тоже довольно тяжелая. Плюс мы получаем огромное количество переключений контекста на одну картинку. Так что сжимать фреймы целиком все-таки лучше.
Имелся в виду один кадр
> один кадр — один поток
Верно, а потом склеивать их, но с сохранением очередности. Или дропать фрейм, если поток не успел в отведенное время и уже был закодирован следующий. Ответ, которого я ждал.
> Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Можно. Или так, как в предыдущем варианте. Но тут бы надо производительность замерить, потому что может быть не слишком большой выигрыш. То есть это не полностью параллельный алгоритм, стадия reduce тоже довольно тяжелая. Плюс мы получаем огромное количество переключений контекста на одну картинку. Так что сжимать фреймы целиком все-таки лучше.
Ну Вы лучше уточните это «несколько», а то ведь 2 ядра — это тоже несколько.
Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
Выкинуть армы, оставить один для управления.
Сверху напаять плисину (плюс покупная библа) или дсп-шку.
Профитттт! :)
>> А опыту за пределами алгоритмов откуда взяться?
>Хм. На SO, например. Какой там опыт нужен? Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.
Вот поэтому я всегда настороженно отношусь к олимпиадникам и любителям всяких хакерренков. Зачастую они вот так и мыслят.
Архитектуру приложения нельзя нагуглить. Написать код, который работает, может любой дурак. Написать код, который эффективно работает, может куда меньше кто. Разработать же архитектуру, которая выдержит годы развития проекта без его превращения в набор костылей и подпорок, могут единицы. А это в сто раз важнее. Алгоритм всегда можно оптимизировать локально, а неудачная архитектура — глобальная проблема.
>Хм. На SO, например. Какой там опыт нужен? Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.
Вот поэтому я всегда настороженно отношусь к олимпиадникам и любителям всяких хакерренков. Зачастую они вот так и мыслят.
Архитектуру приложения нельзя нагуглить. Написать код, который работает, может любой дурак. Написать код, который эффективно работает, может куда меньше кто. Разработать же архитектуру, которая выдержит годы развития проекта без его превращения в набор костылей и подпорок, могут единицы. А это в сто раз важнее. Алгоритм всегда можно оптимизировать локально, а неудачная архитектура — глобальная проблема.
«Алгоритм-мен» никогда не сможет решить практическую задачу
И чем эта практическая задача принципиально отличается от алгоритмической? Типа горе от ума? Отсортировать списки он сможет, а сложить 2 числа — уже нет, слишком просто?
Вы серьезно? Да в любую сторону ткни, нужны знания. Одно только поле знания баз данных неисчерпаемое. Как человеку помогут знания алгоритмов в написании эффективного запроса, если он даже SELECT не делал?
А если базы данных c SQL не используется? В гуглах и яндексах всякие свои распределенные системы хранения со своими интерфейсами.
Как человеку помогут знания алгоритмов в написании эффективного запроса
Отличный вопрос, кстати. Как человек, у которого нет знаний в алгоритмах, может проанализировать план запроса и понять, почему он неэффективно работает? Или как он может понять, почему индекс надо перебалансировать, например? Зная алгоритмы, по крайней мере, отдаешь себе отчёт, чем там занимается СУБД, выполняя твой запрос, а не воспринимаешь её как чёрный ящик.
Вы всё с ног на голову перевернули. Человек умеющий оптимизировать запросы, будет разбираться и в алгоритмах, как субд оптимизирует. Человек умеющий реверсить списки на листочке не сможет сразу сказать как оптимизировать запрос без практики оптимизации, тем более если он вообще о субд ничего не знает. Так может и стоит спрашивать оптимизацию запросов на собеседовании если она нужна? Да не бред какой-то, давайте алгоритмы.
Вы всё с ног на голову перевернули. Человек умеющий оптимизировать запросы
… является человеком, который в той или иной мере изучал алгоритмы. Ну нельзя хорошо уметь оптимизировать запросы, не имея бэкграунда. СУБД — это как раз та редкая область в ИТ, которая буквально напичкана алгоритмикой.
тем более если он вообще о субд ничего не знает.
Ну очевидно же, что если мы берём человека, который ничего о СУБД не знает, то наверное не на должность DBA или DB Performance Engineer? ;)
… является человеком, который в той или иной мере изучал алгоритмы. Ну нельзя хорошо уметь оптимизировать запросы, не имея бэкграунда. СУБД — это как раз та редкая область в ИТ, которая буквально напичкана алгоритмикой.
Все верно, но обратное — не верно.
Ну очевидно же, что если мы берём человека, который ничего о СУБД не знает, то наверное не на должность DBA или DB Performance Engineer? ;)
Зато если отбирать на указанные должности строго алгоритмистов-олимпиадников есть шанс на довольно знатное веселье.
100 раз "да". Ситуация абсолютно уникальная — одна хорошо прорисованная "ментальная модель базы данных" (ну там парсер, кэш запросов, оптимизатор, эвристики, память, буфер сортировки, redo, диск, ...) превращает способного слушать литкодера в достаточно полезного специалиста по отладке запросов СУБД. А гуглить — просто умрешь, сумасшедшее количество деталей и ручек/кнопок (особенно Oracle какой-нибудь).
понять, почему он неэффективно работает
О как, а вы только исходя из знания алгоритмов, можете понять почему запрос неэффективно работает? Поделитесь сим сакральным знанием пожалуйста, а то знаете мы то думали что тут 100500 нюансов.
Зная алгоритмы, по крайней мере, отдаешь себе отчёт, чем там занимается СУБД, выполняя твой запрос, а не воспринимаешь её как чёрный ящик.
Серьезно? То есть обладая общим знанием алгоритмов вы сходу можете понять почему последняя версия пг строит r-tree индексы на порядок быстрее?
Нечеткостью критериев.
Я вам в другой ветке писал про различия между "смогут" и "сделают" — вот лично наблюдаемый случай у меня был как раз такой: х2 времени на разработку и очень сложно поддерживаемый код от двух олимпиадников-снежинок там, где вместо всех примененных наворотов можно было взять чужую либу (работающую медленнее, чего уж там, только это не играло никакой роли).
Могли они сами взять чужую либу? Да конечно же могли. Взяли? Нет, не взяли. Лишние пара недель разработки (и потом еще пара недель на то, чтоб после них подтереть) — это та самая нерешенная практическая задача.
"Взять либу" — это вы только до предпоследнего уровня дошли. На последнем смотришь сколько у этой либы активных авторов, какая лицензия, как быстро они баги закрывают и на что живут при этом, зачем им эта либа вообще. Потом читаешь код, чтобы убедиться, что и сам бы также написал. В общем если надо написать 20 строк я бы не стал тащить либу, слишком много надо сделать, чтобы притащить ее правильно.
Алгоритмическая задача — это отсортировать список как можно быстрее, а дальше хоть трава не расти. Любой говнокод, любые недокументированные хаки приветствуются, лишь бы это добавило скорости.
Практическая задача — это не просто сложить два числа. Это написать код так, чтобы он был понятен и легок в поддержке. Это правильно декомпозировать его, написать читаемые имена переменных (а не «a, b, c»), сделать его расширяемым для будущих изменений бизнес-логики, грамотно написать тесты, и тд.
Практическая задача — это не просто сложить два числа. Это написать код так, чтобы он был понятен и легок в поддержке. Это правильно декомпозировать его, написать читаемые имена переменных (а не «a, b, c»), сделать его расширяемым для будущих изменений бизнес-логики, грамотно написать тесты, и тд.
Причем даже скорость не всегда является абсолютным приоритетом.
Мы же не про сферического коня в абсолютном вакууме, а про некий реальный процесс, работающий в окружении десятков, сотен, тысяч других процессов. И нам важна не только скорость, но и ресурсоемкость этого процесса. Что толку в его скорости, если он под себя отбирает столько ресурсов, что все остальное встает колом пока он работает?
В результате задача уже формулируется примерно так: «есть временное окно, в котором загрузка сервера составляет XX%. Необходимо уложиться в это временное окно так, чтобы загрузка сервера не превысила YY%»
А это уже те аспекты, про которые на олимпиадах нет.
Мы же не про сферического коня в абсолютном вакууме, а про некий реальный процесс, работающий в окружении десятков, сотен, тысяч других процессов. И нам важна не только скорость, но и ресурсоемкость этого процесса. Что толку в его скорости, если он под себя отбирает столько ресурсов, что все остальное встает колом пока он работает?
В результате задача уже формулируется примерно так: «есть временное окно, в котором загрузка сервера составляет XX%. Необходимо уложиться в это временное окно так, чтобы загрузка сервера не превысила YY%»
А это уже те аспекты, про которые на олимпиадах нет.
Ну так в процессе решения алгоритмической задачи смотрят в том числе и на эти качества кода.
«Алгоритм-мен» никогда не сможет решить практическую задачу. Потому что он наловчился только списки сортировать. А опыту за пределами алгоритмов откуда взяться?Оттуда же, откуда и у тех, кто ни в алгоритмы, ни в сложность, очевидно. Только у него будут дополнительно важные знания и навыки.
ттуда же, откуда и у тех, кто ни в алгоритмы, ни в сложность, очевидно. Только у него будут дополнительно важные знания и навыки.Угу. А еще он на скрипке играть умеет — это тоже очевидно.
Вспоминайте, вводный курс теории вероятности. Что более вероятно: (а) Вася хорошо умеет в алгоритмы или (б) Вася хорошо умеет и в алгоритмы, и в архитектуру?
Умеющие в алгоритмы и сложность, очевидно, не сферические ботаны в вакууме. Они точно так же работают, приобретая весь тот же самый опыт, помимо алгоритмического, только у него еще мыслительный аппарат при этом более разносторонний и тренированный.
Так что даже нельзя сказать, что статистически Петя подобен Васе, только без необходимых знаний. Без знания алгоритмов — Петя слабый, просто негодный архитектор. Вот потому-то архитектура, построенная вообще без представления алгоритмической сложности работы с ней — явление куда более распространенное, чем хотелось бы.
Что более вероятно: (а) Вася хорошо умеет в алгоритмы или (б) Вася хорошо умеет и в алгоритмы, и в архитектуру?Если Вася успешно потратил при изучении алгоритмов мозговых усилий кратно больше ленивого Пети, то статистически и в любой другой области, в которой он профессионально позиционируется, очевидно, будет разбираться не хуже Пети. Потому что может укладывать в голове сложные объекты и действия над ними, а Петя — ну так, со скрипом. И потому что Вася умеет упорно добираться до недр изучаемого предмета, а Петя — ну как уж получилось.
Так что даже нельзя сказать, что статистически Петя подобен Васе, только без необходимых знаний. Без знания алгоритмов — Петя слабый, просто негодный архитектор. Вот потому-то архитектура, построенная вообще без представления алгоритмической сложности работы с ней — явление куда более распространенное, чем хотелось бы.
статистически и в любой другой области, в которой он профессионально позиционируется, очевидно, будет разбираться не хуже Пети.
Ни откуда это не следует, это вы придумали двух каких-то персонажей. Я тоже могу придумать Григория, который как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметь, и Константина, который работал на работе и изучал алгоритмы «в полях», и вообще молодец.
Из этих двух персонажей, Григорий очевидно слаб, глуп и достоин порицания.
Ни откуда это не следует, это вы придумали двух каких-то персонажей.Вы же точно тред сверху прочли?
Я тоже могу придумать Григория, который как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметьМожете придумать, ну пусть будет, почему бы нет. И, внезапно, раз Григорий ничего не умеет, то у него и не получится позиционировать себя в какой-то востребованной области. Тем более так, чтобы это было не замечено в начале первой же беседы. Еще раз подчеркну: если ваш Григорий ничего не умеет, то и проблемы его отсечения не существует. А если умеет как надо, то это не ваш Григорий, который
как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметь
Их желание и способности к погрызу гранита будет с неизбежностью статистически выводить Васю и Константина-молодца к познанию, Петю к накапливающимся фейлам, а Григория к невидимости.
Вы сделали бездну допущений, ничем не подкрепленных, кроме своего желания высказаться «в защиту» алгоритмена. Забавно при этом выглядят ваши рассуждения про «мыслительный аппарат при этом более разносторонний и тренированный». Вот алгоритмист так же, считает что у него крутой «мыслительный аппарат», а на деле он дальше алгоритмов ничего не видит.
Но ладно, это уже лирика, так можно бесконечно переписываться о том, что для кого очевидно и что не очевидно.
Факт в том, что в «оперативной памяти» хранятся наиболее часто используемые знания и навыки. Чем реже и меньше человек что-то использует, тем с большей вероятностью он это забудет (или положит в «холодное хранилище в долгим временем доступа», если продолжить говорить метафорами).
Если происходит сортировка людей по одному признаку, то первые места занимают те, у кого этот признак «на кончиках пальцев». Если критерий — алгоритмы, то победят те, кто знают алгоритмы лучше других. А кто может знать алгоритмы лучше других? Правильно, тот, кто совсем недавно закончил их изучать. Если человек хотя бы лет так 5 поработал программистом, то, скорее всего, реально изучал алгоритмы он как раз лет так 5 назад. Сейчас ему интересно другое — архитектура, паттерны проектирования, и прочие высокоуровневые штуки. К примеру, вместо того, чтобы сравнивать скорость разных алгоритмов сортировки списков, он сравнивает разные способы организации и получения данных в какой-нибудь базе, типа постгреса.
Вот и получается, что, задавая вопросы в стиле «реализуйте сортировку пузырьком» или «повращайте мне дерево», больше всего баллов наберут студенты, олимпиадники, разработчики чего-то низкоуровневого, типа компиляторов, и всякие кванты, занятые высокочастотной торговлей, когда каждая миллисекунда промедления означает убытки. А, ну и те, кто страстно желают попасть именно в эту компанию, и последние полгода прорешивали литкод. Обычные инженеры, которые первые минут 10 (особенно, если запретить пользоваться справочниками) будут только вспоминать, как именно работает под капотом алгоритм с тем или иным названием, будут в пролёте. А учитывая, что вряд ли много квантов хотят работать в яндексе, то будут они нанимать в основном новичков.
Но ладно, это уже лирика, так можно бесконечно переписываться о том, что для кого очевидно и что не очевидно.
Факт в том, что в «оперативной памяти» хранятся наиболее часто используемые знания и навыки. Чем реже и меньше человек что-то использует, тем с большей вероятностью он это забудет (или положит в «холодное хранилище в долгим временем доступа», если продолжить говорить метафорами).
Если происходит сортировка людей по одному признаку, то первые места занимают те, у кого этот признак «на кончиках пальцев». Если критерий — алгоритмы, то победят те, кто знают алгоритмы лучше других. А кто может знать алгоритмы лучше других? Правильно, тот, кто совсем недавно закончил их изучать. Если человек хотя бы лет так 5 поработал программистом, то, скорее всего, реально изучал алгоритмы он как раз лет так 5 назад. Сейчас ему интересно другое — архитектура, паттерны проектирования, и прочие высокоуровневые штуки. К примеру, вместо того, чтобы сравнивать скорость разных алгоритмов сортировки списков, он сравнивает разные способы организации и получения данных в какой-нибудь базе, типа постгреса.
Вот и получается, что, задавая вопросы в стиле «реализуйте сортировку пузырьком» или «повращайте мне дерево», больше всего баллов наберут студенты, олимпиадники, разработчики чего-то низкоуровневого, типа компиляторов, и всякие кванты, занятые высокочастотной торговлей, когда каждая миллисекунда промедления означает убытки. А, ну и те, кто страстно желают попасть именно в эту компанию, и последние полгода прорешивали литкод. Обычные инженеры, которые первые минут 10 (особенно, если запретить пользоваться справочниками) будут только вспоминать, как именно работает под капотом алгоритм с тем или иным названием, будут в пролёте. А учитывая, что вряд ли много квантов хотят работать в яндексе, то будут они нанимать в основном новичков.
Вот алгоритмист так же, считает что у него крутой «мыслительный аппарат», а на деле он дальше алгоритмов ничего не видит.Дальше алгоритмов он видит не хуже остальных. А так как сразу на автомате прикидывает сложность работы, то лучше остальных. В сложных случаях — намного лучше. Да что там в сложных — вон по тому, как ворочается эта страничка (вы же заметили?), видно, что хабр далеко не алгоритмисты писали.
Факт в том, что в «оперативной памяти» хранятся наиболее часто используемые знания и навыкиЭто не факт, это ваше допущение, особенно в части навыков. На самом деле строго наоборот: чем более мыслительный аппарат разносторонен и тренирован (ага), тем легче и успешней даются прочие действия в смежных областях.
Чем реже и меньше человек что-то использует, тем с большей вероятностью он это забудетВот только нет ни одной причины, по которой умеющие в алгоритмическое мышление вдруг в повседневной работе что-то использовали реже остальных. Вы тоже фантазируете про шарообразных алгоритмистов в вакууме, а они точно так же работают над обычными задачами, используя те же технологии, что и неспособные в алгоритмику. Только с лучшим результатом в силу более развитых способностей видеть сложность целого.
А кто может знать алгоритмы лучше других? Правильно, тот, кто совсем недавно закончил их изучать.Алгоритмы нужно не «знать и помнить наизусть», а помнить в целом, какие они есть, а главное — моментально оценивать сложность разных подходов, когда приходит время выбора. Да, архитектуры это тоже касается, если вообще не в первую очередь.
К примеру, вместо того, чтобы сравнивать скорость разных алгоритмов сортировки списков, он сравнивает разные способы организации и получения данных в какой-нибудь базе, типа постгреса.Ох… Вы знаете, я вообще-то sql'щик, и мне особенно больно видеть, какие способы организации и получения данных в какой-нибудь базе изобретают неумеющие в базовую алгоритмику/сложность. И чаще всего быстро и прозрачно пофиксить это невозможно, это фиксится через кровь и развороченные кишки. Ну просто написано вообще без мысли «а как это потом будет работать». Даже не «и так сойдет (с)», а просто люди не видят последствий, не привыкли автоматом просчитывать пути и алгоритмы наперед. Пока данных немного, оно без проблем работает. А когда/если проект вырастает, начинаются веселые старты с поминанием незлым тихим словом непонимающих, что алгоритмы и сложности — они на самом деле везде, просто они не обучены сразу видеть это на каждом шагу.
ЗЫЖ кому вы написали последний абзац, я не знаю. Про описанный процесс найма я не слова не писал, это выбор яндекса, а их проблемы и профиты от этого процесса мне неинтересны.
Если вовремя отучить от плохих practices с постоянным желанием реализовывать велосипеды и заставить пользоваться уже готовыми и оттестированными кровью и потом библиотеками и фреймворками. И заставить писать по-человечески, с нормальными названиями переменных и вот этим всем.
Решить может и может, но заточеность на решение сложных алгоритмических задач часто мешает ему сделать простое и поддерживаемое решение, в итоге буде плохокод
Если человек владеет инструментами, но алгоритмы сочинять не умеет, то он застрянет на вполне себе практических задачах вида «отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты»
Ну, слушайте, для такого не надо быть алгоритменом, достаточно просто немного иметь голову на плечах, а в ней — мозгов.
«алгоритм-мен» всегда может решить практическую задачу.
Да если бы. Уж сколько я в промышленной разработке повидал умудренных опытом профессоров, которые могут потратить год на то чтобы оптимизировать до ниточки алгоритм какого-нибудь специфического обхода фрезой внутреннего радиуса малого диаметра, но не способных, под угрозой штрафа, смерти и увольнения, за месяцы и месяцы, не способных этот алгоритм написать и встроить в общую инфраструктуру так, чтобы оно запускалось хотя бы, не говорю уж об исполнялось.
У некоторых из таких теоретических профессоров задачки с литкода вообще никаких проблем не вызывают, вот прям совсем. У них нерешимая задача это склонить репу с гита, или данные из модуля передать чем-то кроме global static void*.
Ну вот поэтому на интервью просят решать задачики, а не проводят теоретический экзамен. Чтобы отсеять в том числе таких профессоров.
Как в посте задачки, да? Ну да, если под отсеять вы имеете ввиду «искать исключительно их»
Что?
Сначала вы пишите, что есть профессора, которые могут натеоретизировать заумного computer science, но не могут писать код. Я вам говорю, ну вот же, на интервью просят писать код. Не заумный — задачки простые! И тут вы каким-то непостижимым мне образом делаете вывод, что если заставлять людей писать код решающий эти простые задачки, то его пройдут исключительно профессора "не могущие написать код"? Раскройте свою логику по шагам — она мне вообще не понятна.
Задачки в посте и прочие простые задачки на интервью — они и есть задачки. Это не работающие программы в реальном мире, это вакуумный код в вакууме.
Человек умеющий решать code puzzles совсем не обязательно умеет производить продукт работая программистом на работе. Потому что в реальности задачи стоят не в виде условий от экзаменатора, а в виде ситуации в реальном мире, превратить которую в задачу решаемую инкапсулированным куском кода — тот еще нетривиальный навык.
И два эти навыка — писать программы и уметь решать code puzzles — друг в друга не транслируются. Сопудствуют, но не транслируются.
Отсюда люди, умеющие решать пазлы, но не умеющие решать практических задач, зачастую даже не могущие понять как подходить к решению практичексих задач.
Человек умеющий решать code puzzles совсем не обязательно умеет производить продукт работая программистом на работе. Потому что в реальности задачи стоят не в виде условий от экзаменатора, а в виде ситуации в реальном мире, превратить которую в задачу решаемую инкапсулированным куском кода — тот еще нетривиальный навык.
И два эти навыка — писать программы и уметь решать code puzzles — друг в друга не транслируются. Сопудствуют, но не транслируются.
Отсюда люди, умеющие решать пазлы, но не умеющие решать практических задач, зачастую даже не могущие понять как подходить к решению практичексих задач.
Задачки в посте и прочие простые задачки на интервью — они и есть задачки.
Эти задачки (или нечто очень похожее на них) постоянно возникают во время работы. Вам так сложно представить, что в Яндексе где-то программисту придется выбрать общие элементы из двух списков?
Отсюда люди, умеющие решать пазлы, но не умеющие решать практических задач, зачастую даже не могущие понять как подходить к решению практических задач.
Не могу себе это представить. Как раз алгоритмическое мышление и умение решать пазлы тренеруют построение математической модели задачи. Это очень помогает решать практические задачи.
Потому что в реальности задачи стоят не в виде условий от экзаменатора, а в виде ситуации в реальном мире
Есть еще отдельная секция про проектирование систем — вот там как раз проверяется умение решать большую, нечеткую задачу. Там не просят писать код (то, что человек код писать умеет видно по алгоритмическим секциям). Но там как раз смотрят, как человек разбивает задачу на подзадачи, как выковыривает из интервьювера недостоющую информацию.
Ее не задают на начальные позиции, потому что люди на этих позициях в основном "копают от сюда и до обеда". Им ставят вполне фиксированные задачи.
Я ищу программиста которы умеет на Java и выбивает 7+ из 10 (0-нуб, 10-бог, условно). Задаю вопрос по почте «пожалуйста прочитайте 17.4 спецификации языка, и подумайте, зачем оно». Ни один из кандидатов (многие с 20+ годами опыта) нормально не ответил, либо не могут прочитать, либо не могут нагуглить разжеванный вариант, либо начинают хамить прямо сразу и говорить, что это не надо. Так что да, профессия загибается.
Так у вас тон вопроса агрессивный, вот люди и закрываются. И даже «пожалуйста» этот тон не смягчает. Вы переформулируйте хотя бы в виде: «что вы думаете по поводу §17.4 в спецификации Java?»
Я его по-английски задаю, и всем немного по-разному, чтобы рекрутер не понял паттерн, но все с “can you please, if you have time, ...”, плюс — это тоже тест, насколько легко вас втянуть в конфликт.
А зачем, собственно, вы втягиваете программистов в конфликт?
Я спрашивал (в смысле что делать если у вас с коллегой разные предпочтения). На собеседовании все либо говорят, что они взрослые люди, что можно договориться, что надо форматирование автоматическое делать в pre-commit делать, либо (когда совсем без опыта и не понимают что будет с историей в гите) — что это пофиг и пусть каждый как хочет так и кодит. А после найма — большинство тихонько делают по-своему и меняют форматирование в каждом коммите, пока "начальник" не скажет как надо.
А я вот думаю, что рекрутеры — зло которого должно быть поменьше. Пусть лучше пара лидов (или как там сейчас модно их называть) которые будут непосредственно ставить задачи тратят 10% времени на поиск сотрудников, чем потом все огребают от некачественного кода, но это, конечно возможно в условиях хорошего финансирования (а то будут толпы джунов и текучка).
Просто вы хотите от кандидатов, чтобы они потратили свое личное время, когда есть куча компаний в которых можно прийти весело поговорить на технические темы без решения задач и уйти получив оффер.
Я понимаю всё это. Я просто не могу придумать как делать лучше. Когда кандидат мне пишет “я 9 из 10 в Linux” честно готовлюсь сам ко встрече с мессией, как дурак трачу время на поиск интересных вопросов и тем, а потом чел не знает что такое системный вызов, и, грубо говоря, на какой порт приходит пинг.
и, грубо говоря, на какой порт приходит пинг.
На какой?
грубо говоря, на какой порт приходит пинг.
Я каждый день ковыряюсь в пачке микротиков, хобби такое, но вот сходу не вспомнил. Во первых я не в контексте, во вторых вы всегда можете загуглить любыми словами, даже не зная «icmp».
Я понимаю всё это. Я просто не могу придумать как делать лучше.
Поговорить как два профессионала, у вас есть задачи, соискатель их может(возможно) решить. Вы когда мебель заказываете тоже сначала спрашиваете из какого металла и под какую отвертку будут шурупы? Уверен что нет, вы говорите «хочу шкаф».
как дурак трачу время на поиск интересных вопросов и тем
Извините, но вы все верно сформулировали. Я встречался с такими как вы и мне ваши «интересные» вопросы не кажутся таковыми.
Когда я прихожу на собеседование (а прихожу я только когда настойчиво зовут) то я ожидаю услышать «Мы хотели бы нанять вас под проект Н, суть проекта М. Вы сталкивались с таким, можете чтото рассказать? Наши текущие проблемы О, П, Р, С, Т., вы бы смогли их решить? Давайте обсудим как бы вы приступили к решению проблемы Р»
Если бы я нанимал сборщика мебели, я бы еще и спросил с каким моментом надо закручивать в фанеру и с каким в ДСП и у кого их лучше покупать и какой отверткой крутить.
Те кто 9 из 10 в Linux, обычно знают с ходу и про пинг и про то, какую для пинга лучше брать сетевуху и у кого покупать, но редко клюют на вакансию "Software Engineer".
Удачи вам, особенно с мебелью.
Да, вы правы, мой мастер цеха бы их научил с каким моментом крутить и какой отверткой. Нафиг их спрашивать. И проверить просто — дать один шкаф собрать.
В принципе так с контрактниками и происходит, и все довольны обычно. И контрактники сами еще приносят шкаф показать, который они делали, и иногда даже можно владельца шкафа спросить как он там.
Те кто 9 из 10 в Linux, обычно знают с ходу и про пинг и про то, какую для пинга лучше брать сетевуху и у кого покупать
Ту на которой написано "ping ready edition"?
Те кто 9 из 10 в Linux, обычно знают с ходу и про пинг и про то, какую для пинга лучше брать сетевуху и у кого покупатьWTF. Или это такой тонкий сарказм? :D
Я каждый день ковыряюсь в пачке микротиков, хобби такое, но вот сходу не вспомнил. Во первых я не в контексте, во вторых вы всегда можете загуглить любыми словами, даже не зная «icmp».
Без знания ICMP вам врядли светит профессия сетевого инженера например, т.к. поговорить как два профессионала с нанимателем не получится.
Судя по всему, в Яндексе у вас есть такой шанс. Заодно алгоритмы подтянете.
Без знания ICMP вам врядли светит профессия сетевого инженера например
Идем в начало ветки и смотрим кого же человек искал то.
Я ищу программиста которы умеет на Java и выбивает 7+ из 10 (0-нуб, 10-бог, условно).
Опа, а ищет то он оказывается разработчика, как интересно. Но я как разработчик (CTO, TeamLead) конечно страшно опечален, да.
ЗЫ кстати даже сетевой инженер не держит все и вся в памяти непрерывно а еще он может волноваться на собеседовании. Простой пример, 5ый знак после запятой числа пи назовете сходу? Как нет? Мы же все это учили, ну в самом деле, основы же.
Чел будет просить значительно больше денег, и нам было бы здорово такого заиметь и платить больше, мы сами себя сисадминим. Он же сам пишет что знает.
ЗЫЫ — про пинг сетевой инженер знает и на вопрос про порт проржется мне прямо в глаза. Зачем знать про порт — ну чтобы знать насколько хорошо можно пингом оттестировать производительность TCP.
Простой пример, 5ый знак после запятой числа пи назовете сходу?назову — я принят? :D Не знаю почему, но еще со школы врезалось — 3,14 15 926 53 58 (написал по памяти)
В сжатые сроки рассказ кандидата о самых интересных и технически сложных задачах из тех что он делал, даст лучшее понимание его уровня, чем вопросы по каким-то деталям реализации.
Потом всегда есть испытательный срок. Да это денежные и временные траты, но тут уж вопрос баланса — если поток кандидатов высок, то можно ставить барьер в виде алгоритмических задач, если поток низок то больше надо допускать к реальным задачам.
Потом всегда есть испытательный срок. Да это денежные и временные траты, но тут уж вопрос баланса — если поток кандидатов высок, то можно ставить барьер в виде алгоритмических задач, если поток низок то больше надо допускать к реальным задачам.
Вот да. В Альфу у меня именно такое и было собеседование.
Никаких тестов, просто поговорили — чем они занимаются, чем я занимался.
Интервьюеров тут тоже нет. Беседуют члены команды (тимлид, техлид, функциональный руководитель...) — те, с кем потом работать.
Испытательный срок есть, но это больше обучение — найти готового спеца на RPG и AS/400 у нас малореально…
Никаких тестов, просто поговорили — чем они занимаются, чем я занимался.
Интервьюеров тут тоже нет. Беседуют члены команды (тимлид, техлид, функциональный руководитель...) — те, с кем потом работать.
Испытательный срок есть, но это больше обучение — найти готового спеца на RPG и AS/400 у нас малореально…
Ну не все так страшно на самом деле. Система вполне себе живет и развивается как по железу, так и по софту. Относительно недавно появились системы PowerS9. На подходе (если еще на вышли) — 10-е.
Версия самой ОС 7.4 вышла в прошлом году. TR-ы (обновления внутри версии) выходят регулярно (мы сейчас в процессе перехода с 7.3TR9 на проде на 7.4TR3 которые уже раскатаны на тестовых средах)
Да, у нас она не популярна (я знаю три банка, которые на ней работают — Альфа, Райф и Рос, ну может еще где-то есть). Но в мире она достаточно распостранена — банки, страховые компании, госструктуры.
Просто на фоне всеобщего засилия мобильной и вебразработки это выглядит нишево, но ниша эта стабильна.
В целом, это свой рынок, вполне устойчивый. Аналогично можно сказать и про многие другие аспекты разработки — та же промавтоматизация, встроенные системы. Уступает по объему вебразработке, но средняя квалификация работающих там людей достатчоно высока.
Версия самой ОС 7.4 вышла в прошлом году. TR-ы (обновления внутри версии) выходят регулярно (мы сейчас в процессе перехода с 7.3TR9 на проде на 7.4TR3 которые уже раскатаны на тестовых средах)
Да, у нас она не популярна (я знаю три банка, которые на ней работают — Альфа, Райф и Рос, ну может еще где-то есть). Но в мире она достаточно распостранена — банки, страховые компании, госструктуры.
Просто на фоне всеобщего засилия мобильной и вебразработки это выглядит нишево, но ниша эта стабильна.
В целом, это свой рынок, вполне устойчивый. Аналогично можно сказать и про многие другие аспекты разработки — та же промавтоматизация, встроенные системы. Уступает по объему вебразработке, но средняя квалификация работающих там людей достатчоно высока.
Видимо да, наименее затратный подход для обоих сторон. Или вообще только через знакомых искать (но это будет не совсем честно).
И на какой? Вот как ни странно, но по этому запросу на первой странице гугла ничего путевого. В вики пусто.
А потому что нафиг это никому не нужно в реальных задачах.
А потому что нафиг это никому не нужно в реальных задачах.
Вот, вот опять это самое. Вопрос «на какой порт приходит пинг» это же в лучшем случае вопрос с подвохом, экзаменационное «завалить» вот это вот.
Это ровно противоположное разговору двух специалистов, это никак не про то, может ли человек работу работать, это очередная итерация агрессивного экзамена, где цель экзаменатора найти чего экзаменуемый не знает, и радостно поставить ему неуд. А если найти не удается сразу, начать трюки разные, лишь бы где-нибудь ошибся.
Это ровно противоположное разговору двух специалистов, это никак не про то, может ли человек работу работать, это очередная итерация агрессивного экзамена, где цель экзаменатора найти чего экзаменуемый не знает, и радостно поставить ему неуд. А если найти не удается сразу, начать трюки разные, лишь бы где-нибудь ошибся.
А ссылку даете?
Кстати, один из кандидатов был русский чел из гугла. Элегантно отвертелся от низкоуровневых деталей 17.4, затроллил offline coding task на игре слов, сделав совсем не то, что просили но настолько круто, что всем очень понравилось — совершенно другая лига, футболист с мячом, а не бурлак на Волге, условно говоря. Ощущение, что просто приходил убедиться, что в гуле ОК, несмотря на иногда скучную работу.
Прошу прощения… Вы вот об этом ...?
«17.4. Спецификации — ДНК, код — РНК
Даже в давние времена PDP-7 Unix-программисты всегда (больше чем их коллеги, работающие с другими системами) были склонны рассматривать старый код как непригодный к повторному использованию. Это, несомненно, было продуктом Unix-традиции, которая акцентировала внимание на модульности, облегчающей выбраковку и замену небольших блоков систем без потери целого. Unix-программисты уяснили из опыта, что попытки сохранения плохого кода или плохого дизайна часто являются более трудоемкими, чем создание проекта заново. Там, где в других культурах программирования инстинкт подсказывал бы исправлять неповоротливые монолиты, потому что в них вложено много труда, инстинкт Unix-программиста обычно ведет к выбрасыванию старого кода и созданию нового.
Традиция IETF усилила этот инстинкт, научив нас считать код вторичным по отношению к стандартам. Стандарты являются тем, что позволяет программам взаимодействовать; они связывают технологии в единое целое. Опыт IETF показывает, что тщательная разработка стандартов, стремящаяся к сбору лучшего из существующей практики, является той формой сдержанности, которая достигает гораздо большего, чем претенциозные попытки переделать мир по образу нереализуемого идеала. ...»
«17.4. Спецификации — ДНК, код — РНК
Даже в давние времена PDP-7 Unix-программисты всегда (больше чем их коллеги, работающие с другими системами) были склонны рассматривать старый код как непригодный к повторному использованию. Это, несомненно, было продуктом Unix-традиции, которая акцентировала внимание на модульности, облегчающей выбраковку и замену небольших блоков систем без потери целого. Unix-программисты уяснили из опыта, что попытки сохранения плохого кода или плохого дизайна часто являются более трудоемкими, чем создание проекта заново. Там, где в других культурах программирования инстинкт подсказывал бы исправлять неповоротливые монолиты, потому что в них вложено много труда, инстинкт Unix-программиста обычно ведет к выбрасыванию старого кода и созданию нового.
Традиция IETF усилила этот инстинкт, научив нас считать код вторичным по отношению к стандартам. Стандарты являются тем, что позволяет программам взаимодействовать; они связывают технологии в единое целое. Опыт IETF показывает, что тщательная разработка стандартов, стремящаяся к сбору лучшего из существующей практики, является той формой сдержанности, которая достигает гораздо большего, чем претенциозные попытки переделать мир по образу нереализуемого идеала. ...»
Не понимаю где они берут специалистов с таким подходом?
Второй путь через рекомендации тех кто уже работает в Яндексе, в этом случае вас не будут мучить этой ерундой.
Вы уверены? Я слышал ровно наоборот от коллег, которые пробовали кого-то рекомендовать.
Я слышал это от людей из Яндекса. Более того, книге «Яндекс.Книга» описано, что они стараются нанимать именно по рекомендациям, а не случайных людей с рынка.
Наоборот это как? Тех кто пришел по рекомендации спрашивают в 2 раза больше дурацких задачек?
Надо понимать что Яндекс большая компания и все процедуры включая собеседования могут сильно отличаться от отдела к отделу.
Наоборот это как? Тех кто пришел по рекомендации спрашивают в 2 раза больше дурацких задачек?
Надо понимать что Яндекс большая компания и все процедуры включая собеседования могут сильно отличаться от отдела к отделу.
Наоборот, это что они (порекомендованные) сначала долго ждут, когда с ними свяжутся, и не всегда даже дожидаются, а потом их отправляют на тот же стандартный набор секций.
Собственно, это даже логично, учитывая, что рекомендовавшему за нанятого по рекомендации дают приличный бонус.
А то, что стараются нанимать по рекомендации, вовсе не противоречит необходимости решать при этом задачки.
Нигде не берут, воронку проходят единицы, мы в проект спецов хантили по полгода. Единственный нормальный поток кадров, это студенты на стажировках, у нас большая часть оставалась.
Но к сожалению почему то политика не становится более адекватной.
П.С. на входе два прохода по 7 интервью (из них 7-8 задачки), провел в офисе Я 2 дня)))
Но к сожалению почему то политика не становится более адекватной.
П.С. на входе два прохода по 7 интервью (из них 7-8 задачки), провел в офисе Я 2 дня)))
собеседование в ФБ на сетевика
4 из 6 тех собеседований — программирование, причем варианты — правильно сделать вот так (например не хранить состояния мелких процессов/докеров локально) — отметались как неподходящие, «правильно» писать в темп файл локально.
сетевое номер один — все норм, кроме того что я не отгадал «правильную» причину возможной потери пакетов (я назвал штук 20 по уменьшению вероятности, эта проблема была где то в моем списке месте на 50, я ее в итоге после выпытывания назвал, но «уже было поздно»)
единственное норм впечатление (как относящееся к вакансии) оставило архитектурное интервью
вот так я и не стал частью ФБ
4 из 6 тех собеседований — программирование, причем варианты — правильно сделать вот так (например не хранить состояния мелких процессов/докеров локально) — отметались как неподходящие, «правильно» писать в темп файл локально.
сетевое номер один — все норм, кроме того что я не отгадал «правильную» причину возможной потери пакетов (я назвал штук 20 по уменьшению вероятности, эта проблема была где то в моем списке месте на 50, я ее в итоге после выпытывания назвал, но «уже было поздно»)
единственное норм впечатление (как относящееся к вакансии) оставило архитектурное интервью
вот так я и не стал частью ФБ
Расскажете поподробней про это собеседование?
про которое из
там их штук 6 — 8 было
все удаленные
прогерские — часть норм (пытаются понять что ты знаешь, как думаешь)
часть — нам нужен ответ который у меня в голове, угадывай,
то что их больше профельных слегка удивило
профильные — архитектурный — прикольно и интересно
чистая сетевка — угадай ответ (на простых, стандартных вопросах не проблема, в сложной проблематике — как указал выше — я привел с десяток потенциальных проблем (из опыта) вызывающих заданную проблему, попытки переключить интервьюрера из режима «угадай мой ответ» в режим «давай вместе проведем траблшут / сужение и найдем варианты» не удалась — от этого интревью осталось самое плохое впечатление
скорее всего — просто не повезло
общее впечатление от всей серии положительное, но локальные перегибы позабавили
HR один из немногих случаев когда они вполне разбирались в базовой тематике и нормально знали требования / альтернативы (например CCIE им достаточно как подтверждение сетевого опыта)
там их штук 6 — 8 было
все удаленные
прогерские — часть норм (пытаются понять что ты знаешь, как думаешь)
часть — нам нужен ответ который у меня в голове, угадывай,
то что их больше профельных слегка удивило
профильные — архитектурный — прикольно и интересно
чистая сетевка — угадай ответ (на простых, стандартных вопросах не проблема, в сложной проблематике — как указал выше — я привел с десяток потенциальных проблем (из опыта) вызывающих заданную проблему, попытки переключить интервьюрера из режима «угадай мой ответ» в режим «давай вместе проведем траблшут / сужение и найдем варианты» не удалась — от этого интревью осталось самое плохое впечатление
скорее всего — просто не повезло
общее впечатление от всей серии положительное, но локальные перегибы позабавили
HR один из немногих случаев когда они вполне разбирались в базовой тематике и нормально знали требования / альтернативы (например CCIE им достаточно как подтверждение сетевого опыта)
Это у них, видимо, так, потому что наемом занимаются люди, которые никакого отношения к тому проекту не имеют. Поэтому у них подход чисто формальный: озадачить кандидата задачкой и поставить оценку, которая зависит от того, насколько его решение соответсвует тому, что они ожидают. Им так проще.
А вот насколько способность быстро решать логические/алгоритмические задачи на интервью кореллирует с практикой разработки программного обеспечения, это еще вопрос. По мне так не сильно.
а никак. у нас конечно не Гугл, но все таки софтверная компания с персоналом около 7 тыс человек. я был в шоке, когда пришлось одному Senior Developer Engineer во время PR review объяснять что set intersection может сократить его код в 2-3 раза. ЗЫ. сам я не senior.
Безусловно кореллирует, но не пропорционально тем масштабам, которые уделяют этому они. Причем у них вообще вопросы зачастую сильно оторванные от прикладных областей.
Очень хотелось бы прочитать историю человека, который прошел все этапы в Яндекс (или другую крупную компанию), о том, чем он занимается ежедневно. Доступным языком.
Расскажу схожую историю про одного моего знакомого))) Он смог попасть в госкомпанию (назовем это так) на три буквы первая Ф. Отбирался год примерно, куча этапов, сложнее только у космонавта отбор… Потом ходил гордый, на вопросы чем занимаешься не отвечал — тайна. В итоге через общих знакомых узнал, что он 10 лет на калитке просидел сутки-трое. Нет, тоже важная часть работы, но зачем тайну делать из этого, видимо разочарован был.
Тем же, что и везде. Работал в Маркете бэкендером на Java. Когда устраивался, описанное выше ещё задачками на сообразительность разбавляли. Писал всякие API, "перекладывал JSON'ы", добавлял в БД таблички и писал к ним запросы, иногда писал и фронт (с минимальным опытом в этом, но на внутренние проекты фронтов часто не дают), иногда что-то ковырял в местном map-reduce, настраивал местный недо-кубер, настраивал всякие графики (rps, тайминг, ошибки и пр.) и мониторинги по ним (тоже всё в основном самописное: "на наших масштабах готовые решения не тянут" ©), чинил баги и разбирался со всякими неожиданными (и иногда мистическими) проблемами с производительностью или неожиданными багами, когда при отключении одного ДЦ ложится вся, казалось бы устойчивая к этому, конструкция.
По теме могу только сказать, что писать квадратичные алгоритмы вместо линейных — это таки большое зло. И стреляет потом очень больно, и разбираться и чинить придётся в дикой спешке и, возможно, в нерабочее время, ибо прод горит, а деньги улетают в трубу тоннами в секунду.
Что конечно никак не обосновывает необходимость задротства на литкоде
Еще большее зло — не писать бенчмарки, или не уметь их писать правильно/реалистично.
Таки вот тут выше был пример с "найти общие элементы в двух списках". Вот вы как предпочитаете: написать "очевидный" для тех, кто не в курсе про асимптотическую сложность, квадратичный алгоритм, а потом ловить проблему бенчмарком, или таки воспользоваться библиотечной функцией для пересечения множеств и больше не вспоминать об этом никогда?
Нагрузочное тестирование конечно никто не отменял, но его делают далеко не так часто, а ещё реже добиваются высокого покрытия по коду, а подобная взрывная штука может спрятаться где угодно.
Ну и писать бенчмарки на любой кусочек кода — тоже странная идея. Они всё-таки обычно применяются, когда уже понятно по другим признакам, что конкретный кусочек кода работает слишком медленно, и не видно очевидных опять же проблем с асимптотикой, поэтому придётся писать что-то сложное, которое надо и протестировать досконально, и производительность с другими вариантами сравнить.
Ну да, я вот как раз недавно узнал как один банк у себя внедряед очередную систему. Какие то совершенно безумные выкрутасы с разнесенными базами и построчной вставкой «для производительности», метрик нет, бенчмарков нет, мониторинга нет, слов у меня — тоже.
Ещё я заметил, что люди пишущие квадратичные алгоритмы абсолютно не парятся по поводу рантайма приложения. Напихать в контейнер 5гб зависимостей — легко! А что, на ноуте же запускается? Потом эти же люди решили в результат map-reduce для простоты добавить все входные данные. А что? Так же проще дебажить? Подумаешь, на мастер приезжает 1тб мусора… проще ж засыпать железом.
Спасибо, коллега. Занимаюсь примерно тем же.
Кратко если, то тем же самым, что и в других компаниях. Сейчас яндекс большая компания с кучей проектов разной сложности. Поэтому и разработчики в нем работают самых разных уровней.
Могу поделится опытом из гугла. Да, 99% времени — рутина. Как шутят в гугле — вместо алгоритмов перекладываешь данные из одного протобуфа в другой.
Но алгоритмические задачи раз в месяц, да и случаются. И тут я благодарен, что я алгоритмы умею.
Сейчас на интервью спрашиваю именно ту задачу, которую сам решал и комитил в прод (слегка упрощенную, конечно, чтобы в интервью влезло).
И считаю что такие алгоритмические интервью — полезны. Даже идиота можно научить перекладывать данные из одного протобуфа в другой. А вот с редкими, но важными алгоритмическими задачами чувак с кучей историй и с которым можно по душам поговорить про очередной фреймворк далеко не всегда справится. Более того, такой условный разработчик может даже и не поймет, что тут алгоритмическая задача. Надо как-то данные перемолотить, ну и молотим. А то, что тут можно динамическим программированием вместо 2^n получить n^3 и при этом решение в 3 раза короче по коду и сильно проще для чтения — даже мысль не придет.
Поэтому, если у вас достаточно кандидатов, то имеет смысл отсеевать по самому сложному, хоть и редко нужному навыку.
Плюс, единственный достоверный способ реально понять, умеет ли кандидат писать код — это заставить его писать код.
Самый сложный и постоянно нужный навык — задавать себе вопросы типа:
- Чем я сейчас занимаюсь? Какая от этого польза? Что мы вообще делаем и для кого?
- Могу ли я добиться того же результата в 10 раз быстрее (не в плане алгоритмов, а в плане time-to-market) используя что-то готовое?
- Какие у решения риски (включая maintainability, риски продукта, бизнес-риски)?
- Как я могу ускорить, упростить работу коллег, или просто помочь им?
И еще «как мне не стоять на проходе когда я ничем не могу помочь», и как понять когда я могу а когда нет. Фрактальный скилл просто.
Вопросы интересные, но интереснее, как вы на них отвечаете)
Чем я сейчас занимаюсь? Какая от этого польза? Что мы вообще делаем и для кого?
Чревато. Можно прийти к выводам "ненужное, неиспользуемое, корявое и неудобное, а ещё хлипкое".
Особенно первый вопрос качёвый, только сильно им не надо увлекаться, а то можно и забухать
Как раз гугл писал статью что качество работника с типом и качествои собеседования не коррелирует никак, совсем, вообще.
А потом смазать это построчным вызовом запроса в бд и вообще ляпота. Без шуток, видел много раз такое в «крайне оптимизированном» коде.
2^n получить n^3 и при этом решение в 3 раза короче по коду и сильно проще для чтения — даже мысль не придет
А потом смазать это построчным вызовом запроса в бд и вообще ляпота. Без шуток, видел много раз такое в «крайне оптимизированном» коде.
Тут спорный момент, сильно зависит от того что и как вставляете. И тем не менее, делать миллион вставок одной строки — совсем плохо. Тут можно впринципе длинную дискуссию организовать, но в процессе обсуждения мы с вами скорее всего и конкретные СУБД обсудим и сеть и транзакции, и (маловероятно но возможно) дисковую подсистему и прочие IOPS, но вот чего мы точно с вами не обсудим это как раз большую О. И, кстати, далеко не факт, что с добавлением слоя абстракции и работы с бд, оптимизация исходного алгоритма будет иметь хоть какое то значение.
. А то, что тут можно динамическим программированием вместо 2^n получить n^3 и при этом решение в 3 раза короче по коду и сильно проще для чтения — даже мысль не придет.
А про потребление памяти не забыли? Запросто может быть, что более «медленный» алгоритм более оптимален по памяти, чем более «быстрый» с каким-нибудь бектрекингом, но как только мы сваливаемся в какой-нибудь своп — усе пропало, шеф
Если там n такое, что n^3 заметно по потреблению памяти, то первоначальный алгоритм за 2^n — вообще ни в какие ворота не лезет. Кстати в динамическом программировании часто памяти надо на порядок (или даже 2) меньше, чем времени. И в итоге потребление по памяти может быть таким же, как при переборе.
Ну 2^n может по памяти быть массив на n + счетчик, а n^3 может быть "а давайте создадим массив nnn и будем его обновлять в процессе обхода."
Если n^3 уже хотя бы 100 килобайт, то 2^n — это 70 триллионов. Наивный алгоритм тут работает десятки часов, когда как этот ужасно прожорливый до памяти алгоритм — миллисекунды.
Повторю свой тезис: Если увеличенное потребление памяти нельзя тупо проигнорировать, то изначальный алгоритм работал непозволительно долго.
Это как упрекать пожарника, что вы мне компьютер залили — он сломался. Когда как вокруг дом горел и люди умирали. Несоизмеримо меньшее зло.
А то, что тут можно динамическим программированием вместо 2^n получить n^3 и при этом решение в 3 раза короче по кодуи сильно проще для чтения— даже мысль не придет.
>> и при этом проще для понимания.
Если последний критерий немного переформулировать — то честно говоря прям с ходу я хороших примеров и не вспомню.
То есть если знать терминологию — то да помогает.
Если обладать «постзнанием решения» — тоже помогает.
А вот прям так с ходу, чтобы более быстрый алгоритм был ещё и более коротким и понятным (без постзнания) — не вспомню.
Что вы понимаете под "постзнанием" тут? Базовые понятия из курса про алгоритмы (ДП идет оттуда). Тут даже никакой хитрой математики нет.
Если это продолжать, то тогда и всякие хитрые конструкции языка использовать не надо. switch-case, оно короче, проще и понятнее, когда представляешь, как оно работает. А вот if-else-if-else-if… это и без "постзнания" понятно. Так что ли?
А вот прям так с ходу, чтобы более быстрый алгоритм был ещё и более коротким и понятным (без постзнания)
Из моей практики. 100+ строк рекурсивной функции полного перебора (+ еще 20 комментариев) заменяется на 20 строк ДП уже с комментариями. Там всего 2 вложенных цикла и тривиальная формула внутри. Комментарии четко говорят, что тут ДП, что вот такие параметры, вот пересчет. Даже не знакомый с ДП человек сможет въехать.
>> из моей практики.
Вот прям хотелось бы пример!
>> что вы имеете в виду под постзаннием?
пример задачи:
Найти в массиве подпоследовательность с максимальной суммой.
Базовое решение за O(n2), быстрое решение за О(n).
Быстрое решение ещё и короче (в строках кода).
Но по записи быстрого решения понятно что мы делаем на уровне бизнес логики — только в случае, если человек уже разобрался с этой задачей (встречал её в олимпиадном \ литкодном прошлом или на каком курсе).
В итоге быстрое решение хоть и короче — но скорее хуже с т.з. понимаемости.
Вот прям хотелось бы пример!
>> что вы имеете в виду под постзаннием?
пример задачи:
Найти в массиве подпоследовательность с максимальной суммой.
Базовое решение за O(n2), быстрое решение за О(n).
Быстрое решение ещё и короче (в строках кода).
Но по записи быстрого решения понятно что мы делаем на уровне бизнес логики — только в случае, если человек уже разобрался с этой задачей (встречал её в олимпиадном \ литкодном прошлом или на каком курсе).
В итоге быстрое решение хоть и короче — но скорее хуже с т.з. понимаемости.
Вот прям хотелось бы пример!
Я эту задачу сейчас сам на интервью использую. Поэтому не буду приводить.
Но по записи быстрого решения понятно что мы делаем на уровне бизнес логики — только в случае, если человек уже разобрался с этой задачей
Это лечится одним комментарием вроде "cur_max_sum — максимальная сумма подпоследовательности, заканчивающийся в данном элементе." Если после этого человек не может понять эту логику, то этому человеку, наверно, не место в яндексе.
Сейчас на интервью спрашиваю именно ту задачу, которую сам решал и комитил в прод (слегка упрощенную, конечно, чтобы в интервью влезло).
Интересно бы глянуть условие задачи.
Поскольку я ее все еще задаю, не хочу ее в интернет сливать.
Может в ЛС напишите? Интересно решить.
Вот немного похожая задача: leetcode
Спасибо за ссылку, интересный паззл.
Вспомнилась другая забавная задачка, может Вы зацените. Дан массив положительных чисел, и надо собрать из них максимально возможную сумму, но при этом нельзя использовать соседние элементы (т.е. если в сумму взяли a[i], то не берем a[i-1] и a[i+1]). Вернуть значение суммы. Интересна тем, что внезапно очень компактно решается за O(N) времени и O(1) памяти.
Простейшее же ДП: F(i) — максимальная сумма, если брать i-тое число и какие-то до него (соблюдая правила).
Пресчет очевиден. Если мы берем i-ое число, то предыдущее может быть i-2 или раньше.
F(i) = max_{j<i-1}(F(j))+a[i]
Такая реализация O(N^2) по времени, но легко реализуется и за линию, если еще ввести
G(i) = max_{j<i}(F(j)).
Тогда пересчет:
F(i) = G(i-1) + a[i]
G(i) = max(G(i-1), F(i-1))Также, можно сделать O(1) по памяти, если хранить только последние значения F и G, и пересчитывать на месте по формулам выше.
Ответ: max(G(N),F(N)). База: F(0) = a[0], G(0) = 0.
Через несколько дней я расскажу на хабре, чем конкретно я занимаюсь (не разработчик, про алгоритмы не спрашивали)
Ну вот тут люди неплохо описывают: habr.com/ru/company/yandex
Извините, не объясните, что за «сидение на калитке»? Это фразеологизм, эфемизм или фреймворк из веба? А то сходу не гуглится.
Работу работаем, и прокрастинацию прокрастинируем.
Размен скорости на память и наоборот делаем регулярно, страшных алгоритмов типа trie на практике не реализовывал и не использовал, но знаю где в соседней команде заиспользовали и зачем.
Размен скорости на память и наоборот делаем регулярно, страшных алгоритмов типа trie на практике не реализовывал и не использовал, но знаю где в соседней команде заиспользовали и зачем.
Сейчас прохожу в яндекс на Go сеньора. Было 2 интервью с задачками, сейчас жду фидбэка по второму — уже 3 дня жду. Надеюсь, следующим этапом будет что-то отличное от алгоритмических задачек с литкода. Кстати, задачку про «функцию RLE» я тоже решал. :)
Не понимаю этого негатива. Задачки простые, зачем беситься? Ну покодил онлайн, поняли, что умеешь кодировать. Относитесь ко всему проще :-)
4 часа.
ну покодил 4 часа :-)
Да, 4 часа это много когда вы и не собирались устраиваться на работу, а пришли поразвлекаться.
Реальная работа это, извините, сommitment и от вас и от компании на как минимум много месяцев или даже уже лет, плюс с большим количеством денег на кону.
Жаловаться что вас крутят 4 часа по алгоритмам это показать свое непонимание процессов найма, их практичности, неумение оценки реальности внедрения более «правильных» с вашей точки зрения процессов найма, неуважение к людям выстраивающим этот процесс за счет отметания с ходу вероятности того что возможно это именно вы что-то неправильно понимаете.
Даже если бы вы решили идеально все представленные задачи, изложенное вами отношение и мысли в этом посту с таким подходом вида «Все говно, а я Д`Артаньян» не помогают уже вам заслужить уважения в ответ. Лично я бы вас не принял никуда ни на какую роль после такой демонстрации, рад за вас что вам на текущем месте хорошо.
Реальная работа это, извините, сommitment и от вас и от компании на как минимум много месяцев или даже уже лет, плюс с большим количеством денег на кону.
Жаловаться что вас крутят 4 часа по алгоритмам это показать свое непонимание процессов найма, их практичности, неумение оценки реальности внедрения более «правильных» с вашей точки зрения процессов найма, неуважение к людям выстраивающим этот процесс за счет отметания с ходу вероятности того что возможно это именно вы что-то неправильно понимаете.
Даже если бы вы решили идеально все представленные задачи, изложенное вами отношение и мысли в этом посту с таким подходом вида «Все говно, а я Д`Артаньян» не помогают уже вам заслужить уважения в ответ. Лично я бы вас не принял никуда ни на какую роль после такой демонстрации, рад за вас что вам на текущем месте хорошо.
Да, 4 часа это много когда вы и не собирались устраиваться на работу, а пришли поразвлекаться.
Реальная работа это ...
Найм на работу — это ещё не работа. Во-первых — время не оплачивается. "Во-вторых" после этого уже не требуется.
Вы заранее до интервью знаете что это займет несколько часов, хотя бы 2-3, оплачивать которые вам никто не собирается. Это абсолютная клоунада, когда вы ожидаете что по-хорошему каждому из сотни людей на вакансию надо оплачивать его время. Или из десятков, которые доходят до интервью. Компании и так тратят на каждого кандидата куда больше денег, чем требуется потратить от кандидата, в десятки раз больше даже с таким потоковым подходом к интервью.
Надо хоть немного совести иметь и понимать это, а не жаловаться что все про все заняло на 1-2 часа больше времени и бугуртить до уровня написания поста на хабр.
Еще надо понимать что собеседования по удаленке куда сложнее для интервьюера чем лично, поэтому очевидно что их надо больше чтобы лучше понять что за человек пришел. Очевидно это временно. Очевидно что винить компанию за это крайне несправедливо.
Если кто не в курсе, то до ковида яндекс и так при приглашении на личные интервью покупал вам и билеты на самолет и гостиницу оплачивал. Требовать чтобы еще больше они вам что-то компенсировали это вообще тотальная наглость. Что они вам еще должны, оплатить пару дней на уровне реальной зарплаты? Рожа, извините, не треснет? При ковиде теперь то конечно не лично получается, но и время вы экономите не собеседуясь лично.
На каждого программиста, который считает что ему все обязаны, найдется не менее десятка сравнимого уровня тех, кто понимает что ему эта конкретная вакансия нужна больше, чем он нужен компании. И кто готов «потратить» десятки, а то и сотни часов на весь процесс прохождения на желаемую вакансию в желаемую компанию. И я лично рад что такие как ОП, а также неготовые потратить несколько часов бесплатно, отсеиваются в описанном процессе найма. Классическая фича, а не баг.
Надо хоть немного совести иметь и понимать это, а не жаловаться что все про все заняло на 1-2 часа больше времени и бугуртить до уровня написания поста на хабр.
Еще надо понимать что собеседования по удаленке куда сложнее для интервьюера чем лично, поэтому очевидно что их надо больше чтобы лучше понять что за человек пришел. Очевидно это временно. Очевидно что винить компанию за это крайне несправедливо.
Если кто не в курсе, то до ковида яндекс и так при приглашении на личные интервью покупал вам и билеты на самолет и гостиницу оплачивал. Требовать чтобы еще больше они вам что-то компенсировали это вообще тотальная наглость. Что они вам еще должны, оплатить пару дней на уровне реальной зарплаты? Рожа, извините, не треснет? При ковиде теперь то конечно не лично получается, но и время вы экономите не собеседуясь лично.
На каждого программиста, который считает что ему все обязаны, найдется не менее десятка сравнимого уровня тех, кто понимает что ему эта конкретная вакансия нужна больше, чем он нужен компании. И кто готов «потратить» десятки, а то и сотни часов на весь процесс прохождения на желаемую вакансию в желаемую компанию. И я лично рад что такие как ОП, а также неготовые потратить несколько часов бесплатно, отсеиваются в описанном процессе найма. Классическая фича, а не баг.
на найм дефицитных и востребованных кадров
Такие то вы дефицитные, что даже у яндеса найдется десяток людей на ту же вакансию с соразмеримым уровнем, но куда меньшим чсв, чем у вас, не говоря уже о гуглах и им подобных. Продолжайте кукарекать о своей незаменимости.
Давайте их пожалеем?
Эх, сейчас бы помечтать о том как мой будущий работодатель будет тратить уйму денег ради оплаты чсв кандидатов, которые приходят на интервью почесать оное чсв, а не на повышение зарплаты работникам, которым я, как настоящий кандидат, вроде как собираюсь стать.
Впрочем, если не собираюсь и не имею достаточно эмпатии чтобы поставить себя на место такого кандидата, то да, я могу вредных советов насоветовать, попризывать не жалеть бедненькие компании.
Соответственно, не понятно в чём тут экономия времени для кандидата, если его будут больше собеседовать.
Уровень понимания и осознания написанного на абсолютном дне. До ковида — телефонное интервью плюс переговоры с рекрутером + Полеты туда-сюда до Москвы/Питера/etс. отнимающие больше суток. После ковида — чуть больше онлайн интервью чем их было бы на месте. Экономия очевидно на сутках потраченных на полеты туда-обратно, плюс-минус пара часов здесь вообще ни что не влияет.
Ну, в том то и дело, что то было до ковида. Если компания оплатит перелёт и проживание, то можно и 8 часов лично собеседоваться, тут нормально всё.
При этом вы все равно потратили больше суток своего времени и не получили на выходе никаких денег в кармане, только оффер или нет.
Без полетов вы потратили условные 4 часа, и на выходе получили оффер или нет.
В первом случае вам типа норм, а во втором вам типа недоплатили. Задумайтесь, не унюхиваете маразм и отсутствие логики?
они ничего не тратят кроме денег на зарплату интервьюеру.
А это как бы мало? 4 условных интервьера плюс-минус, каждый тратит какое-то время на подготовку интервью с вами, само интервью, потом пишет отзыв, каждый тратит на вас в среднем допустим часа 3. Потом рекрутер сколько своего времени тратит, я не знаю, но пусть допустим еще 3.
А сколько еще затрачено на отвлечение программиста от непосредственной работы в плане уменьшения его производительности за счет отвлечения на интервью с вами? Можно еще по часу накинуть. А время изначальной подготовки каждого программиста к интервьюированию? Пару десятков часов, которое потом будет окупаться и размазываться по всем интервью. Думаю далеко не каждый программист за все время работы в яндексе проведет хотя бы 20 интервью чтобы подготовка размазалась хотя бы до часа. Но пусть будет 20 в среднем, еще час можно накинуть.
Итого получается 4 интервьюера * 5 часов зарплаты на каждого, плюс время рекрутера. На этом фоне оплата билетов и гостиницы даже не удвоит эти траты для компании. А вот вы при полетах в несколько раз увеличите затраты своего времени.
пришли поразвлекаться
А ничего что "они первые начали"? Не автор к ним просился, а они его всяко зазывали. Значит — в данном случае им нужнее! Поэтому:
- И чего бы не поразвлечься?
- Почему бы потраченное на вас время не оплатить?
Плюсую, сейчас собеседуюсь в Яндекс, та же картина что и у автора, но никакого негатива с моей стороны нет. «У них так заведено» (с) Компания крупная, принимаю их правила игры, смысл беситься? Конечно хочется какой-то глубины вопросов, типа вам надо разработать такую-то систему с нуля, какие характеристики и как будете делать? но мб не тот уровень вакансии.
Чувак, может ты в Питоне и понимаешь немного, но проблемы и задачи при найме людей на работу не понимаешь вообще.
понимаю :-) обычно кодингом смотрят человек программировать вообще умеет или нет. Был неоднократно свидетелем когда собеседование проходили блестяще, а кодить не умели совсем.
Помню каким то образом в компанию прошел человек «сеньор помидор» который спросил «Парни, а что такое классы? не понимаю как они работают»
Я за то, чтобы кодинга онлайн было меньше, но он необходим :-) хотя бы физбаз
Помню каким то образом в компанию прошел человек «сеньор помидор» который спросил «Парни, а что такое классы? не понимаю как они работают»
Я за то, чтобы кодинга онлайн было меньше, но он необходим :-) хотя бы физбаз
На сколько я понимаю на западе даже большие компании начали отказываться от такого подхода. Например в Амазоне уже давно не только алгоритмы и задачки а сильно лучше
4-5 собесов — это каким бездельником надо быть? Если они по часу это уже пол рабочих дня.
ну поэтому для экономии Яндекс и не посылает нормальных программистов собеседовать. Отправляет тех чье время не жалко… всяких рекрутеров, а качество интервью пытается заменить количеством.
Вроде во все крупные конторы финальные собесы собирают в один день, чтобы кандидату не нужно было сто раз мотаться. В Ковидом не очень актуально стало, но процесс менять не торопятся.
Я могу ошибаться, но вроде бы нельзя шарить задачи, которые были на интервью?
В гугле, во всяком случае, было так.
По вопросу почему так в Яндексе, ну да, знание базовых вещей сильно помогает потом разобраться в местных велосипедах. А что еще спрашивать? Про высоконагруженные сервисы тоже будет секция, если код пройдешь.
В гугле, во всяком случае, было так.
По вопросу почему так в Яндексе, ну да, знание базовых вещей сильно помогает потом разобраться в местных велосипедах. А что еще спрашивать? Про высоконагруженные сервисы тоже будет секция, если код пройдешь.
Но почему на кодирование 4 собеседования?! Они были не уверены после первого? Вроде бы и кодит, но что-то тут не то, давайте ещё 3 раза повторим.
Там не только задачи разные, но и собеседующие, очевидно, чтобы исключить знание конкретной задачи и субъективизм конкретного собеседующего.
Дешевле не нанять хорошего разработчика, чем нанять плохого.
Дешевле не нанять хорошего разработчика, чем нанять плохого.
ЕМНИП, чтобы уменьшить влияние мнения одного человека. Ок, один не получил то что хотел, но трое других были в восторге.
Обычно в таком случае все четверо приходят вместе. И спрашивают из широкого спектра, а не одни и те же задачки.
Я после 11 класса, помнится, и олимпиадные задачки решал, и сортировки все помнил… Но могли бы меня с теми знаниями взять сейчас на сеньора? Да упаси Нортон!
Сейчас уже все эти сортировки забыл за 20 лет, но знаю где лучше применить RabbitMQ а где Kafka, на каком сервере расположить сервисы и как их связать. А сложность сортировки я нагуглю быстро, если надо.
RabbitMQ
С удовольствием бы почитал, а то, как человек, от которого развве что ноги торчат из бд, никак не возьму в толк зачем выводить за пределы транзакции критичные вещи (а все этим радостно занимаются)
> Сейчас уже все эти сортировки забыл за 20 лет, но знаю где лучше применить RabbitMQ а где Kafka
Во! Норм вопросы на позицию сеньёра-бекендера,
Во! Норм вопросы на позицию сеньёра-бекендера,
Я могу ошибаться, но вроде бы нельзя шарить задачи, которые были на интервью?
В гугле, во всяком случае, было так.
Ну если автору плевать — почему нет?
Я могу ошибаться, но вроде бы нельзя шарить задачи, которые были на интервью?
Под NDA нельзя поставить что-то без полноценного заведения оной NDA, с подписями, контролем доступа и всем таким, причём строго через "И".
Поэтому всякие подписи в письмах от рекрутеров "вот это письмо, которое пришло к вам без всяких подписанных бумаг, шарить нельзя" — фикция. Во всяком случае в России.
Устно договориться "давайте Вы не будете делиться?" — это только на уровне устной договорённости. То есть можно, но не обязательно.
но вроде бы нельзя шарить задачи, которые были на интервью?
С каких это пор нельзя? часто ребята идут «по трупам друзей». Первый идёт, кому не сильно надо — разведка боем, просто собирает максимум инфы все вопросы что запомнит / запишет. Потом идёт более подготовленный товарищ, с уже заготовленными ответами на вопросы которые спрашивают на эту позицию. Последним идёт тот, кому нужно больше всего, и которому коллеги добыли максимум инфы. Ко мне всегда отделами ходят на собеседования из глобалов/интеллиасов/люксофтов. Правда такая подготовка для меня — очевидна.
А вы сделайте им такое собеседование, к которому нельзя заранее подготовиться :)
Это, кстати — фигня вопрос для более-менее опытного интервьюера. При желании, разумеется. Я в прошлой фирме задавал те же две задачи на протяжении трех лет, их опубликовали уже через месяц на местном форуме — и ничего, ни о ком из десятка принятых пожалеть не пришлось. Могу даже поделиться:
1. Дан PNG с изображением мяча. При загрузке страницы мяч должен появиться в центре окна браузера и начать двигаться в случайном направлении с заданной скоростью, отражаясь от границ окна.
2. Разработать архитектуру Веб-чата, для простоты — с одной комнатой для всех. Обосновать принятые решения и предложенные фреймворки/библиотеки.
1. Дан PNG с изображением мяча. При загрузке страницы мяч должен появиться в центре окна браузера и начать двигаться в случайном направлении с заданной скоростью, отражаясь от границ окна.
2. Разработать архитектуру Веб-чата, для простоты — с одной комнатой для всех. Обосновать принятые решения и предложенные фреймворки/библиотеки.
1. Если отвлечься от фронта и конкретики, то обычные векторы и угол падения равен углу отражения. С небольшим рандомом если ровненько в угол попали. Чтобы пользователю больше понравится. Не точечная фигура добавит чуть-чуть математики, но опять ничего этакого.Что тут вообще такого?
2. А вот это неплохо. Вполне себе типичный вопрос на архитектуру.
Только зря вы про фреймворки и билиотеки. Какие у вас приняты те и берем. Какая разница в конце концов?
Если ничего подходящего у вас нет, то окей Гугл самое массовое и типовое. Опять же какая разница что брать?
2. А вот это неплохо. Вполне себе типичный вопрос на архитектуру.
Только зря вы про фреймворки и билиотеки. Какие у вас приняты те и берем. Какая разница в конце концов?
Если ничего подходящего у вас нет, то окей Гугл самое массовое и типовое. Опять же какая разница что брать?
1. Не надо отвлекаться от фронта. 95% интервьюируемых понятия не имели как сделать анимацию в браузере (ни одним из способов). Тем, кто слишком углублялся в тригонометрию, не подумав что константы не обязаны быть одномерными — мы давали подсказки.
2. Это не холивара ради — а проверить, насколько человек «в теме» (а WebSockets почти у всех в CV). Если он/а может обьяснить и нарисовать, как это все должно работать (или работало в их предыдущих проектах) — то ничего искать и не нужно. Кстати, по поводу Гугла — мы дали предложение человеку, который честно сказал что с таким раньше не сталкивался, но за то время что мы ему дали — нагуглил что-то похожее, разобрался и вот что получилось.
2. Это не холивара ради — а проверить, насколько человек «в теме» (а WebSockets почти у всех в CV). Если он/а может обьяснить и нарисовать, как это все должно работать (или работало в их предыдущих проектах) — то ничего искать и не нужно. Кстати, по поводу Гугла — мы дали предложение человеку, который честно сказал что с таким раньше не сталкивался, но за то время что мы ему дали — нагуглил что-то похожее, разобрался и вот что получилось.
1. Скажем так — это простая, но непопулярная задача показывает, что человек вообще умеет кодить и в этот момент немного думать (про физику) )
2. Про фреймворки и библиотеки — тут как раз нетривиально, как архитектор говорю. Вопрос «как будете строить решения и что из библиотек/фреймворков» используете как раз позволяет оценить, как человек принимает архитектурные решения. «Гугл самое массовое и типовое» — это лишь один из стилей, он, кстати, кое-что говорит о кандидате :)
2. Про фреймворки и библиотеки — тут как раз нетривиально, как архитектор говорю. Вопрос «как будете строить решения и что из библиотек/фреймворков» используете как раз позволяет оценить, как человек принимает архитектурные решения. «Гугл самое массовое и типовое» — это лишь один из стилей, он, кстати, кое-что говорит о кандидате :)
Как будете строить это замечательно. Архитектура чистая.
Вопросы вызывает только часть про фреймворки. Я допустим чаты не делал. При этом распределенные системы делаю и знаю. Бекенд, но не суть.
Я назову Спринг как отраслевой стандарт и окей Гугл что угодно для вебсокетов. Вроде же на них модно сейчас такое делать? Если что-то подходящее есть в Спринге это и берем, нет смотрим от Апаче итд. Что там будет мне глубоко все равно. Проблема точно решенная в разных библиотеках и в большей части библиотек она точно решена хорошо.
А дальше уйду в дебри кеширования и распреденных БД. Чтобы работать отказоустойчиво и вызывать максимум авто реконнект пользователей при выпадении чего угодно. И не падать когда набегут тысячи пользователей в комнату и начнут постить гифки с котиками.
Это все от фреймворков и конкретных технологий не зависит примерно никак. Хотите Редис, хотите Тарантул, хотите Постгрес, хотите Mysql. Хотите кубер, хотите пакетами можно катать все на любое число серверов. Все работает примерно одинаково. Можно сделать на любых стандартных технологиях.
Вопросы вызывает только часть про фреймворки. Я допустим чаты не делал. При этом распределенные системы делаю и знаю. Бекенд, но не суть.
Я назову Спринг как отраслевой стандарт и окей Гугл что угодно для вебсокетов. Вроде же на них модно сейчас такое делать? Если что-то подходящее есть в Спринге это и берем, нет смотрим от Апаче итд. Что там будет мне глубоко все равно. Проблема точно решенная в разных библиотеках и в большей части библиотек она точно решена хорошо.
А дальше уйду в дебри кеширования и распреденных БД. Чтобы работать отказоустойчиво и вызывать максимум авто реконнект пользователей при выпадении чего угодно. И не падать когда набегут тысячи пользователей в комнату и начнут постить гифки с котиками.
Это все от фреймворков и конкретных технологий не зависит примерно никак. Хотите Редис, хотите Тарантул, хотите Постгрес, хотите Mysql. Хотите кубер, хотите пакетами можно катать все на любое число серверов. Все работает примерно одинаково. Можно сделать на любых стандартных технологиях.
Чаты — тоже не мой профиль, но можно порассуждать — что вы, в принципе, и делаете. И это ок :)
У меня, например, первые вопросы:
1. Это встраиваемое в портал решение, или автономное? Или встраиваемое, но должно быть отдельным сервисом? От этого сильно зависит, как делать авторизацию — прокидывать ли ключи от главного сервиса, или как-то еще.
2. Ну, предположим, делаем модельное решение — доступ по ключу входа, без всяких проверок. Вопрос — на какой объем пользователей? Если у нас миниатюрный сервис до 50-100 участников и мы тестируем гипотезу, я бы почти вообще без библиотек сделал (ну, кроме сокетов, конечно, и, может, хранения сообщений, если есть что толковое под рукой). Зато выкатил бы через несколько дней. Или же у нас есть платная/бесплатная часть? Тогда как выделяем инстансы?.. В общем, тоже, уходим в дебри кеширования и распределенных сервисов (мне, кстати, ближе простенький монолит, но я и высоконагруженными системами не занимаюсь)
Ну, как-то так.
Про фреймворки — это, условно, вопрос «что вы вообще возьмете и зачем». Будете ли фреймворком закрывать архитектурные решения, или возьмете библиотеки и сами их склеите. Что сделаете сами, что делегируете библиотеке (я вот сокеты точно делегирую).
У меня, например, первые вопросы:
1. Это встраиваемое в портал решение, или автономное? Или встраиваемое, но должно быть отдельным сервисом? От этого сильно зависит, как делать авторизацию — прокидывать ли ключи от главного сервиса, или как-то еще.
2. Ну, предположим, делаем модельное решение — доступ по ключу входа, без всяких проверок. Вопрос — на какой объем пользователей? Если у нас миниатюрный сервис до 50-100 участников и мы тестируем гипотезу, я бы почти вообще без библиотек сделал (ну, кроме сокетов, конечно, и, может, хранения сообщений, если есть что толковое под рукой). Зато выкатил бы через несколько дней. Или же у нас есть платная/бесплатная часть? Тогда как выделяем инстансы?.. В общем, тоже, уходим в дебри кеширования и распределенных сервисов (мне, кстати, ближе простенький монолит, но я и высоконагруженными системами не занимаюсь)
Ну, как-то так.
Про фреймворки — это, условно, вопрос «что вы вообще возьмете и зачем». Будете ли фреймворком закрывать архитектурные решения, или возьмете библиотеки и сами их склеите. Что сделаете сами, что делегируете библиотеке (я вот сокеты точно делегирую).
Авторизацию все делают одинаково давно уже. Насколько я знаю.
Пользователь приходит с кукой. Мы эту куку передаем внешнему сервису, он возвращает все что нам положено знать про этого пользователя.
Работает само и независимо. Это как то место где изоляции мало не бывает.
Кеширование в этом месте или запрещенно вообще или минимальное.
Распределенный монолит это хорошо и правильно. Его размер не выглядит слишком уж большим. Распределение делать все равно надо. Нагрузку на балансерах надо как-то распределять по бекендам, да и ребутать без даунтайма хочется иметь возможность. Как именно их синхронизировать и кешировать дело вкуса.
Мне нравятся зукипер, редис и любая sql бд. Если нужно сделать на etcd, Тарантуле и Монге могу и на них сделать. Ну потрачу я недели две чтобы разобраться с новыми технологиями. Мелочь по сути.
Делать один инстанс чего угодно без возможности подключить второй — это самая большая ошибка которую только можно совершить при проектировании. Исправлять очень дорого и сложно. Как правило проще выкинуть и написать заново чем исправить такое.
Если планируется настолько маленькая штука что даже два инстанса с синхронизацией делать кажется дорого, то стоит вообще не делать а походить по рынку поискать готовое решение.
Пользователь приходит с кукой. Мы эту куку передаем внешнему сервису, он возвращает все что нам положено знать про этого пользователя.
Работает само и независимо. Это как то место где изоляции мало не бывает.
Кеширование в этом месте или запрещенно вообще или минимальное.
Распределенный монолит это хорошо и правильно. Его размер не выглядит слишком уж большим. Распределение делать все равно надо. Нагрузку на балансерах надо как-то распределять по бекендам, да и ребутать без даунтайма хочется иметь возможность. Как именно их синхронизировать и кешировать дело вкуса.
Мне нравятся зукипер, редис и любая sql бд. Если нужно сделать на etcd, Тарантуле и Монге могу и на них сделать. Ну потрачу я недели две чтобы разобраться с новыми технологиями. Мелочь по сути.
Делать один инстанс чего угодно без возможности подключить второй — это самая большая ошибка которую только можно совершить при проектировании. Исправлять очень дорого и сложно. Как правило проще выкинуть и написать заново чем исправить такое.
Если планируется настолько маленькая штука что даже два инстанса с синхронизацией делать кажется дорого, то стоит вообще не делать а походить по рынку поискать готовое решение.
Фреймворки - это "мета-вопрос", проясняющий несколько аспектов сразу:
- Случилось ли кандидату действительно работать с тем, что у него/нее в CV написано - или это копипаста откуда-то
- Понимает ли он/она преимущества и проблемы использования библиотек/фреймворков
- Понимает ли он/она "внутреннюю кухню" фреймворка и его API (я люблю .NET-чиков спрашивать, как Task выполняется - почти никто не знает)
- Как кандидат обьясняет свой выбор и реагирует на вопросы
Разумеется, я никогда в жизни не сталкивался и с половиной предлагаемого (например Spring или React) - но если человек действительно на этом писал или хотя бы знает принципы, это сразу видно.
Смотря что понимать под «нельзя».
Неэтично — да, конечно. А в принципе то как запретишь? Даже если в Яндексе установлен режим коммерческой тайны и они как-то умудрились притянуть к нему эти задачки, кандидат — не сотрудник, как ему доступ к коммерческой тайне оформлять?
Шарить задачки, которых нет в интернете — подло с точки зрения компании, но яндекс в этот круг компаний не входит, тк взял все задачки с литкода и ничего нового не придумал.
Не знаю, я в свое время в яндексе ничего такого не подписывал.
Очень много эмоций… На мой взгляд, в таких ситуациях по факту, можно спокойно рассказать о том, как и что ты проблематизировал в процессе коммуникации. Этакий дебаг, что произошло. А эмоции даже при изрядной правоте, выдают склонность к тенденциозности и желанию чтобы все представили ситуацию именно по твоему.
Ну стиль у меня такой ¯_(ツ)_/¯ Да, всё субъективно — рассказал, как это выглядело с моей стороны и что я чувствовал.
Какой смысл в сухом изложении, если большинство пойдет и получит такой же эмоциональный фон в подобной ситуации — это же не вопиющий случай, а политика компании. Наверно будь это не яндекс, было бы куча оговорок — "я не знаю как у других", "может зависит от того кто собеседует" и тд. и тогда сухое изложение может быть было бы уместно, а бурю эмоций можно было бы скрыть под спойлер
С таким подходом, очень вероятно, в Яндекс набирают одних олимпиадников. Это неплохо, возможно, но на самом деле алгоритмы в реальной работе нужны не очень часто — как правило используемые библиотеки уже оптимизированы.
Меня на моей предыдущей работе тоже на собеседовании жестко гоняли по алгоритмам и большому О. Когда приступил к работе, выяснилось, что из алгоритмов в ПО используются только геттеры и сеттеры)
Меня на моей предыдущей работе тоже на собеседовании жестко гоняли по алгоритмам и большому О. Когда приступил к работе, выяснилось, что из алгоритмов в ПО используются только геттеры и сеттеры)
Да, и стандартная библиотека олимпиадникам не нравится, они ее сразу переписывают сами :)
на самом деле алгоритмы в реальной работе нужны не очень часто
"На самом деле огнетушитель в машине нужен не очень часто". Зачем их вообще требовать и проверять на техосмотрах?
Дело в том, что олимпиадники, в подавляющем большинстве случаев, смогут использовать готовые библиотеки, перекладывать данные отсюда туда и всякую другую рутину. Плохой стиль кода у олимпиадников лечится всего за пару недель, если в компании есть код-ревью. А вот не умеющий в алгоритмы программист даже не заметит, что вот тут эта самая алгоритмическая задача возникла. И впендюрит n^2 вместо n log n. Потом внезапно прод станет тормозить, когда нагрузка возрастет всего-то в 10 раз. И придется экстренно искать это место и переписывать.
Да-да, олимпиадник. Он как раз вместо того чтобы взять готовое решение будет сам месяц писать велосипед. Потому что его натаскивали именно на задачи "война, stdlib убит, напиши свое".
У нас в гугле такого не вижу. Да, есть всякие внутренние фреймворки и библиотеки, которые имеют распространенные аналоги, но практически все они в компании сделаны раньше, чем эти распространенные появились. Есть собственная замена почти всему из stdlib в репозитории, поддерживаемая специальными командами (и работает сильно быстрее почти всегда). Никто из моей команды каких-то велосипедов не пишет.
Мой коммент:
У нас в гугле...
Вы приводите ссылку на статью о том, что технологии применяемые в гугле не стоит бездумно перенимать, ибо они заточены под реально большие объемы, которых в большинстве других компаний почти точно нет. Что вы хотели этим сказать?
Если вы про контекст этого поста — то он о яндексе. Как конкурент гугла, хоть и на локальном рынке, Яндекс как раз одна из тех немногих компаний, где гугловые технологии тоже нужны. Опять же, я не понимаю, при чем тут ваш коммент.
Простите, я не считаю Яндекс компанией уровня FAANG. Это безусловно крупный локальный игрок, но по масштабам всё таки отстаёт. Яндекс не Гугл. Уже не Yahoo конечно но и не Baidu. Не надо им по всему миру размещать кешируещие сервера Youtube. Осмелюсь предположить, что stdlib на проектах тоже стандартный. Не верю что так же как в Google «собственная замена почти всему из stdlib». ИМХО нецелесообразно это для локального игрока на стагнирующем локальном рынке. Хотя, это ж Яндекс, какая может быть целесообразность?
Ну вообще, интернет большой. Искать по всему интернету — даже с учетом фокуса на рунете у яндекса — охренительный объем данных. Не знаю, сколько у них датацентров, но предполагаю, что далеко не один. Так что яндексу 100% нужны самопальные решения. Потому что если можно соптимизировать std::string на 1% — это огромная в абсолютных цифрах экономия, хоть и ничтожная в относительных.
> что stdlib на проектах тоже стандартный
ха-ха-ха
ха-ха-ха
И уж точно не свой glibc
С вменяемым руководством — не будет. Главное их самих к руководству не допускать пока они не освоят подход «начинаем с проверки готовых решений». Но к счастью почти у всех это получается освоить очень быстро.
При этом я не раз видел как довольно быстро «готовое решение» «олимпиадникам» удавалось ускорить раза так в 3 а там где performance matters это довольно полезный скилл.
При этом я не раз видел как довольно быстро «готовое решение» «олимпиадникам» удавалось ускорить раза так в 3 а там где performance matters это довольно полезный скилл.
«олимпиадникам» удавалось ускорить раза так в 3 а там где performance matters это довольно полезный скилл.
Я правильно понимаю, что ускорить в 3 раза можно только тот алгоритм который изначально имеет сложность О(1) и О(N)?
Нет. Не обязательно. Взяли вместо O(N^2) сделали O(N log N). Там уже от навороченности алгоритма (константы) и конкретного значения N может получиться что угодно — хоть в 3, хоть в 100 раз быстрее.
Я про общий случай ускорения ровно в три раза.
В моей практике, n-кратное ускорение обычно может быть достигнуто знанием архитектуры, но не алгоритма.
Обычно 2 порядка производительности лежат там где убираются списки, убираются денормализованные числа, заменяются деревья на хэш таблицы или данные перепаковываются что бы уложиться в кэш процессора, или распараллеливается, или чтото типа фильтр блума применяется, или замещаются сики на отображаемые в память файлы. Один порядок производетльности лежит в оптимизациях предсказания ветвлений. Процентов 20 лежат в неоптимальном TLB. Еще префетчер есть. Часто бывает что сложность алгоритма компенсируется латентностью памяти и переключением банков, инвалидации кэша, межпроцессорной инвалидацией данных. Часто где критична производительность и алгоритмов хитрых и не встретишь, просто терабайтные таблицы предвычисленных значений или другие ухищрения.
В моей практике, n-кратное ускорение обычно может быть достигнуто знанием архитектуры, но не алгоритма.
Обычно 2 порядка производительности лежат там где убираются списки, убираются денормализованные числа, заменяются деревья на хэш таблицы или данные перепаковываются что бы уложиться в кэш процессора, или распараллеливается, или чтото типа фильтр блума применяется, или замещаются сики на отображаемые в память файлы. Один порядок производетльности лежит в оптимизациях предсказания ветвлений. Процентов 20 лежат в неоптимальном TLB. Еще префетчер есть. Часто бывает что сложность алгоритма компенсируется латентностью памяти и переключением банков, инвалидации кэша, межпроцессорной инвалидацией данных. Часто где критична производительность и алгоритмов хитрых и не встретишь, просто терабайтные таблицы предвычисленных значений или другие ухищрения.
Я работаю на острие технологий, коллеги понимают кучу алгоритмов, в теме новейших математических и алгоритмических изобретений и публикаций. Но после них получаю задачи вида: «вот у нас алгоритм, на гигабайте работает неделю… прям сильно сильно надо что бы он 100 гигов отрабатывал хотя бы за выходные… мы его на месяц запускали, но даже не представляем сколько ещё осталось… (спустя некоторое время) как это на с++ за час отработал?.. а на 10 ТБ отработает? „
Проблема в том, что про любого хорошего специалиста с глубоким знанием чего бы то ни было (компилятора, среды, архитектуры компьютера) всегда можно сказать, что у него есть «супероружие», позволяющее ему сделать то, чего не может другой. Да, карикатурный «не умеющий в алгоритмы» не заметит, что у него O(2^N), а карикатурный «умеющий» сделает за O(1), но на каждый типаж можно десяток таких карикатур придумать. Навыки должны быть сбалансированными, и хорошо бы проверять на собеседовании какой-то срез, а не что-то одно.
Дело в том, что олимпиадники, в подавляющем большинстве случаев, смогут использовать готовые библиотеки, перекладывать данные отсюда туда и всякую другую рутину.
И конечно же это чистое совпадение, что именно компании-средоточия-олимпиадников являются же главными центрами по производству софтверных решений, которые устраняют исключительно фатальные недостатки в самых разнообразных существующих технологиях.
Ну и уже на личном опыте: смогут использовать готовые библиотеки? Да, безусловно смогут. Будут ли использовать готовые библиотеки там, где их можно прекрасно было использовать? Скорее нет, если только не придёт признанный авторитет и не скажет таки использовать.
И конечно же это чистое совпадение, что именно компании-средоточия-олимпиадников являются же главными центрами по производству софтверных решений, которые устраняют исключительно фатальные недостатки в самых разнообразных существующих технологиях.
И еще одно забавное совпадение: большое количество этих "велосипедов" без фатального недостатка появилось раньше этих разнообразных существующих технологий.
И конечно же это чистое совпадение что именно компании-средоточия-олимпиадников являются лидерами рынка и «разнообразные существующие технологии» создаются зачастую именно ими.
Олимпиадниками нужно руководить, без руководства они естественно могут начать делать совсем не то что надо. Но любыми программистами надо руководить чтобы они не делали совсем не то что надо. И олимпиадниками руководить зачастую проще. Они, в числе прочего, умеют выбирать из готовых решений там где другие не видят особой разницы.
Олимпиадниками нужно руководить, без руководства они естественно могут начать делать совсем не то что надо. Но любыми программистами надо руководить чтобы они не делали совсем не то что надо. И олимпиадниками руководить зачастую проще. Они, в числе прочего, умеют выбирать из готовых решений там где другие не видят особой разницы.
Они, в числе прочего, умеют выбирать из готовых решений там где другие не видят особой разницы.
Не наблюдал никакой корреляции. Умеют выбирать — те, кто умеют выбирать (как правило это те люди, которые уже обжигались на плохих выборах, или те, кто были свидетелями таких случаев). Олимпиадники к этому относятся ортогонально.
И конечно же это чистое совпадение что именно компании-средоточия-олимпиадников являются лидерами рынка и «разнообразные существующие технологии» создаются зачастую именно ими.
И стали лидерами они до перехода на "строго олимпиадники" или после?
И пруф на "создано именно олимпиадниками" очень хотелось бы увидеть.
Ну какие олимпиадники? В описанном собеседовании уровень задачек для начинающих. Олимпиадники — это вообще другая лига. То, что автору давали на собесе — базовый уровень, ну.
В яндексе всё свое, им нафиг не нужны Ваши знания библиотек, фреймворков и т.п. А еще они большие и хотят сделать наем более объективным. Я видел в других местах ситуации когда лид набирает людией под себя и после его ухода их всех только увольнять, другие с ними работать не хотят.
В общем причины почему так нанимают есть. Но вот платят они мало и потому только студентов олимпиадников и могут нанять..
Вспмонилось как один кандидат спросил "чтО большое?"
Возможно этого достаточно, но вопрос — сколько яндекс таким образом теряет потенциальных специалистов по тем вещам, которые нужны в реальной работе
к интервью не готовлюсь
Жму руку. Как там… быть, а не казаться.
Я тоже не готовлюсь.
Но не исходя из моего высочайшего морального облика, а по эгоистичной причине — меньше тревожусь.
Вроде как если я зазубрил все типичные вопросы интервью, то я выдал себя за кого-то другого, и потом грызет синдром самозванца.
А если я просто прошёл собес «чистым» без подготовки, то что уж тут, глаза видели, кого брали:) И мне становится гораздо спокойнее, когда я с какой-то задачей разбираюсь не так быстро, как хотелось бы
Но не исходя из моего высочайшего морального облика, а по эгоистичной причине — меньше тревожусь.
Вроде как если я зазубрил все типичные вопросы интервью, то я выдал себя за кого-то другого, и потом грызет синдром самозванца.
А если я просто прошёл собес «чистым» без подготовки, то что уж тут, глаза видели, кого брали:) И мне становится гораздо спокойнее, когда я с какой-то задачей разбираюсь не так быстро, как хотелось бы
Есть теория, что Яндекс понимает кого ищет.
Ищет людей с хорошим знанием алгоритмов и привычкой всюду смотреть на O(?).
Как найдет, дальше всему научит сам.
Мне такой подход не близок, но я не Яндекс.
Про то, что спрашивать про джанго на собеседованиях не нужно, я как раз с Яндексом согласен. Если ты крутой, дадут методичку, выучишь.
Джанго — это практика, и именно по ней понятно какой у человека опыт и что он точно уже умеет делать. А алгоритмы сам Яндекс форсит учить перед собеседованием. Вот как раз по ним и надо давать методичку, чтобы выучить, если они понадобятся. Но в том и дело, что не нужны Яндексу алгоритмы в большинстве случаев, об этом программисты говорили в одном видео. А такой способ проверки программиста связан с размером компании, с тем, что с таким подходом меньше субъективности, говоря простым языком — бюррократия(например, чтобы токарь получал больше денег, надо не работать продуктивнее, а сдавать на категорию)
А вот то, что не надо искать человека именно с опытом Джанго и спрашивать от него каких-то хитрых подробностей фреймворка, если ему придется работать с Джанго на текущем месте работы — с этим согласен.
А вот то, что не надо искать человека именно с опытом Джанго и спрашивать от него каких-то хитрых подробностей фреймворка, если ему придется работать с Джанго на текущем месте работы — с этим согласен.
А алгоритмы сам Яндекс форсит учить перед собеседованием. Вот как раз по ним и надо давать методичку
Выучить джанго все-таки на порядки проще, чем научится алгоритмическому мышлению и способности решать задачи.
Выучить джанго все-таки на порядки проще, чем научится алгоритмическому мышлению и способности решать задачи.
С этим не поспоришь. Но хватит и пары задач чтобы это выяснить. А вот реальный опыт очень важен.
У меня есть хороший пример — на прошлой работе был коллега, матерый программист, еще TCP-стек для какого-то микроконтроллера реализовывал 30 лет назад, писал на всем что горит… Кинули его и меня на новый проект с Джангой. Дали книжку, которую мы за неделю прочитали и уяснили суть.
Как матерые ООПшники порадовались идее ORM и кинулись в бой. Красиво реализовали все на классах, а потом как пошла нагрузка — поняли что база не совсем любит наш подход и select_related не зря придумали.
Что вы подразумеваете под выучить джанго? Можно написать сайт визитку с 10 посетителей в день без тестов и собрав с помощью батареек необходимой функционал. А можно писать что-то посложнее с гораздо большим количеством посетителей, где надо, например, знать, что такое zero downtime migrations, грамотно организовать архитектуру app внтури django, покрыть всё тестами, организовать сбор метрик для мониторинга, CI, грамотно интегрировать свои компоненты во фреймворк используя паттерны программирования, оптимизировать SQL запросы, чтобы не было N+1 проблемы. Именно умение делать это и нужно в первую очередь работодателям, а не алгоритмы. И более того, умение алгоритмов не гарантирует АБСОЛЮТНО НИЧЕГО из этих навыков и никаких способностей решать задачу, оно гарантирует только умение решать синтетические алгоритмические задачи.
В том-то и дело, что Яндексу не нужен опыт. Нужна голова и способность принять условия игры. Несколько раз сказали — выучи, повтори алгоритмы. Если (а) согласишься (б) успешно и быстро подтянешь — то потом, когда тебе скажут разобраться с «Яндекс.Велосипедофреймворк», ты (а) не будешь спорить (б) быстро разберешься.
Яндексу нужен опыт, в подтверждении этому у него есть система грейдов, да и на собеседовании он тоже проверяется и от него зависит зп. Да и вы сами подумайте, что вы утверждаете. Вы сейчас уравняли вчерашнего студента зазубрившего алгоритмы и программиста с 10 летним опытом в разработке высоконагруженного проекта. Хотите сказать, что яндексу без разницы кого брать? Если да, то вы сильно ошибаетесь. Да и опыт меряется не только знаниями фреймворка X, есть более фундаментальные вещи.
Система грейдов — чтобы удерживать людей со знанием «Яндекс.Велосипедофреймворк» в компании.
И да, система найма Яндекса устроена так, что сеньоров с рынка они почти не нанимают.
P.S. На всякий случай — я не из Яндекса, инсайдов нет, это мои наблюдения.
Мне понятно откуда берется желание обесценить, но всё-таки давайте будем разумными и смотреть на цифры и факты. Считать что Яндекс, у которго сотни продуктов, петабайты данных, мегахайлоад, компанией, которая держится на студентах без опыта, посидевших 3 месяца на leetcode это в высшей степени неуважение. У них точно также внутри как у всех есть синьоры, мидлы джуниоры, которые получают разную зарплату в зависимости от опыта. Причем опыт меряется не фреймворками, а более фундаментальными вещами: работа с бд, паттерны проектирования, микросервисная архитектура, профилирование и отладка и т.п… Мерять опыт фреймворками — это тоже заблуждение, о чем я уже писал в предыдущем посте. Если вы пользовались какой-нибудь SuperMegaDistributedYandexDb, то и с Postgresql быстро разберетесь. Кроме того у яндекса есть, как вы выразились «Яндекс.Велосипедофрейморк» под названием ClickHouse. А React — это «Facebook.Велосипедофреймворк». Вы думаете фреймворки в лесу собирают, они там сами растут?
Ага, а еще без опыта проще эксплуатировать и можно меньше платить.
но я человек ответственный, поэтому к интервью не готовлюсь. Это кстати я не шуткую, реально: если вы ответственный человек, ты вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах.
ну тут двоякое, большинство все еще любят упарываться в типовые вопросы, знание ответов на которые никак и ни разу тебе не пригодятся в будущей работе и вообще никогда не пригодятся ни на одной из будущих работ
Мне кажется, вы словили джекпот — вам подсунули все самые популярные в Яндексе задачки на собеседованиях (сам, когда работал в Яндексе, очень любил задачку про симметрию задавать).
При этом, вы их все слили в интернет, так что сейчас все будут бегать кругами и придумывать новые.
Я надеюсь, что что-то поменяется. А вообще leetcode большой. На крайний случай могу накидать 10 аналогичных по классу задач и предоставить Яндексу на безвозмездной основе.
Да ничего не поменяется. Ну, поменяют они в задачке отели и гостей на завод и выпуск чушек — какая разница? Смысл этого процесса, как верно заметил один из авторов выше, в проверке вашей submissiveness. Если вы бесплатно ради гипотетического варианта трудоустройства готовы n-кратно учить литкоды, то на работе, столкнувшись с велосипедами, переработками и прочими приколами жизни в Яндексе — вы также согласитесь это все делать, не задавая вопросы.
Пусть своим рекрутерам эти задачки задают, а то они не умеют в пересечение «нам нужны ...» и «кандидат умеет ...».
вы их все слили в интернет, так что сейчас все будут бегать кругами и придумывать новые
Ящитаю, это очень хорошо. Человечество от этого только выиграет. Если все так и будут
всегда поступать, со временем сформируется "база знаний" автоматизирующая решение подобных задач, высвобождая время для более полезных вещей. Хотя, конечно, есть некоторая вероятность, что потеря такого фильтра навсегда лишит общество некоего жизненно важного градиента, оставив нас в локальном минимуме эффективности. Но это скорее в предельно длительной перспективе, а на наш век всё-таки — одна выгода.
Плюсую, недавно проходил второй собес в Я, была задача про симметрию
Кста, придумывать ниче не будут, у них там этих задач — выше крышы, мне ам рекрутер говорил
Автор молодец, я хорошо посмеялся, а я просто возьму и оставлю это здесь
https://blog.ploeh.dk/2021/03/22/the-dispassionate-developer/
очень понравился стиль изложения с удовольствием прочитал. Из своего опыта собеседований: у меня было как раз наоборот. Как-то раз, когда-то давно, я зазубрил всякие определения ООП, паттерны и прочее, и с успехом прошел собеседование в очень крутую компанию на сеньора, имея 0 опыта в ООП вообще и совсем не большой в программировании в частности. Ну т.е. как раз таки случай «казаться». Слава богу, здравый смысл у меня победил и я туда не пошел, а пошел туда куда мне и была дорога — в джуны. Что забавно, при этом собеседование проходил мой друг у которого был за плечами очень большой опыт и его не взяли. Зубрить википедию накануне он просто не захотел, исповедуя верную мысль автора.
Яндекс, IMHO, вообще славен письмами типа «Иди работать к нам! Язык G, задачи из области X», при том что ты не специалист по X, а на G и вовсе ни строчки кода не читал. Ах да, и работу получатель таких писем тоже не ищет!
По моему многие просто неправильно понимают суть собеседования в яндекс. С чего-то им кажется что их туда набирают чтобы в дружном коллективе решать интересные задачи с помощью нестандартных подходов. Что будут какие-то глобальные задачи, где надо будет используя опыт предыдущих работ выдумывать интересную архитектуру которая способна справиться с этой задачей. Но эти должности в любой крупной компании уже давно заняты уважаемыми хорошо зарекомендовавшими себя людьми. Совсем не новичками со стороны. А новых сотрудников набирают сидеть и копать от забора и до обеда. Ну вернее сидеть и херачить то, что как раз те самые уважаемые люди придумают за вас. Никому не нужно ваше знание async/await или опыт предыдущих проектов, от вас как раз требуется прочитать что требудется выполнить в конкретной небольшой задаче, где уже всё будет написано что использовать и как «корпортаивно» писать за вас, и нахерачить максимально непротиворечивым способом чтобы это было лекго покрыть тестами. Чем меньше будет творчества в этом, тем лучше — тем стабильней будет решение.
И вот тут как раз со стороны яндекса это именно то, что они от вас хотят — чтобы кандидат мог стабильно сидеть и кодить что сказали, без фигни. А то если каждый будет выдумывать как ему и что делать, каждый подтянет свои любимые библиотеки в проект — любой проект на дно пойдёт.
Так что может это вам было не интересно, а яндекс-то как раз проверяет всё как надо яндексу.
И вот тут как раз со стороны яндекса это именно то, что они от вас хотят — чтобы кандидат мог стабильно сидеть и кодить что сказали, без фигни. А то если каждый будет выдумывать как ему и что делать, каждый подтянет свои любимые библиотеки в проект — любой проект на дно пойдёт.
Так что может это вам было не интересно, а яндекс-то как раз проверяет всё как надо яндексу.
То-есть они могли бы выбрать не алгоритмы, а любую другую область программирования и так же проверять вашу совместимость?
Например, дать необычную (странную) либу со странной же документацией, дать задание разобраться и сделать, а самим следить за моральным состоянием кандидата и тем как он реагирует на подсказки/напутствия?
Например, дать необычную (странную) либу со странной же документацией, дать задание разобраться и сделать, а самим следить за моральным состоянием кандидата и тем как он реагирует на подсказки/напутствия?
По моему многие просто неправильно понимают суть собеседования в яндекс.
Добавьте сюда ещё другой аспект: когда к тебе стоит очередь из желающих пособеседоваться, её надо бы как-то проредить с минимальными затратами для компании, чтобы не тратить время на тех, кто и не собирается становиться сотрудником, но хочет большую честь или там строчку в резюме ну хоть кого-нибудь.
Одного мема «в Яндексе/Гугле/Иксе гоняют по алгоритмам» достаточно, чтобы часть из этой очереди поумерила пыл — и вообще не пришла сразу, а ушла готовиться — не тратя время компании на это.
Всё ещё слишком много времени уходит на собеседования? Добавляем в ротацию домашнее задание и отсеивается ещё часть людей, которые не хотят тратить своё время — и таки образом не будут тратить время компании.
Всё ещё не помогает? Полируем раундом-двумя-тремя онсайт-интервью на четыре часа — часть людей отвалится сразу как только их об это предупредят, а с «выжившими» можно и поговорить.
Похоже, мы присутствуем при рождении нового мема...
Ну ок, хотят проверить знание каких-то базовых вещей.
Прям таки действительно «улыбает» со всего этого. Нет, не «позиция» автора. И не «позиция» какого то яндекса. Складывается стойкое впечатление, что ни те ни другие не способны даже файл открыть и распарсить за действительно минимальное время.
Ну потому что автор — это питон и это конечно же смишно))
Ну а яндекс вообще ничего не спрашивает про железо, и это тоже смишно)
Ибо не зная как работает конкретная ОС, как она настроена, какие железки стоят т.е. контроллеры и винты и т.д. — почитать и распарсить файлик за минимальное время совсем не получится. И что бы опиративку оно не выжрало как не в себя. И что бы у бгмерского коллектора голова не закружилась. Слушайте, а тогда зачем вам это всё?)
Кому вообще нужен мееееедлееееееенный код? Идиотам? Хз хз… Даже теряюсь в догадках…
Какие то абстрактные кони в вакууме…
п.с.: Нет, я категорически не против алгоритмов и я категорически не против вхлам тормозного питона, однако же я против того, что существует так называемое абстрактное программирование. Нет, это не ооп. Абстрактное программирование — это программирование насмерть оторванное от железа. Однако же если юзать такое вот абстрактное программирование — ничего хорошего не получится, причём по определению. Сие даже не нуждается в доказательствах.
Ну потому что автор — это питон и это конечно же смишно))
Ну а яндекс вообще ничего не спрашивает про железо, и это тоже смишно)
Ибо не зная как работает конкретная ОС, как она настроена, какие железки стоят т.е. контроллеры и винты и т.д. — почитать и распарсить файлик за минимальное время совсем не получится. И что бы опиративку оно не выжрало как не в себя. И что бы у бгмерского коллектора голова не закружилась. Слушайте, а тогда зачем вам это всё?)
Кому вообще нужен мееееедлееееееенный код? Идиотам? Хз хз… Даже теряюсь в догадках…
Какие то абстрактные кони в вакууме…
п.с.: Нет, я категорически не против алгоритмов и я категорически не против вхлам тормозного питона, однако же я против того, что существует так называемое абстрактное программирование. Нет, это не ооп. Абстрактное программирование — это программирование насмерть оторванное от железа. Однако же если юзать такое вот абстрактное программирование — ничего хорошего не получится, причём по определению. Сие даже не нуждается в доказательствах.
Абстрактное программирование — это программирование насмерть оторванное от железа
А чем вам AWS Lambda не угодил?
Закусывайте.
М, я думал, что фон Нейман свою архитектуру вычислительных систем затаскивал именно для того, чтобы абстрагироваться от железа при решении прикладных задач, а тут воно как.
Месьё программирует с помощью бабочек?
Сам был участником подобных собеседований в FAANG. Поэтому было интересно узнать, почему собеседования проходят именно таким образом: 3 кодинг сессий, 1 дизайн системы, 1 поведенческая.
Для себя сделал такой вывод:
1. Большой поток кандидатов, сложно объективно и индивидуально подходить к каждому.
2. Решая алгоритмические задачи, кандидат показывает свои когнитивные способности. Способность понимать подсказки интервьюера, способность находить и обрабатывать крайние случаи. Отбираются кандидаты с хорошей соображалкой, а уж по скиллам место внутри многотысячной корпорации найдется.
3. Подготовленный кандидат (over 50-100 решенных задач на leetcode, например) также показывает свою мотивацию получить работу в компании.
Для себя сделал такой вывод:
1. Большой поток кандидатов, сложно объективно и индивидуально подходить к каждому.
2. Решая алгоритмические задачи, кандидат показывает свои когнитивные способности. Способность понимать подсказки интервьюера, способность находить и обрабатывать крайние случаи. Отбираются кандидаты с хорошей соображалкой, а уж по скиллам место внутри многотысячной корпорации найдется.
3. Подготовленный кандидат (over 50-100 решенных задач на leetcode, например) также показывает свою мотивацию получить работу в компании.
Ну даже я после первой 100 проведенных однотипных интервью догадался их автоматизировать и проводить скопом сразу на 20 человек (но офлайн, чтобы без читерства).
Из хорошо проведённого кодинг интервью можно вообще массу полезных сигналов вытащить.
+ Насколько вменяемо кандидат общается с интервьювером в процессе решения задачи,
+ Как кандидат себя ведёт, если встречает алгоритмическую задачу, которую раньше не видел. Пробует примерить на неё все паттерны подряд, делает решение «в лоб» и оптимизирует, залез под стол и кричит?
+ Как он то, что понаписал, собирается тестировать? Код хоть приблизительно читаем?
+ Нашёл ли кандидат крайние случаи, уточнил ли все места где задача была недостаточно определена, смотрит ли на вычислительную сложность…
Автор, кстати, хорошо показывает откуда берутся статьи «Винда полчаса сортирует значки рабочего стола» и «GTA V зачем-то парсит гигантский json на каждый чих». А что, «сложность алгоритма в реальном программировании нужна целых 0 раз», интерсектом бахнем да и норм :)
+ Насколько вменяемо кандидат общается с интервьювером в процессе решения задачи,
+ Как кандидат себя ведёт, если встречает алгоритмическую задачу, которую раньше не видел. Пробует примерить на неё все паттерны подряд, делает решение «в лоб» и оптимизирует, залез под стол и кричит?
+ Как он то, что понаписал, собирается тестировать? Код хоть приблизительно читаем?
+ Нашёл ли кандидат крайние случаи, уточнил ли все места где задача была недостаточно определена, смотрит ли на вычислительную сложность…
Автор, кстати, хорошо показывает откуда берутся статьи «Винда полчаса сортирует значки рабочего стола» и «GTA V зачем-то парсит гигантский json на каждый чих». А что, «сложность алгоритма в реальном программировании нужна целых 0 раз», интерсектом бахнем да и норм :)
Автор, кстати, хорошо показывает откуда берутся статьи «Винда полчаса сортирует значки рабочего стола» и «GTA V зачем-то парсит гигантский json на каждый чих». А что, «сложность алгоритма в реальном программировании нужна целых 0 раз», интерсектом бахнем да и норм :)
Теперь бы еще понять, откуда берутся статьи «Гуглопочта весит 6.7Мб и её практически невозможно* открыть на плохом канале».
Ах да, это же не про сложность алгоритма, какие могут быть претензии.
* — в прошлом, с некоторых пор гугл изволил починить логику отображения ссылки перехода на «легкую» версию гуглопочты, и теперь по крайней мере её можно без проблем нажать
Так именно при подходе «просто подключим тут для решения проблемы Х (решается одной страничкой кода) библиотеку N (10 мегабайт кода)» и возникает «гуглопочта по 6.7 Мб».
Гуглопочта написана на собственных технологиях гугла.
1) Так что же, их собственные офигенные решения не такие уж офигенные?
2) Куда делись все олимпиадники при написании гуглопочты?
Это, конечно, звучит как "сперва добейся"… Но попробуйте сделать гуглпочту более лучше. Я не встречал ни одного другого почтового клиента с таким набором фич, с поддержкой того же количества трафика.
Я не встречал ни одного другого почтового клиента с таким набором фич, с поддержкой того же количества трафика.
Гуглопочта, до того момента, как она стала гуглопочтой на 6.7Мб — была такой же гуглопочтой, но весьма более скромного размера.
А еще до этого она была гуглопочтой без SPA (это то, что сейчас существует как "облегченная версия"), и там с размерами и скоростью загрузки тоже было всё просто наишоколаднейше.
Так что вот "другие клиенты с фичами и траффиком" — это всё та же гуглопочта, просто не то, что сейчас предлагается по умолчанию, а исторические её варианты.
была такой же гуглопочтой, но весьма более скромного размера.
И там не было ни автодополнения, ни отмены отправленных сообщений, ни чата и кучи других функций.
Да ну нет конечно. Тот же hangouts в почте с незапамятных времен, и в прошлой он тоже был. И в новой он, подозреваю — один из самых скромных по размеру компонентов. И вообще в момент радикального утолщения почты там не было никаких прорывных фич добавлено, по крайней мере относящихся непосредственно к почте.
Фичи уже потом пошли. И самое забавное, что размер гуглопочты они особо не увеличивали.
Да не нужен в ней чат! Это почта! Мне не чат нужен, а мгновенное удаление писем! В 2021 году удаление письма занимает 5 секунд, в течение которых нельзя закрыть вкладку!
Так Яндекс же. Чего далеко ходить.
И там тоже есть автодополнение, чат, оффлайн режим?
Автодополнение есть.
Чат в одном клике. Правильное продуктовое решение.
Оффлайн режим есть в мобильном приложении. В вебе нет. Тут вы правы.
Если такая тяжесть gmail обусловлена оффлайн режимом, то стоит сделать галочку для его выключения. 10х ускорение работы стоят того.
Чат в одном клике. Правильное продуктовое решение.
Оффлайн режим есть в мобильном приложении. В вебе нет. Тут вы правы.
Если такая тяжесть gmail обусловлена оффлайн режимом, то стоит сделать галочку для его выключения. 10х ускорение работы стоят того.
Из того, что я вижу, автодополнение полностью на сервере сделано, на каждый новый символ отправляется запрос (весьма сложно структурированный и включающий в себя все содержимое письма), в ответ на который приходит или не приходит возможное автодополнение. Причем на каждый ввод символа сообщение пересылается целиком. С точки зрения объема клиентского кода это не выглядит очень уж весомой фичей для мегабайта кода. Не считая того, что на так себе канале оно будет жуть как лагать.
Чат — лучше бы его можно было выключить, если им не пользуешься. Hangouts — боль и страдание, с проблемами входа в комнату и подобным. Ух я им наелся, когда с гуглерами работал, у которых кроме него ничего нет.
А offline mode — а он не работает фактически. Да, он позволяет открывать письма в текущем ящике (правда при этом отваливаются пиктограммы над письмом), но к примеру в черновики не попасть.
Зачем оно нужно вообще в таком виде?
Чат — лучше бы его можно было выключить, если им не пользуешься. Hangouts — боль и страдание, с проблемами входа в комнату и подобным. Ух я им наелся, когда с гуглерами работал, у которых кроме него ничего нет.
А offline mode — а он не работает фактически. Да, он позволяет открывать письма в текущем ящике (правда при этом отваливаются пиктограммы над письмом), но к примеру в черновики не попасть.
Зачем оно нужно вообще в таком виде?
Тут же меня спросили, какова сложность алгоритма — ок, норм, это нужно знать, потому что в реальном программировании мне это потребовалось целых 0 раз
Да, это нужно. Тут вам повезло, что словарь в питоне работает быстро. Но если не знать что как работает, то можно, например, написать то же самое со списком. Получить квадратичный алгоритм и получить дикие тормоза, когда нагрузка на прод возрастет.
Ну тут ещё вопрос культуры языка и среды. В C++ (STL) алгоритмическая сложность каждого метода является частью спецификации и прописана в документации. Соответственно, даже если человек вообще не очень в алгоритмах смыслит, ему эти "линейное время" и "логарифмическое время" постоянно глаза мозолят. И хорошо что мозолят, везде бы так.
Статистический подход к собеседованию. Проверяют на однотипных задачах всех кандидатов на позицию, каждый интервьюер выставляет оценку, в итоге сравниваем некую среднюю метрику и можем выбрать среди кандидатов лучшего по метрике. В итоге, результат найма не зависит от конкретного интервьюера или того, что некий кандидат чуть больше прочитал в документации на фреймворк X про фичу Y. При этом, т.к. компания большая, то финалист собеседования сможет разобраться во внутренних фреймворков, а не только использовать шаблонные best-practice из SO для условного Spring/Django.
Как еще делать в большой компании, чтобы избежать влияния личности на результат, и чтобы можно было сравнить нескольких кандидатов между собой?
Если что, мне тоже не нравятся алгоритмические собеседования и тем более, подготовка к ним.
PS Дополнил спустя 5 минут. Еще нужно попутно держать в голове, что нужно избежать проблему кумовства, найма по знакомству, «он хороший человек», по принадлежности в группе (к примеру, он из моего универа, города) и т.п. В маленькой компании эти проблемы не важны, в крупной — я думаю будет не в кайф оказаться в коллективе, где все друг друга знают по еще какому-то признаку и прикрывают друг друга, а сторонний человек становится изгоем.
Как еще делать в большой компании, чтобы избежать влияния личности на результат, и чтобы можно было сравнить нескольких кандидатов между собой?
Если что, мне тоже не нравятся алгоритмические собеседования и тем более, подготовка к ним.
PS Дополнил спустя 5 минут. Еще нужно попутно держать в голове, что нужно избежать проблему кумовства, найма по знакомству, «он хороший человек», по принадлежности в группе (к примеру, он из моего универа, города) и т.п. В маленькой компании эти проблемы не важны, в крупной — я думаю будет не в кайф оказаться в коллективе, где все друг друга знают по еще какому-то признаку и прикрывают друг друга, а сторонний человек становится изгоем.
Как еще делать в большой компании, чтобы избежать влияния личности на результат, и чтобы можно было сравнить нескольких кандидатов между собой?
Автоматизировать? Предложить решить 100 задач на том же литкоде в удобное время?
Нет, лучше назначить в рабочее время звонок на минимум час времени и сопеть в наушники пока кандидат потеет в стрессе. Повторить через день. И потом еще неделю так же.
Где-то видел чей-то комментарий на тему "когда меня спросили есть ли у меня вопросы я сказал что есть — мне хотелось бы тоже знать уровень тех, с кем я буду работать. И тоже предложил им решить при мне задачку". Мне кажется это может немного охладить интервьюеров иногда.
Литкод не решит задачу списывания, к сожалению.
А как её решит любое удалённое собеседование? Я видел правила для удалённой сертификации, когда принимающему экзамен нужно камерой показать всё пространство вокруг рабочего стола, но вряд ли эти правила соблюдаются на собеседованиях.
По крайней мере интервьювер видит кандидата. Тупо подсказки соседа и гуглеж уже невозможны. Хитрости со скрытыми наушниками еще работают, но в интервью при живом общении такие странности видны. Если кандидат после каждого вопроса несколько минут тупит, а потом идеально отвечает — это будет отражено в отчете интервьюера.
Предложить решить 100 задач на том же литкоде в удобное время?
Та же проблема что и с предложением принимать профиль на гитхабе на интервью.
Списывание, читерство и обман.
Мне кажется, вы не видите за деревьями леса. Когда вас гоняют по (иногда?) тупым задачкам, хотят вовсе не получить их решение, а достать т.н. «сигналы» — как кандидат себя ведет, как размышляет, как комментирует свои действия, как тестит свой код (каким бы простым он ни был).
При этом само решение тут, гм, решающей роли не играет — по большому счету, вы можете ее даже не решить или решить неправильно, но все равно набрать себе очков, если все делали правильно (и это логично, потому что кому нужны олимпиадники и литкод-ковбои в продакшене :) ).
И да, я (уже) не провожу собеседования в яндекс, это просто мои соображения, основанные на том, как сейчас мы собеседуем к себе. И конечно же есть нерадивые интервьюверы, которые из-за лени или по запарке просто посмотрят на формальное выполнение задачки и потом дадут отписку эйчарам, мол, этот решил — его берите, а этот не решил — его не берите.
При этом само решение тут, гм, решающей роли не играет — по большому счету, вы можете ее даже не решить или решить неправильно, но все равно набрать себе очков, если все делали правильно (и это логично, потому что кому нужны олимпиадники и литкод-ковбои в продакшене :) ).
И да, я (уже) не провожу собеседования в яндекс, это просто мои соображения, основанные на том, как сейчас мы собеседуем к себе. И конечно же есть нерадивые интервьюверы, которые из-за лени или по запарке просто посмотрят на формальное выполнение задачки и потом дадут отписку эйчарам, мол, этот решил — его берите, а этот не решил — его не берите.
При этом само решение тут, гм, решающей роли не играет — по большому счету, вы можете ее даже не решить или решить неправильно, но все равно набрать себе очков, если все делали правильно (и это логично, потому что кому нужны олимпиадники и литкод-ковбои в продакшене :) ).
Эта популярная отмазка Яндекса ("вы, если чё, можете решить всё неправильно, мы принимаем комплексное решение, основываясь на всех аспектах") не бьется с практикой: тем, кто на задачособеседованиях решает неправильно, тут же говорят "извините, дальше мы вас не будем собеседовать".
Так кандидату на собеседовании будут давать подсказки.
А если он даже с подсказками не может решить, то это явный звоночек о проблемах.
А если он даже с подсказками не может решить, то это явный звоночек о проблемах.
«Как ведёт себя кандидат, сталкиваясь в бесконечным однотипным потоком задач, кажущихся бессмысленными, от людей, которым он не может отказать».
Ха-ха (сквозь слёзы).
И ведь работает, набирают, кодит у них там кто-то.
Ха-ха (сквозь слёзы).
И ведь работает, набирают, кодит у них там кто-то.
Когда вас гоняют по (иногда?) тупым задачкам, хотят вовсе не получить их решение, а достать т.н. «сигналы» — как кандидат себя ведет, как размышляет, как комментирует свои действия, как тестит свой код (каким бы простым он ни был)Ну вообще человек, который понимает, что его время тратят по большому счёту зря, при этом ожидая к себе какого-то уважительного отношения, раздражается, и правильно делает. А умение сохранять покерфейс при работе с неприятными людьми нужно обычно менеджеру, а не программисту (да, даже в продуктовых компаниях и внутренней разработке при общении со стейкхолдерами оно нужно очень ограниченно). Потому, ну, что проверяете, то и получаете.
При этом само решение тут, гм, решающей роли не играетКак уже сказали, это утверждение неверно.
кому нужны олимпиадники и литкод-ковбои в продакшенеЯндексу. Почему-то. Хотя зачем люди идут унижаться в Яндекс за всем этим, когда можно пойти хотя бы в Гугл с теми же предусловиями (плюс английский, окей), мне совершенно непонятно.
Почему зря? Вы показываете, как вы решаете проблемы и коммуницируете, на вас смотрят, оценивая, подходите ли вы. А потом бы желательно еще оставить минут 5-10 на вопросы кандидата — про процессы и все такое. Но это, конечно, в идеале.
Другое дело, что, к сожалению, программисты — зачастую, очень неприятные люди :) Поэтому частенько нарываешься на такой отвратительный подход к проведению интервью — формальный, на отъебись, лишь бы эти чертовы эйчары отстали и можно было бы вернуться к любимому перекладыванию жсонов. И эйчарам, в свою очередь, насрать на то, как эти интервьюверы работают — лишь бы вакансию закрыть худо-бедно.
Так и живем.
Другое дело, что, к сожалению, программисты — зачастую, очень неприятные люди :) Поэтому частенько нарываешься на такой отвратительный подход к проведению интервью — формальный, на отъебись, лишь бы эти чертовы эйчары отстали и можно было бы вернуться к любимому перекладыванию жсонов. И эйчарам, в свою очередь, насрать на то, как эти интервьюверы работают — лишь бы вакансию закрыть худо-бедно.
Так и живем.
Почему зря?Потому что если вы спрашиваете однообразные задачи, которые даже не из разных сфер знаний алгоритмики более двух раз — а примеры выше реально однообразные и практически друг друга не дополняют — вы тратите время зря, притом и своё, и кандидата. Это не добавляет новой информации, это проверяет терпение кандидата, а для программиста ангельское терпение не является ключевой компетенцией. Возможно, потому что процессы поганые, возможно, потому что конкретные интервьюеры/рекрутёры не справляются с задачей (в этот конкретный раз или систематически — другой вопрос).
к сожалению, программисты — зачастую, очень неприятные людиЛюди вообще зачастую очень неприятные, чивоуштам. А если чуть серьёзнее — так задача менеджмента и отдела по работе с персоналом выстроить процессы так, чтобы очень неприятные люди как минимум не собеседовали кандидатов за исключением крайней необходимости, а в полном идеале так вообще не попадали в компанию (но это уже сложнее, и ещё и платить надо деньгами, и вообще шевелиться много), или, если попали, исправлялись по мере возможностей.
Вот я думаю, пройдёт аффтар ещё десяток уровней собеседования, решит всё, и возьмут они его на работу. А потом руководство найдёт эту статью, да и обидится на слова «в яндексе всё как-то тупо».
Без обид, разбор задачек крутой)
Без обид, разбор задачек крутой)
Ну их можно понять, но это не делает процесс лучше. Типа — ну да, мы в крусе, что ты знаешь %фреймворкнейм%, но вдруг ты ничерта кроме него не знаешь и надо «проверить какие-то базовые вещи». Типа такой тест на самозванца.
Имхо имеет смысл спрашивать что-то в духе «а что тебе больше нравится из этих вот технологий?». Ответ показывает и знание и заинтересованность (которой у самозванцев нифига нету)
Имхо имеет смысл спрашивать что-то в духе «а что тебе больше нравится из этих вот технологий?». Ответ показывает и знание и заинтересованность (которой у самозванцев нифига нету)
После 9 таких собеседований в Яндекс мне сказали, что они не готовы меня взять. Не знал, что чтобы отказать человеку, нужно провести 9 собеседований)
Значит ты был близок, живи с этим. :)
Скорее всего это значит, что много интервьюеров сказали что-то в духе «нанимать, но не к нам в команду». Ищите проблему в себе.
Девяти??? Хахаха, капец, надо из них высудить компенсацию, пусть оплачивают час по ставке.
UPD: После отказа написали что хотят продолжить. Пройдено 13 собеседований. Зовут на 14 и 15.
Мда, слоны боятся мышей…
Во-первых, удачи, во вторых я бы подождал постить это, так как они могут увидеть и, сам понимаешь, тайна компании, и.т.д.
А так, скоро наверное и GIL с Multithread будут ненужны, за них всю работу будут делать сервисы Амазонки и Ажура. Вот тогда наверное и будут спрашивать о них :)
Во-первых, удачи, во вторых я бы подождал постить это, так как они могут увидеть и, сам понимаешь, тайна компании, и.т.д.
А так, скоро наверное и GIL с Multithread будут ненужны, за них всю работу будут делать сервисы Амазонки и Ажура. Вот тогда наверное и будут спрашивать о них :)
Флешбеки словил. У меня не так все долго было и после 2 или 3 задачки отказали. Мы параллельно весело болтали с интервьюером, и я в их блокнотике в .append скобки квадратные написал. Меня это никак не оправдывает — я сам тупень, но сейчас прям благодарен этим скобкам.
При всем этом, Яндекс остается хорошей компанией для работы.
Самое веселое, что эти собеседования, скорее всего, результат «работы» очередного эффективного менеджера. А репутация не манагера, а компании. Ну и вспоминается анекдот про строителя мостов и овцу.
При всем этом, Яндекс остается хорошей компанией для работы.
Самое веселое, что эти собеседования, скорее всего, результат «работы» очередного эффективного менеджера. А репутация не манагера, а компании. Ну и вспоминается анекдот про строителя мостов и овцу.
Поделись плиз своим опытом. Мой — очень похож с разницей в яп.
В гугле 3-4 алгоритмических интервью. Но это не 10 задач. Обычно дают 1 задачу с дополнительными вопросами. Вроде: сначала напишите совсем простой случай. Потом а что если у вас данные вот такие придут?
Насколько я понимаю, в таких собеседованиях хотят проверить не только алгоритмическую подкованность и желание работать в Я (если хорошо подготовился и порешал задачки — значит, хочет сильно),
но и понять, как кандидат думает и насколько хорошо вливается в коллектив разработчиков.
Возможно, навыки, необходимые для решения таких задач, положительно коррелируют с результатами в Яндексе.
Учитывая количество внутренних велосипедов в Яндексе, часто у кандидата могут актуальные навыки только на таком низком уровне (stdlib, конечно, тоже, но тут не знаю, почему её знание не проверяют).
Сам недавно проходил такие секции — впечатления неоднозначные.
но и понять, как кандидат думает и насколько хорошо вливается в коллектив разработчиков.
Возможно, навыки, необходимые для решения таких задач, положительно коррелируют с результатами в Яндексе.
Учитывая количество внутренних велосипедов в Яндексе, часто у кандидата могут актуальные навыки только на таком низком уровне (stdlib, конечно, тоже, но тут не знаю, почему её знание не проверяют).
Сам недавно проходил такие секции — впечатления неоднозначные.
я там понимаю в гугл или фб гоняют по собесам, но там и зп соответствующие. А яндекс то что может предложить? зп которая ниже чем средняя по рынку, ниже чем у многих других отечественных контор, где на собесах по делу спрашивают, а не экзамены устраивают. Есть еще плюсы?
Вот, сходил даже за первым попавшимся примером:
1) вакансия в яндекс на дата аналитика:
2) ниже сразу какая-то небольшая контора из питера, тоже дата аналитик:
Вот, сходил даже за первым попавшимся примером:
1) вакансия в яндекс на дата аналитика:
Middle от 130к до 200к; Senior от 200к до 300к + полугодовые премии
2) ниже сразу какая-то небольшая контора из питера, тоже дата аналитик:
Middle 2500 — 3500 USD; Senior 5000 — 6000 USD
Ну опять вот это всё. Смиритесь уже, что никого не волнует знание Django или SqlAlchrmy. Это всё наживное, если мозги есть, человек разберётся. А вот закодить эффективный алгоритм для хай лоада — это уметь надо.
Так и алгоритмы — это наживное) Если мозги есть, то при необходимости научится писать более сложные и эффективные алгоритмы.
И как на интервью проверить, что мозги есть? Понятно, что лучший способ — взять человека на испытательный строк в пол года, чтобы уж наверняка. Но это непозволительно дорого.
Если компания может себе позволить тратить время на собеседование сотен и тысяч кандидатов, то видимо так, как и делают FAANG и yandex. Если у компании нет таких ресурсов, то вряд ли есть эффективный способ проверки мозгов и найма специалиста выше джуна. Задачки по алгоритмам не покажут знания и опыт, но могут отсеять много опытных, как и плохие вопросы по теории. Я склоняюсь к тому, что вместо лайфкодинга лучше дать кандидату кусок кода и попросить рассказать, что в нем делает каждая строчка. Дать куски с явно плохим кодом и просить, что в них стоит отрефакторить. Не программисты или совсем новички с этим не справятся, да и опытные не отсеются. Ну а далее особо и нет вариантов, кроме как проверить знание используемого кандидатом и компанией стека, а также понимание некоторых важных в разработке вещей, и нанимать того, кто показал себя лучше остальных. Дальше уже как повезет. Конечно же это не универсальный способ и подойдет не всем компаниям.
Вроде уже несколько раз прозвучало выше что яндекс таким образом нанимает людей, которым можно внушить корпоративные ценности и которые не будут задавть лишних вопросов. Как показывает эта статья — со своей задачей они справляются, автор отсеился, а если бы прошел то сам бы свалил в течение пары месяцев "задачи мусор и инициативы вообще не дают".
Это раз, второе — когда у вас гигантский поток заявок то нужно отсеивать хоть по каким-то признакам. Хоть по цвету кожи, хоть по гороскопу, хоть по байке "зачем нам нужны неудачники". Если вы физически не можете проводить единолично 100 собеседований в день и на первый взгляд все резюме +- одинаковые — все прекрасные крутые спецы с кучей опыта и интересными проектами — то приходится фильтровать хоть как-то. Например разделить 100 кандидатов на 20 подчиненных и попросить их пройти какой-нибудь бессмысленный формальный критерий. Ну и дальше от них уже отсекать какой-то процент.
Это раз, второе — когда у вас гигантский поток заявок то нужно отсеивать хоть по каким-то признакам.А зачем кого-то вообще отсеивать? Нужно набрать условно сотню человек по разным позициям — обрабатываешь входящие заявки до тех пор, пока не наберешь, после чего закрываешь вакансию. Вряд ли кто-то всерьез надеется на таких объемах брать лучших из лучших. Подходят под требования — и ладно.
А зачем? если можно улучшить корреляцию и вместо 0.1% шанса найти кого нужно сделать 0.2% шанса назойливыми вопросами — то это в целом удвоение качества поискав 2 раза, хотя 99.9% и 99.8% отказов со стороны кажутся примерно одним и тем же.
Ну то есть не факт, что человек знающий алгоритмы — молодец, а не знающий — лохопед. Но зачастую хороший разработчик шарит и за базовые алгоритмы, а если нет — то придумает на ходу. У меня недавно собес был, спросили про MESI (алгоритм когерентности кеша в цпу), а я ни в зуб ногой. Помню что лет 5 нзад в википедии читал про него, в памяти осталось только что там 4 режима работы. Ну и как бы ничего, с подсказками от интервьювера минут за 20 переизобрел режимы и зачем они используются. Просто исходя из простой логики разработчика с опытом работы с многопотоком.
Точно так же изобретал каналы — для меня это всегда была штука куда ты пихаешь данные и они с другого конца видны — без мьютексов и каких-то других дорогостоящих синхронизаций. И тоже — не интересовался никогда, но после предложения "давайте вы попробуете придумать такую структуру данных, думаю у вас получится" и некоторых подсказок тоже смог придумать и spsc и mpsc каналы. ИСЧХ теперь я думаю я это навсегда запомню — вымученное таким трудом запоминается.
В итоге да, вместо часа интервью заняло почти два, и незнание каких-то вещей в целом не помешало успешно пройти (позвали на второй и третий этап) собеседование. Задачка это бусидо — не цель, но путь. Важно не решить задачу, а продемонстрировать свои навыки в процессе. Например вот так.
Я чего-то не пойму первое задание безвоенное задание что-то выдает не то, а во втором варианте есть несколько описок
result.append(el) # то это успех
b_dict[el] -= 1
result.append(el) # то это успех
b_dict[el] -= 1
def common_elements(a, b):
b_dict = defaultdict(int) # defaultdict выжил :)
for el in b:
b_dict[el] += 1 # я считаю все элементы из b, т.е. типа collections.Counter
result = []
for el in a:
count = b_dict[el]
if count > 0: # если какой-то элемент из a встречается в b
result.append(el) # то это успех
b_dict[el] -= 1 # и я "вынимаю" его из b, т.е. уменьшаю его количество на 1
return result
Сделал для себя такие выводы.
- У Яндекса очень много бабла. Прямо совсем много. Иначе как об объяснить бесполезную трату времени интервьюеров?
1.5. Интервьюеры Яндекса тратят свою жизнь впустую, вместо работы на результат. - Яндекс это отличный тренажёр, чтобы почувствовать себя уверенным на собеседованиях в другие компании.
Собеседование в Яндекс: театр абсурда :/