Comments 1270
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
Бедные курьеры...
Не курьеры, а коммивояжеры.
Авторитетно, как яндекс-курьер получивший оффер, заявляю.
ПС
: sarcasm:
Я не настоящий сварщик, я маску нашёл, но насколько я понимаю, под словами "задача коммивояжёра" и "задача о рюкзаке" могут подразумеваться несколько разные вещи, в том числе NP-полные задачи, так что сведение одной к другой неочевидно в таком простом заявлении, как ваше :)
Но если брать формулировку по «knapsack problem» и «travelling salesman problem» в английской вики — то я не вижу как решение второго свести к решению первого (без многократного повторения или увеличения размерности задачи).
Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)
Руку на отсечение не дам, но вроде бы, в обоих случаях задачи разрешимости NP-полны, и не всегда ясно, когда говорят просто про рюкзак (коммивояжёра), имеются ли в виду оптимизационные задачи или речь про разрешимость.
Насколько я вижу по вики (да и всегда думал) — задачи имеют разное название потому что это разные задачи. Там где задачи явно сводятся к другим обычно это пишут, например тут
The knapsack problem is a generalization of subset-sum.
Если не пишут значится что не сводится одно к другому
Рюкзак и коммивояжёр оба NP-полные, значит оба сводятся друг к другу.
Не согласен с такой формулировкой. Если на си можно написать компилятор идриса а а на идрисе компилятор си это не означает что между ними нет разницы.
Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)
Если вы чистите трубы только тем, кто не может прочистить их сам, у меня к вам есть один вопрос. :)
Я не настоящий курьер, я рюкзак нашёл! У подъезда, вместе с велосипедом
Сколько теннисных мячей поместится в сумку
В голос, спасибо! :)
Через много лет, когда стал Solution Architect, также было интервью по этой позиции, и угадайте каким был первый вопрос?:)
Не, ну это ещё можно вытерпить. Хуже, когда хрюша идёт по опроснику и спрашивает «Какой алгоритм сортировки лучший?».
Это ещё что... Когда проходил собеседование на менеджера продукта, для какой-то важной оптимизированной операции решил использовать бинарный поиск по постоянно поддерживаемому сортированному набор строк (вполне умещались в RAM). А собеседовавший меня менеджер проекта (хотя там ещё был аналитик, не считая HR) завернул мой вариант, обосновав, что тогда потребуется индекс, а операции над ним дорогие при таких объёмах данных и требованиях к производительности. И что характерно, аналитик его не поправил. После этого я уже не стремился в их команду, потому что либо каждый должен заниматься своим делом, либо должен хотя бы знать то, о чём говорит, и понимать, что говорят другие, либо не участвовать в решении при недостатке компетенции. А уж с чем-то минимально сложным с максимальным приближением к реальному практическому решению тот товарищ вообще не совладал (это уже из опыта их приёма выполненного мною тестового задания для самостоятельной работы).
бинарный поиск по постоянно поддерживаемому сортированному набор строк
какая по вашему будет сложность вставки в такой список? и устроит ли она вас? мне кажется, что вас хоть и не поняли, но вариант вы предложили так себе. хотя и возможно, что если уточнить задачу и ваше предложение, то окажется, что всё хорошо
И ЗП меньше среднего, прям как в Яндекс доставке!
После прочтения предыдущих комментов и поста, а потом вашего коммента, в голове само всплыло название следующего сервиса: Яндекс.Девопс. Ну, знаете, сдача админов, которые почти прошли собеседование, в аренду клиентам Я.Облака.
Ну, чтобы просто результаты собеседований хоть как-то применить, даром, что они по алгоритмам!
На многие вопросы из первой части я ответил с большим трудом, а на некоторые ответов вообще не знал, что наверняка и послужило поводом меня слить)
Такое впечатление, что в яндексе хорошо умеют проверять знание алгоритмов — вот и ищут специалистов где светлее, а не за углом где потеряли.
Правда это было достаточно давно, что бы Яндекс не мог засудить меня за разглашение, ибо соглашение о неразглашении истекло.
Меня не взяли водителем беспелоднега хотя я идеально соответствую требованиям вакансии. Про алгоритмы, с.ка, даже не спросили...
И еще кучу беспонтовых вопросов
В моем случае это правда: соискал позицию тестера. Правда, отшили после двух и "зошто" не случилось.
Они проверяют не эрудицию (знания) а ум - умение думать
Задачки нормальные, но зачем столько? Трёх-четырёх достаточно. Я бы уже на втором таком интервью вежливо распрощался, если я захочу порешать задачки, я пойду на hackerrank или leetcode.
В свое время я не успел решить одни задачки на время, честно сказал интервьюеру, что если им так нравится, они могут сами решать олимпиадные. В ответ получил оффер.
Они созданы, чтобы проверять знание кандидатом базового синтаксиса. Конечно, немного думалка тоже проверяется, но алго-думалка с обычной не совсем коррелирует и даже скорее совсем не коррелирует.
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
Но там не задают задачу на написание хеш таблицы. Максимум на использование. И полностью рабочее бинарное само-балансирующееся дерево — тоже не задают. Максимум тривиальное дерево. Просто для проверки, что кандидат может представить структуру и хоть чуть-чуть понимает, как работают указатели.
И на софт скилах не выедешь, как можно сделать в разговоре за жизнь.
И можно разных кандидатов сравнивать друг с другом. По формализуемым признакам.
Предложите альтернативный вариант. Чтобы не хуже было хотя бы по этим критериям.
Какой варинат решения прелагаете? Спрашивать еще сложнее? Рюкзак модифированный так чтобы его случайный человек не узнал пойдет? Так отсеются вообще все. Случайный мидл даже после сидения на литкоде не справится же.
Более-менее нормальный подход — давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить (то есть надрочиться на литкоде не поможет), а головой подумать, плюс и прикладной смысл чтобы был, и дать человеку ее решать в привычной среде — просто расшарив экран. Пусть гуглит что хочет (кроме прямого решения задачи, конечно), вообще разрешено все (как и что человек гуглит — это вообще о многом сразу говорит!). И посмотреть, КАК человек это все делает. Такое, типа, парное программирование.
Тут, конечно, формальных баллов не начислишь, все субъективно. Но уровень сразу виден, уже через пять минут на самом деле.
давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить
Ну посмотрите же задачи из статьи. Где там хоть одна, где надо алгоритмы помнить? Максимум, знать, что есть такая структура данных — хеш-таблица.
А примерчик ещё проще чем в статье можно? Там все еще проще вырождается в однострочник или физзбазз.
IDE или не IDE дискуссионно.
Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.
Ну так в отличие от ИДЕ от вас не требуется написать компилируемый код, а иногда не требуется и брать существубщий ЯП — достаточно просто набросать алгоритм, чтобы было понятно что куда и как. Вангую что никто не будет докапываться если в каком-нибудь SelectMany букву забудете или порядок аргументов какой-нибудь функции перепутаете. Главное как вы будете рассуждать и какие уточняющие вопросы задавать.
Если от вас требуют написать без ИДЕ на бумажке идеально компилирующийся код без ошибок — то это вполне хороший фактор чтобы туда не идти. Так что не вижу ничего плохого в том чтобы получить на такое отказ.
Но вопрос в основном в театре абсурда, когда тебе на 10 интервью задают то одни то другие алгоритмы И НИЧЕГО по технологиям
А в разговоре за жизнь можно много чего узнать. Что человек сделал, зачем, почему.
пишет алгоритмы а не программы
Что? По определению, любая программа — алгоритм. Если вы придираетесь к тому, что там на интервью спрашивают заумные алгоритмы, которые в реальной работе не пригодятся — то вы не правы.
Вам так сложно представить, что в яндексе может возникнуть задача взять общие элементы из двух списков (задача из статьи с интервью)?
Я за свою недолгую пока карьеру в гугле много раз использовал и математику и писал хитрую структуру данных, и динамическое программирование. Не каждый день конечно, но эти вещи реально пригождаются. И самое печальное, что если этого всего не знать, то даже мысль не возникнет о том, что вот тут можно было "алгоритм" впендюрить и получить более быстрый и простой код. До этого немного поработал в яндексе, и там пришлось, например, использовать trie для ускорения процесса в несколько раз. Этой структуры нет в stl. Про нее надо хотябы знать, иначе как вообще ее нагуглить?
Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
Так ведь в каждой конкретной ситуации надо смотреть и думать, что нужно. Не может быть универсального решения, т.к. где-то очень важен lookup-time (не асимптотика, а чистое время), где-то важен объём памяти, занимаемый данной структурой. Вы, кажется, не понимаете, что когда речь идёт о миллиардах, то начинает быть важна каждая мелочь.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
Ну всем подряд и не задают. У вас тут типичная ошибка выжившего. Те, у кого интервью прошло нормально — они на хабре статей не пишут. Тут не принято писать о том, что в Яндексе хорошие собеседования, за такое можно и минусов отгрести. Поэтому вы со стороны видите только те собесы, которые прошли отстойно. Или прошли нормально, но человеку не хватило компетенции понять, что его вообще спрашивали и какие скиллы проверяли.
— это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),
— это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.
Бардак с «деревом» собеседующих (изоляция процесса найма от реальных задач, как результат этого), размер компании, а также некоторые решения, которые ранее использовались Яндексом, склоняют меня к тому, что более вероятно второе. Ваш же аргумент косвенно исходит из первого, а возможность второго — игнорирует.
— это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),
О, ну тут всё просто. Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива». Потому что им на практике нигде не надо было работать работать с большими данными и, соответственно, задумываться про асимптотику и т.п. Поэтому к «реальным» задачам далеко не все могут перейти. Но они есть, вполне себе интересные.
это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.
Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).
Текущая система используется (кстати, в том же FAANG примерно всё то же самое при найме — регулярно прохожу собесы чтобы «знать рынок») не потому что идеальная, а потому что пока лучше ничего не придумали.
Но тут ведь система со смещённым фидбэком: если мы наняли слабого человека (т.е. человек оказался слабее, чем показалось при найме), то мы об этом узнаем; а если не взяли сильного (т.е. человек оказался сильнее, чем нам показалось) — то не узнаем. Поэтому очень сложно подобрать оптимальное количество и сложность задач.
Есть ещё интересное соображение: если давать много простых задач, то можно не успеть дать сложные (и недооценить кандидата). И это действительно правда, изредка так и бывает. Но если дать сразу сложную задачу и кандидат её не решит — тут всё намного хуже. Т.к. если кандидат не решил сложную задачу — это не значт, что он не подходит, мб он пойдёт на должность ниже. Надо разибраться с причиной того, почему конкретно человек не смог решить задачу — а это ну очень сложно. Я видел как люди на собесе очень хорошо всё рассказывают по плану задачи, но не хватает времени написать код. Их берут в штат, и оказывается, что люди и код-то толком писать не умеют. Это было бы отлично видно, если бы дали простую задачу, но т.к. дали сложную — то подумали, что «перемудрили с задачей, давайте просто дадим ему не сениора, а мидла».
Все перечисленные нюансы — реальность, но другого порядка.
Вы налили тонну воды, но ответ все же дали — две задачи должно быть достаточно для общего случая.
Я не дал ответ который вы хотели услышать. Но если вы читали невнимательно, то вот мой ответ:
сколько нужно — не знаю.
На деле же, когда у компании 1000 кандидатов, а нанять надо 50-100, то интервьеров будет человек 100. Из них части попадутся знакомые знакомых, часть окажется олимпиадниками, которым ничьих знаний не будет достаточно, части будет не жалко нанимать всех, кто решит простую задачу, которую решают на первом курсе любого вуза. А ещё кандидат может одному интервьюеру понравиться, а другому нет визуально, может разволноваться с одним интервьюером, а с другим — нет и т.п. Получится рандом, усугубленный тем, что сильных кандидатов меньшинство.
Для примера пусть из 100 собеседующих 25 не наймут никого, 25 наймут любого, а 50 наймут сильного кандидата и не наймут слабого.
Пусть из 1000 кандидатов 100 сильных (кого в идеале хотел бы нанять Яндекс; каждый 10й).
Тогда при одном собеседовании на каждого кандидата будет нанято 25% (шанс попасть на лёгкого собеседующего) * 900 = 225 слабых кандидатов и 75%*100 = 75 сильных. А надо бы, чтобы соотношение было 0 на 100.
Вот и делают дублирующие собеседования.
Если на каждого кандидата по две секции и нанимают только тех, кто прошел обе, будет нанято 56 (900*0,25*0,25) слабых кандидатов и 56 сильных. Уже лучше, но соотношение всё равно плохое. Даже один слабый прогер уровня миддла может уронить продуктивность команды из 3-5 сильных мидлов.
Делаем третье собеседование. Наняли 14 слабых и 42 сильных. Ещё лучше, но большая часть сильных будет отсеяна.
Делаем четвертое и разрешаем одно собеседование провалить. Получаем 900 * (0,25 ** 4 + 0,25 ** 3 * 0,75 * 4) = 45 слабых и 73 сильных.
Много слабых. Добавляем пятое собеседование на ту же тему (одно можно завалить)
Получаем 14 слабых и 63 сильных.
Если сделать 6е, получим 4 слабых кандидата и 54 сильных.
Примерно поэтому в Яндексе обычно 6 секций +- одного и того же. В Гугле аналогично.
Нормально, что среди 942 отсеянных находятся те, кто пишет статьи на хабр о том, какие неадекваты в Яндексе. Согласно модели шанс, что это подходящий Яндексу прогер, процентов 5.
Но по подходу автора (писать квадратичную асимптотику вместо линейной, потому что так привычнее) видно, что тут к Яндексу только один вопрос — зачем было тратить время кандидата и интервьюеров на секции после 2й-3й.
Вы меня поразили прям в мозг. Ну добавьте тогда в ваш зоопарк интервьюеров, которые выдают результат в зависимости от дня недели, и интервьюера, который убивает кандидатов с шансом 50%… В моём понимании интервьюер — это функция, которая принимает на вход знания кандидата и выдаёт 0 или 1. Если этот интервьюер выдаёт много FP или FN, значит это паршивый интервьюер и нафига он нужен. Если есть шанс ошибки, то поставьте 3-4 интервьюера рядом и пусть они исправляют друг друга. Добавьте ещё штуки 4 теста для быстрого вылета кандидатов, типа если напишут O(n^2) или если ник начинается с k, то сразу отлуп. Всё.
Судя по тому, что я видел, Яндекс не парится и берёт пулл кандидатов, пулл сотрудников, и как на той картинке с игрушечными собачками скрещивает их. А ведь эту кучу часов, которые рекрутеры тратят на кандидатов, можно было потратить, чтобы — внезапно — улучшить рекрутеров самих и весь процесс в целом.
Я как кандидат — в печали. Я хочу максимально быстрый ответ и, желательно, фидбек. Тут ни того, ни другого. Ну хоть посмеялись всем хабром.
Не очень понятно, как вместо того, чтобы собеседующие проводили по 6 секций с каждым кандидатом, пустить их время на улучшение процесса. Сажать по 6 человек на кандидата — не уменьшит времязатраты интервьюеров, но уменьшит точность за счёт меньшего числа вопросов.
Есть ли примеры крупных IT-компаний (1000+ разработчиков, не бодишоп), где быстро собеседуют и быстро могут дать положительный фидбек?
В гугле с момента подачи резюме до оффера проходит 3-6 месяцев. В Яндексе 1-2 месяца. Да, не неделя, как в небольших компаниях, но раз недостатка в кандидатах нет и акции растут, значит всё работает норм.
раз недостатка в кандидатах нет
спорное утверждение.
Ко мне рекрутеры Яндекса обращаются с завидной регулярностью. Причем уже доходило до того, что мои данные «передавали» в КА/РА, которое работает на Яндекс.
Ко многим знакомым — тоже.
Да, не спорю, туда все еще многие мечтают попасть, но есть ли прямо очереди? Чё-т не уверен.
Активность HRов, это вполне предсказуемый процесс. Яндекс хочет нанимать самых подходящих специалистов на рынке. При этом сильный кандидат может и не подозревать, что его примут в Яндекс. Поэтому Яндексу в целом выгодно множество HRов, которые ходят по рынку и холодными звонками выцепляют людей на собеседования.
И HRы эти далеко не всегда сотрудники Яндекса. В целом есть распространённая модель партнёрства, когда ты заключаешь с компанией договор о том, что она с каждого трудоустроенного от тебя кандидата платит тебе процент. А дальше ты сам себе хозяин и ищешь кандидатов где только можешь. В результате да, бывают эксцессы, а люди могут сокрушаться в комментариях, мол «мне написывал HR из яндекса, как же они задолбали», но это не признак недостатка желающих пройти собеседование.
Мне, например, когда я работал в Яндексе, в Линкедине писали такие HRы предлагая прийти на собеседование в Яндекс. Бывает, что уж
Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива».
Если инплейс то можете подсказать как? Потому что так-то ничего сильно лучше arr.Where(x => x != 0).ToArray() и не придумывается.
Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).
Можно тоже пример? По опыту в маленьких компаниях это отлично работает, не очень понятно что именно должно сломаться в случае большой. Или у вас в маленьких тоже не работает? Тогда тем более хотелось бы услышать ответ.
Если инплейс то можете подсказать как?
Примерно так:
function remZero(arr) {
var p = 0;
for (var i = 0; i < arr.length; ++i) {
if (arr[i] !== 0) {
arr[p++] = arr[i];
}
}
arr.length = p;
}А ну да, логично, даже странно что я про это не подумал. Мне почму-то показалось что мы можем элементы местами менять и нарушить относительный порядок. Немного не в ту сторону подумал.
В целом это и есть arr.Where(x => x != 0).ToArray() только копируем прям на месте вместо свободных нулей. Да, спасибо, тупанул чет
По прошлому опыту это ведь не просто "наврите нам покрасивее" а вопросы по этому опыту. Почему сделали так, а не иначе. А вот зачем этот компонент. И так далее.
Плюс можно гитхаб посмотреть если есть, если нет — то все же какую-нибудь задачку разминочную на 10 минут тоже можно. Это не дрючить 10 алгоритмическими задачками на 5 раундах собеседований, но какое-то видение дает. Вкупе с вопросами по арихектуре можно делать выводы.
Уже сейчас есть в интернете куча платных и бесплатных курсов, задрачивающих людей решать задачи. Т.е. человек без опыта может научится решать задачки и пройти интервью.
Если FAANG будет спрашивать массово про опыт и профиль на гитхабе, то будут курсы, которые будут учить людей складно рассказывать про "прошлый опыт" и объяснять по этому чужому профилю на гитхабе, почему сделали так, а не иначе.
В текущей ситуации имеем людей, возможно вайтишников, которые научились решать алгоритмические задачи. Значит перекладывать json они точно смогут, ибо это проще. В гипотетической ситуации будем иметь кучу вайтишников, очень слабо программирующих, но складно говорящих.
Вторая проблема: поговорить про опыт и посмотреть гитхаб — слишком субъективные оценки. Такое не годится для крупных компаний, которых пытаются засудить за дискриминацию, потому что интервьювер посмел спросить про размер байта в битах.
А еще это на порядок сложнее для интервьюверов. Сходу вот так глядя на неизвестный вам проект понять, что вот такое решение было лучшим, невероятно сложно. Это потребует невероятно много времени подготовки у интервьювера. Когда как задачки можно спрашивать одни и те же, пока они не утекут в сеть.
Вот и получается, что спрашивать задачки — единственно подходящее решение для интервью в FAANG/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.
Если 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% случаев.
Сколько не работал с кодом, обычно существует одно место, которое тормозит больше всего, и это место отвечает за какую-то io работу в духе "сходи забери из базы что-то с кривым запросом". Переписываешь запрос и все работает :)
Даже во всяких cpu-bound задачах довольно часто спасает кеширование или исправление конкретного места.
Буквально на днях столкнулся с "возросшей нагрузкой" — есть корпоративный портальчик, ничего супер-пупер нагруженного, состряпали, запустили, пользуемся… через пару лет начинаются жалобы — тормозит. Автор портальчика к тому моменту уже потерялся, полез смотреть сам (я не программист) — оказывается, при каждом действии, ajax шерстит историю сообщений, чтобы в случае чего новенького отрисовать "колокольчик", а сообщений накопилось уже немало, а в алгоритме почему-то был линейный перебор с "ручным" анализом "новое/прочитанное" (таблица ID прочитанных сообщений была у каждого пользователя своя, а таблицы сообщений шли сплошной простынёй)… казалось бы — сделай запрос к базе по JOIN с "объединением по NULL", чтобы отобрать только непрочитанные, но автор решил несколько иначе — выбирал все сообщения, а потом искал их ID в "личной" таблице, и если не находил — высвечивал оповещение.
Вроде рабочий алгоритм, но вот с масштабированием совсем боль.
Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
Ну так это ровно то же, что вы пишите. Выборка данных + расчет производных данных на их основе (преобразование функциями, сумма, вот этот весь треш).
Если вы фильтруете или преобразовываете данные потом на бекенде, то тут что-то немного не так. Иногда это ваша вина, иногда бд.
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
Я на самом деле очень люблю оптимизировать. Я несколько лет работал научным сотрудником в сфере, где широко использовалась wolfram mathematica. Я очень заморачивался над вещами типа сведения интеграла к сумме по элементам массива, над вставками на C, которые работали быстрее, итд. Но я это делал уже сильно после того, как написал первый прототип программы, который работал нормально, а потом захотелось больше отзывчивого UI. Я не считаю, что рядового кодера в стрессовых условиях собеса нужно мучать на оптимальные алгоритмы. Для этого давно есть библиотеки и только в редких случаях возникнет реально проблемный боттлнек, где придётся оптимизировать код. Если такое случится — ну, ок, сядет разраб и в спокойной обстановке поищет, в чём там проблема.
Типа, сначала строим дом, потом смотрим, что получилось неплохо, но нужно сделать канализацию, затем снова поднимаем краном и прокладываем водопровод. Разматываем электрические провода вокруг дома, снимаем обои и начинаем штробить стены.
При строитенльстве домов теже проблемы, только в меньшем масштабе. Возьмите типичную квартиру и посмотрите как расположены там розетки, используются ли вские тройники и удлинители. А ведь это все можно было решить на этапе ремонта. Вот только для этого нужно точно знать где какая мебель будет стоять, какие у неё будут размеры, какие электроприборы и где будут стоять и использоваться. Точно это предугадать невозможно, поэтому и возникают все эти удлинители или абсурдно огромные группы розеток "на всякий случай".
Так же и в разработке софта. Мы зачастую не знаем сколько у нас будет пользователей конкретной фичи, не знаем какие фичи будут добавлены завтра, а какие убраны. Мы даже не знаем кто будет завтра с этим кодом работать. То что мы знаем точно — так это то что проект точно будет меняться или умрет. Но что именно будет меняться — можно лишь гадать. И правильно угадывать мы будем далеко не всегда. Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем, пытаться предсказать что может поменяться, а что нет. А еще, чтобы его могли понять другие разработчики, желательно без необходимости вникания во всю историю проекта. Хороше же оптимизированный код зачастую сложно читать, сложно расширять. В итоге приходится балансировать между расширяемостью, читаемостью и оптимизацией. Хороший разработчик — не тот кто упарывается в одну из этих крайностей, а тот, кто умеет находить баланс в каждом конкретном случае. Когда надо — писать хорошо оптимизированный write only код, а когда надо — медленный, но легкочитаемый и/или легкомодифицируемый, а в большинсте случаев — что-то среднее.
Хороше же оптимизированный код зачастую сложно читать, сложно расширять.
Это только если упарываться микрооптимизациями. Если просто использовать нормальный алгоритм или структуру данных — то код часто даже проще и понятнее. Что легче — полный перебор через рекурсивную функцию с откатами и неочевидными отсечениями, или динамическое программирование, которое все — 2 вложенных цикла и тривиальная формула для пересчета одной ячейки массива через соседние?
Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем,
Спасибо, вы меня поняли. Заморочиться и написать fast inverse square root всегда можно потом.
Если же Вы прораб и делаете ремонт «другим», то тут грубо говоря два варианта: 1) прораб
Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…
Рефакторинг отнимает кучу ресурсов, больше, чем было бы потрачено на изначально грамотное проектирование. В конечном итоге рефакторинг откладывается до лучших времен, баги митигируются костылями, мейнтенанс и дев луп растут.
заходишь такой в интернет-магазин… и обычный обывательский мобильник вешается.Зашёл я как-то на один технический новостной сайт с обычного пользовательского мобильника…
Впрочем, ходят слухи, что уже ведётся работа над новым движком для комментариев, и к осени он будет готов. К какой осени — источник умалчивает.
В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку
Браузер стерпит. Пользователь может и не стерпеть.
И как люди без электричества сотни лет жили?
Раньше работало, плохо но работало. Сейчас если Яндекс падает такси в России перестает работать. Надо теперь с этим жить.
А конкуренты куда делись?
В прошлом году полдня Яндекс такси лежало, все конкуренты легли под нагрузкой сразу же.
https://habr.com/ru/news/t/487130
И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.
Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.
Критический путь можно так проверять. И иногда проверяют. Но это даже близко не все методы.
А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.Я ведь верно понимаю, что любой алгоритмист, при устройстве на работу, гарантирует своему работодателю некий аналог sla с несколькими девятками, и полной компенсацией в случае падения прода? Или алгоритмисты только говорить могут, а на деле роняют прод примерно так же часто, как и обычные инженеры?
А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.
Если он сделан прям «так жутко», то он просто код ревью не пройдет.
Всегда есть вероятность что какой-то код написали в тестах. А кто же внимательно ревьюит тесты?
Потом этот же код скопировали в метод нужный в админке. Кто же внимательно ревьют скопированный код на который не будет нагрузки и пользователи все свои?
А потом его вызвали из любого пользовательского метода на который не должно быть нагрузки. Кто же внимательно ревьют не тот код что написан только что, а какой-то там метод? Тем более нагрузки же нет.
А потом пришла нагрузка. И все легло. И никто не виноват.
Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.
Под "алгоритмистами" чаще всего понимают рисерч-инженеров… давайте расскажите, как компаниям не нужен R&D и все можно порешать на уровне понимания "сейчас пройдемся по списку и сложим два числа"...
ну или алгоритмиста
Выделенный алгоритмист не нужен.
У нас был проект, где были выделенные аналитики для увеличения производительности (прям такие математики-предметники). Которые в код реально не лазили.
В итоге (у них было достаточно «веса» чтобы настоять на включении доп.оптимизаций) схема разработки превращалась в старый анекдот про филина и мышей: «я вам решение сказал, а как вы будете это делать — это уже технические (не волнующие меня) детали».
Если же вы имеете в виду, что копия в плане собеседований, то флаг им в руки. Зачем нужно проходить это все в Яндекс, когда можно то же самое все пройти в любую из FAANG?
А что не так? В Яндексе нет настолько умных людей как в FAANG? Или они не делают нормальные сервисы?
В Яндексе нет настолько умных людей как в FAANG?Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.
Или они не делают нормальные сервисы?Ну, не знаю, огромная доля сервисов Яндекса со стороны кажется банальным симптомом болезни «а во. такая штука появилась на рынке, значит, надо делать свой клон». Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
негативных отзывов на поведение контор из избранного списка
Чего чего сделали?
Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
Ну, так сказать, вот они — крутые олимпиадники в действии…
Ой это действительно боль, все еще пользуюсь яндексом по инерции, но заставить его найти именно то что я хотел а не то что он выдумал, это тот еще квест. Особенно весело, учитывая что я работаю с вещами по которым 1.5 статьи и из них одна на английском. Все чаще открываю гугл или утку.
Но справедливости ради это не вина олимпиадников, это вина их начальников. У меня вообще складывается ощущение, что я последний адекватный руководитель на планете, ну что за треш то кругом а.
Ну ок, значит будем людям объяснять что на я.маркете отзывы смотреть нельзя, пусть фламп развивают.
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.
С чего бы это? В сам FAANG конечно больше кандидатов, но вот и мест там значительно больше.
При этом для выпускников местных топовых вузов, как мне объяснял один знакомый из Долины, пойти в Гугл, это не как для москвича после МГУ / МФТИ пойти в Яндекс. Скорее как для москвича пойти в какой-нибудь банк, разгребать несвежее легаси, поскольку местные успешные разработчики стараются идти в стартапы за долей в компании.
Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.
Среднее по больнице на то и среднее, что на больших числах размеры конторы перестают влиять на средний IQ там работающих. )
ps Советую не обожествлять фаанг. Судя по рассказам, локального бардака и бюрократии там куда как больше.
С топовыми компаниями тут ошибка выжившего — не они топовые по тому что у них эффективная система найма сотрудников, а неэффективная система найма сотрудников не мешает им процветать потому что они топовые (много денег и многие хотят там работать).
пройдёт лет 10 и слоупоки-подражатели типа Яндекса тоже сменят пластинку и начнут подражать новым веяниям из Кремниевой Долины
А мне кажется, что они не слоупоки и совсем не подражатели. Просто «отличники» или около того, в большинстве своем. Ну привыкли просто так со школьной скамьи… по другому не умеют. Им бы, наоборот, поучиться у гугла с майкрософтом или у других, более адекватных к собесам российских контор. Вон ниже Emil983 о них [google/ms] рассказывает.
Я уже раза три за последние 15 лет, устраивался в подобных топик-стартеру условиях в топовые компании. Слава богу, попадались адекватные интервьюеры и будущие коллеги. Работа-то далеко не из задачек на классические алгоритмы состоит. )
А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
Окей, в Гугле на первой итерации попросили сдизайнить шедулер тасков, не совсем типичная с литкода, но такие там тоже есть.
Типа надо сделать 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, а что-то, что вы военный радист и получаете донесения с передовой для дальнейшей передачи в штаб. Вам надо раз в день собранный поток сообщений как-то уменьшить в объёме, но сохранить порядок. Ещё известно, что часто подряд приходит много однотипных сообщений. Вопрос — как будете преобразовывать? Тут с помощью интервьюера дойдёте до исходного условия и дальше напишете тот же алгоритм (ну или не напишете).
P.S. я — бывший сотрудник.
Нет, они довели до абсурда худшие практики, которые в FAANG постепенно уходят из повестки собеседований.
Несколько лет назад, когда я проходил свои 4 собеседования в Яндекс, они всё же были другими. Там про архитектуру и проектирование систем спрашивали, про устройство Linux, распределённые системы и т.п. интересные вещи. А то, о чём написал автор — это квинтэссенция идиотизма. Бессмысленная трата времени и очень плохой алгоритм фильтрации и проверки кандидатов.
В начале собеседования с Гуглом, вас потребуют подписать NDA, что ни какие подробности интервью вы не можете разглашать. Какие последствия? Наверное через суд, заставят оплатить издержки, например, потратили время на 1000 кандидатов, которые уже знали заранее ответы, или оплатить 100 часов на переделку всех контрольных билетов. :-)
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 — зло, как по мне.
list((Counter([1, 2, 3, 2, 0]) & Counter([5, 1, 2, 7, 3, 2])).elements())правда не знаю какое тут О
На интервью не требуют писать стандартные структуры данных. Сойдет и использование встроенной хеш таблицы. Запрещают пользоваться стандартной библиотекой там, где есть встроенное решение всей задачи. Иначе проверять нечего.
Ну, на худой конец, можно отсортировать и слить 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. Сделали это как раз те, кто говорит и пишет в каждой подобной теме, как же это тупо — проверять кандидата на понимание алгоритмической сложности. Самому регулярно приходилось и приходится ликвидировать последствия подобного кода. А все потому, что люди даже не видят, не замечают, не понимают, что они на самом деле постоянно сталкиваются с оценкой сложности в повседневных задачах, вот о чем важно говорить.
Инженерное искусство состоит в умении хорошо скомпоновать готовые решения, сделать конечный продукт поддерживаемым и простым в расширении, а так же в умении видеть необходимость оптимизации, когда нужно делать что-то новое. Если готового решения не существует, пойти и разработать свое собственное. Если не хватает экспертизы — посоветоваться с кем-то.
Вы описали какие-то абстрактные требования, вопрос-то в том — КАК понять, что кандидат ими обладает? Я встречал кучу кандидатов (в тч когда побеседовал работников Яндекса в других конторах), которые молоть языком горазды — и расскажут как они сделали «конечный продукт поддерживаемым и простым в расширении» и что у них есть «умение видеть необходимость оптимизации, когда нужно делать что-то новое», но вот беда — hello world написать не могут. Как отсеять болтунов?
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.
> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.
> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
Ну вот я общался с кандидатами — красиво стелят, якобы делали то, сё, пятое, десятое, а hello world написать не могут. Что с такими делать? Поверить на слово что он реально это делал? Тогда почему не может hello world написать? Или включить презумпцию виновности и решить что он балабол и просто сидел на зарплате глядя как другие вот это все описанное делают, а сам JSONы два года перекладывал?
> Как отсеять болтуна-физика, прикидывающегося инженером?
Я не знаю, вы мне скажите=) Для программистов вот есть задачки с литкода — если человек потратил недельку на подготовку к собесу, он их решит. Если не потратил — то точно ли он хочет новую работу или просто так с улицы зашел? Как быть для инженеров — хз, не моя тематика.
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.
Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.
Вы — не гугл. Вы не можете пользоваться этой методикой. Гугл ее использует, потому что богат и может себе позволить найти задротов, нанять их, а потом спустя год работы отсеять тех, кто не имеет инженерных навыков. Вы за год работы этих самородков потеряете деньги и получите малоподдерживаемое глючное дерьмо в продакшне.
Всё же механика часть физики.
И я такой не один, нас таких достаточно много.
В абсолютных цифрах — возможно. А в потоке людей — очень и очень мало. Ну представьте себе что человек проходит какие-нибудь 3-недельные курсы на ютубе, его научили правильно отвечать на "что такое солид" и какие-нибудь киты ООП, но он реально не программист, а какой-нибудь дворник который попал на таргетированную рекламу "заработай 100500 на ~~джойказино ~~яндексе".
И вот на одного такого вас 19 вот таких фот "типа программистов".
Если в маленькой компании с вами могут нормально поговорить по душам и распознать одно от другого (это не трудно, если уделить достаточно времени) — то в компании "на потоке" кроме как собсвтенно попросить кодить это не проверить.
А вот ужастиков через третьи руки слышал, да, вот только ни разу не видел подтверждений, сколько не спрашивал
Увы, тоже пример личный. Один человек вообще себя искренне называл "Аватар тестирования" (я иногда принимаю участие в собеседовании QA, рассказываю про архитектуру и прочие вопросы по компании с точки зрения разработки).
Есть и другие истории, но их пожалуй приберегу, не все из них хочется в паблик писать, мало ли увидят и обидятся.
Если числа не очень большие по модулю — то динамическое программирование, как в задаче о рюкзаке. Будет решение за O(n*M), где M — сумма всех чисел по модулю.
Если числа — любые инты, то только перебор.
А вообще, я невнимательно прочитал задачу. Там надо не подмножество чисел взять, а отрезок из массива. Решается за линию. Идем по массиву считая частичную сумму (до начала). Поддерживаем хешмап уже известных сумм. Смотрим, есть ли там target-<текушая сумма>. Если есть — мы нашли отрезок. Потом кладем текущую сумму в мап.
Нет, просто частичные суммы. От начала до текущего элемента.
Основная идея решения: сумма на отрезке — это разность двух частичных сумм. Поэтому если для каждой частичной суммы достаточно проверить, что левее есть нужная частичная сумма.
Вот набросок кода:
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)
итерируемся по массиву заданных чисел.
если в хештабле есть искомое-текущее значение итератора, значит решение найдено, иначе кладем текущее в таблицу и итерируемся дальше
— один из рекрутеров пользовался компилятором. Просто я что-то нестандартное написал, и без прогона через тесты сложно было понять, во всех ли случаях будет работать.
— на последнем интервью вообще вышло разногласие. Я опять попытался изобрести свой алговелосипед (но не успел), и мнение по поводу работоспособности такого алгоритма у нас с рекрутером разделились. :)
P.S. leetcode крут. Иногда хожу туда за интересными задачками
ЗЫ ну если им по ставке 200к так не жалко своего и кандидата времени, видимо нужно просить 400 с порога
Видимо чуваки, бодро решающие алгоритмические задачки, не в состоянии написать форму обратной связи.
Памятка сотрудникам техподдержки:
Это письмо составлено не потому что проблему у Автора, а потому, что проблема у Вас
Это письмо составлено потому, что Автор уважает труд разработчиков и считает что фидбек лишним не бывает.
Автор сам может справиться любой проблемой или прекратить использование продукта.
Если вас устраивает, что ваши пользователи будут сталкиваться с вышеописанной проблемой, просьба проигнорировать это письмо или в ясной форме озвучить свою позицию в ответе.
Во вторых писал я с действительно серьезными ошибками по их api/интерфейсам.
По более мелким типо отсутствия заливки фона в firefox, да, бесполезно.
Такие же наблюдения. Не понимаю где они берут специалистов с таким подходом?
Создалось мнение, что хорошие спецы попадают в большие компании будучи купленными в стартапах, а там где стартапов нет, там одни задроты-алгоритмены.
Но может это тоже работает? Нанимаешь абстрактного алгоритмена в вакууме и расширяешь необходимыми методами
Хотя, глядя на современный софт, и, даже фреймворки, разрабатываемые корпорациями, (привет гуглу и фейсбуку), которые, вообще, должны быть эталоном кода, понимаешь, что и там квалификация вайтишников на донышке.
ЗЫ опыт работы с пхп чуть больше года, уже три тикета на гитхабе aws php sdk создавал, и объяснял как им надо их баги исправлять… Мир катится в ад
А вот обратное — уже проблема. Если человек владеет инструментами, но алгоритмы сочинять не умеет, то он застрянет на вполне себе практических задачах вида «отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты», которые не лежат в готовом виде на SO.
Ну возьмите одного такого на 50 человек в качестве консультанта, чего ж в этом плохого? Конечно, иногда и список развернуть надо, но с чего бы такое внимание именно на этом аспекте?
Ну тут сразу два перебора получается: 1) спрашиваем три раза про одно и то же; 2) не спрашиваем больше ни о чём.
В некотором смысле каждый кулик своё болото хвалит — неудивительно, что люди, которые сильны в алгоритмах, считают, что это и есть самый важный и незаменимый навык. Но человек хорошо разбирающийся в железе или в особенностях того или иного языка/фреймворка /архитектуры тоже может доказать, что его навык самый главный. Тем более, что требования к алгоритмической задаче хорошо формализуются, и всегда можно найти если не своего, так внешнего консультанта, который это решит за лайки или за пиво.
Нужны совсем-совсем другие наыки, например, научиться использовать свое приложение. Знаете по моему сотни програмеров по миру делали рандомный лут в играх. Помню ровно одну игру с нормализацией на матожидание игрока и еще помню в диабло фикси на эту тему, все, в остальных «корейский рандом». Умные книжки на эту тему кстати есть.
Но в целом, это проблема постановки ТЗ со стороны геймдизайнера. Т.к. плотно сцеплено с UX, монетизацией и прочими вещами вне основной проблемной области программиста.
Потому что вот это «честное распределение» — оно опирается на субъективность восприятия и геймдизайнерам приходится с коэффициентами играться, чтобы с точки зрения игрока всё было как надо (ну и чтобы киты в итоге побольше донатили, куда без этого)
оно опирается на субъективность восприятия
Я понимаю. Но кроме того, если бы я лично, в своей игре, увидел провал заточки 10 раз подряд, при шансе 75%. Я бы разработчика конкретно этой части заставил эти шмотки сутками точить, до просветления.
(ну и чтобы киты в итоге побольше донатили, куда без этого
Нуда, кто же сейчас игры то хорошие делать будет, главноеж китовый донат, точно, я забыл)
провал заточки 10 раз подряд, при шансе 75%
А сколько раз максимум можно? 4? А почему не 3 и не 5? :)
Поймите, я понимаю проблематику, но я встречал разные реализации и оцениваю игру еще по такому показателю как «комфорт».
для опыта игрока должно получаться 3.
Не для "опыта", а для "эмоциональных ожиданий". Игрок, имевший опыт бросания монетки или изучения теорвера, как раз имеет опыт что серии — это ожидаемое поведение. И если их нет — значит рандом "накручен", и ещё вопрос в какую конкретно сторону.
А вот эмоционально можно ожидать и что "5% шанс сломать не выпадет никогда, а 75% сработает точно".
как раз имеет опыт что серии — это ожидаемое поведение.
Все верно, и многократное 0 из 10 в это ожидание не вписывается от слова никак
в это ожидание не вписывается от слова никак
Да, это популярное заблуждение. С точки зрения эмоций — не вписывается. С точки зрения теорвера — это поведение рано или поздно обязано случиться. С точки зрения псевдорандомного генератора(а других не завезли) — оно случиться может.
Остаётся только делать не "честный рандом"(как того требуют эмоционирующие игрока) — а накручивать специальные "сбросы серий" и прочий мухлёж(да) чтоб эмоциональное ощущение не страдало.
При наивных реализациях нюансов слишком много и комфорт игры резко падает, да что там я в некоторых играх умудрялся вычислять временной диапазон, когда ГПСЧ работает на меня (энтропии видимо не хватает).
Кстати мы с вами говорим о достаточно высоких шансах, при низких такой треш начинается…
И на эту тему есть даже примеры:
— У 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% современных разработчиков не понимает что это значит, потому что в свои игры не играет.
Или попробуйте в какой-нибудь контре из снайперки в упор стрелять, рейт будет сильно ниже 95%
Хотите делать промаху в упор? Смотрите в сторону d&d и спасбросков, «противник схватил винтовку за ствол и отвернул ее от себя!» с шансом на определенной дистанции, не будет так бесить и заставит держать стрелков на дистанции. (хотя схватить за ствол винтовку когда палец на спусковом крючке — ну такое, но это я на вскидку)
О господи, ну я вам даже дал в пример другую игру, погуглите что ли, прежде чем рассуждать.
Включите 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 раз орлом падает — это невозможно и монетка кривая. Все же знают забавную задачку на подбросить монетку и потом записать результаты бросков на бумажку — хороший профессор теорвера всегда знает какой студент правда бросал, а какой просто от балды написал "типа случайные броски".
Если хотите генератор псевдослучайных чисел близкий к идеальному нужно использовать криптографические оценки «случайности» последовательностей.
Да, я думал это все в институте проходят.
Ну я в институте не проходил, но это никак не мешает литературу читать. Хотя о чем мы, сейчас расплодилось аналитиков/пм как грязи, вот только от первых я регулярно вижу блоки условий с кучей веток и отсутсвием внятного описания сравнений, а вторые почтив се тупо играют в передастов. Профильную литературу никто даже не пытается изучать.
Новые менеджеры это боль — модно стало считать, что менеджеру/руководителю не нужно понимать предметную область. Рука-лицо.
С нормальным распределением все проверки должны его учитывать, иначе вы вероятность сосем не ту получите какую планировали.
Вот тото и оно, почему то вдруг все решили что могут руководить чем угодно. Теперь модные термины «цифровизация», «гипотезы», «верхний уровень» и прочий булшит. А на самом деле как пытались перестроить сарай в международный аэропорт, так оно все и осталось.
Например точим дешевые палки-копалки пока 3 раза подряд не сломается, а потом затачиваем мифрильные трусы +8. Ура, мы порушили экономику.
Значит придется более сложные данные хранить и мы только что на ровном месте усложнили всю систему. А глобальный беспристрастный рандом такой проблемы иметь не будет :)
Значит для каждого игрока придется заводить записи в БД: «неудачных заточек медных мечей», "«неудачных заточек железных мечей» и т.п.
Ну чтобы когда у него 7й медный меч сломается на 8й раз точно получилось, но при этом он не мог мифрильный меч проточить с 100% гарантией.
При заточке предмет ломается. Так что когда 10 раз подряд фейлится 75% шанс — ломается 10 разных (одного типа) предметов.
В моем примере нет, не ломается. Вообще механика слома все реже появляется нынче.
Просто в LostArk есть тн «фетранит» который как раз «точится» красиво так, в рядочек, с уменьшением шанса на каждую попытку и сам я встречал и у знакомых и у стримеров можно найти где заходишь и так ррраз всю полосочку зафейлил.
Попробую найти, если получиться — кину, но не гарантирую. А вообще я пря мотчетливо помню, что была статья по лут в d3. Там был интересный нюанс, что разработчики при инициализации игровой сессии усекали лут-таблицу и соответственно вышло так, что если тебе не повезло и твоя шмотка не в списке этой сесии то ты можешь хоть запроходится рифты, шмотка нужная тебе просто не упадет. Это стало совсем очевидным когда за осколи стало можно конкретную часть доспеха покупать, вот тут то и выпустили фикс, насколько я помню фиксом была периодическая реинициализация лут-таблиц в рамках игровой сессии.
Вообще я бы с удовольствием почитал сам о наилучших практиках работы с ГПСЧ. Мало кто вообще об этом задумывается, но ГПСЧ подбирать нужно под конкретные цели. Самый яркий пример: отреверсил в одной игрульке как раз такую проверку и прогнал 100 симуляций на матожидании игрока (ну пусть будет 100 попыток), выяснилось что фактический шанс в 10 раз ниже заявленного, хотя по коду это совсем не очевидно.
В этом плане меня варгейминг веселят «вот посмотрите, мы сделали 100 выстрелов на нашем тестовом контролируемом сервере, 80% как и заявлено попадает в круг.» Вот только мишень плоская и вертикальная, сервер тестовый, а количество выстрелов сильно завышено. Я что в танках что в кораблях попадал в игры где в течении игры _каждый_ выстрел летит куда попало. Да можно сказать что шансы все такое и «неповезло» но когда вы разрабатываете игры вы должны такие вещи находить и устранять, поскольку нет ничего более раздражающего и демотивирующего.
Интересно было бы почитать про рандом из мира CS. Такое ощущение, что там коэффициент удачливости устанавливался на запуске игры, потому что было проще перезапустить CS, чем мучиться с не попадающими никуда пулями))
Разброс относительно точки последнего выстрела с поправкой отдачи, рандомный, обычно на много меньше отдачи. Зависит от движения и положения, непрерывности огня, вида оружия, глушителя. Последний обычно на много меньше отдачи, возможно раз в 10, возможные исключения — пулемёт, снайперка без прицела.
Вообще, в CS норма — минимально зависеть от рандома, отдачу контролировать заранее(смещать прицел вниз ~ по траектории отдачи), и даже разброс. Последнее вполне контролируется, т.к. следующий выстрел не заново рассчитывается в большом радиусе, а идёт относительно предыдущего в довольно маленьком радиусе.
PS: всё это отличается от версии, хотя база +- похожа. Потому и не люблю CS — повторение одной и той же механики как путь к победе.
Это да, но мне сложно иначе объяснить, что я проигрываю раунд за раундом — перезапускаю CS и начинаю выигрывать так же стабильно. Возможно, какой-то сетевой лаг меняется, но больше похоже, что именно "удачливость" меняется.
технологии -sql, networks etc
java core (multithreading, core libraries)
интервью с менеджером и командой
впечатление субъективно такое — спрашивают по технической части по делу, вопросы интересные и полезные для саморазвития, но достаточно тяжело — где-то 4 часа это длится, и мутные параметры найма, видимо все же они ищут звезд, готовых на переработки и не очень задорого (за бренд Яндекс в трудовой), насколько знаю у них зп остает от рынка
Где-то слышал/читал, что опционы получает небольшая часть сотрудников ~17%, возможно самые выдающиеся, например здесь https://www.vedomosti.ru/technology/articles/2015/04/02/yandeks-predlagaet-sotrudnikam-otvyazat-optsioni-ot-kapitalizatsii-kompanii
Или есть другая инфа?
И что, этот один будет весь код в компании ревьювить и искать, где разработчик не заметил алгоритмическую задачу?
Если же этих алгоритмистов нанимать несколько, то дешевле всех остальных уволить и пусть алгоритм-мены все сами и пишут.
Ну "алгоритмическая" задача ничем особо не отличается от обычной! Вот надо вам, допустим, найти одинаковые элементы в двух наборах данных. И тут человек не натасканный на эти задачки с интервью вполне может использовать 2 списка и проверять на вхождение через стандартную библиотечную операцию, получая O(n^2). Возникнет ли у него тут позыв послать эту часть алгоритм-мену? Казалось бы все тупо. Надо взять элементы из первого набора, которые есть во втором. Так и сделано.
Наверно, я идеализирую «среднего» человека, и у слишком многих в голове ничего не звякнет, но всё же по моим понятиям такое «звяканье» — это на порядок менее жёсткое требование, чем быть реальным алгоритмистом. Ну опять-таки, разве хоть кто-то в здравом уме будет против того, чтобы люди умели писать алгоритмы и вообще думать головой? Тут же весь дискурс исключительно в контексте того, что этому умению придаётся 100% важность, а остальному 0%, как будто бы его не существует. Если завтра по каким-то причинам во главе яндекса окажутся знатоки математики, то точно так же будут собеседовать, спрашивая умения брать интегралы в уме или решать задачи трёхмерной геометрии. Ведь понятно, что если человек не может взять интеграл, то он в целом безнадёжен, можно дальше не смотреть. А если может, остальному тоже научится.
Ну хорошо, допустим эти звоночки происходят практически во всех нужных случаях. Тогда неизбежно false positive. Все равно наличие выделенных алгоритм-менов сильно усложняет работу. Они будут завалены заявками. Имея гугловую поток кандидатов гораздо легче тупо нанимать только алгоритм-менов.
Но это, конечно, так, вырожденный пример, в идеале, конечно, на каком-то уровне надо уметь всякое разное, как мне кажется.
С тем же успехом тогда надо представлять себе карикатурного «алгоритмена», который ни в зуб ногой в архитектуре, и потом надо ещё иметь специально обученного человека на него
И… такой человек как раз есть практически везде. Называется архитектор, technical lead, или еще как-то.
Разность в том, что задачки, "алгоритмические" или нет, постоянно решает любой, кто пишет код. Любой код — это алгоритм. Любые данные — это структура данных. Очень часто тривиальные, да.
Когда надо составить SQL запрос — тут, очевидно, нужен специалист по SQL, можно спросить его. Когда надо придумать, как организовать новый модуль, то очевидно, что это архитектура проекта — надо спросить архитектора.
А когда надо писать код, очевидно, надо спросить алгоритм-мена в команде. s/
Конечно, в идеале все в команде специалисты во всех областях. Но это слишком дорого держать такую команду, да и тогда надо 100500 собеседований проводить и не наберешь столько работников, даже с гугловым потоком кандидатов.
Вообще-то SQL обычно пишут все. И никаких отдельных специалистов по нему нет. В том же Я у меня была секция с вопросами про SQL, когда я устраивался.
К тому же, бэкендеры/фуллстеки на 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).
Прошу прощения. Конечно, я имел в виду "все бэкендеры". А писать SQL, HQL или Criteria собирать — это уже дело десятое. Один фиг, если тормозить будет, то придётся посмотреть, какой SQL генерируется и какой у него план выполнения.
А потом frontend девелопер генерит себе backend JHipster-ом и захреначивает динамический lazy scrolling (тот который SELECT по rownum) и один юзер с мышкой вешает и backend и базу простым движением руки.
Ситуация в Яндексе, кстати местами именно такое впечатление и производит. Все умеют проходить алгоритмические секции, а практически любое решение переделывают каждые несколько лет, т.к. оказалось, что архитектура достаточно жёсткая, чтобы проще было с нуля переписать. Или под конец моей там работы был случай, когда ради оптимизации в одном из компонентов решили кардинально поменять его АПИ, чем вынудили всех клиентов этого компонента переписывать довольно много кода. И ни у кого ничего не "звякнуло" ведь. Хотя теоретически, если есть сомнения по архитектуре, то можно сходить на специальный "Архитектурный комитет" и там её обсудить. Просто сомнений обычно нет, да и "зачем время тратить?" — лучше потом два раза переделать)
Мне это напоминает мем, про то как писатель написал, что занавески синие, а все думают и гадают, что же он имел в виду, может он хотел символизировать тоску и деперессию? Хотя на самом деле ничего кроме того, что занавески были «синие». Так и с яндексом. Ввели они эти собеседования, потому что по ним можно прозрачно оценить прошел ли интервьювер собеседование или нет. Решил задачу лучшим решением, без ошибок написал код — прошел. Нет — не прошел, а то, что к реальному миру эта задача имеет отношение чуть более чем косвенное, ну лучше пока не придумали. А все вокруг бегают и строят теории: да эти задачи показывают как программист мыслит, да яндексу нужны алгоритмисты, да алгоритмисты могут решать любые задачи. Увы нет, всё гораздо проще.
Вот на чем такие утверждения основаны интересно. Типа я вот щас пошел, посидел три месяца на 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. Там нет решения.
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
- Можно в лоб — сделать очередь задачек (одна задача — один кадр) и 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 считают, что достаточно искать именно вторых, а остальное как-нибудь приложится.
В смысле, нельзя распараллелить? Как раз поток jpeg параллелится элементарно: один кадр — один поток.
Учитывая указанные ранее ограничения, конечно:
Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд
с задержкой не более 200ms и максимальным fps
Но, если вам, по каким-то пропущенным мною ограничениям, это решение не подходит, то сжатие jpeg все-равно можно параллелить: косинусные преобразования, квантование и RLE происходят в блоках независимо. Потом уж и не помню, хаффман применяется ко всем блокам сразу или независимо. Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Имелся в виду один кадр
> один кадр — один поток
Верно, а потом склеивать их, но с сохранением очередности. Или дропать фрейм, если поток не успел в отведенное время и уже был закодирован следующий. Ответ, которого я ждал.
> Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Можно. Или так, как в предыдущем варианте. Но тут бы надо производительность замерить, потому что может быть не слишком большой выигрыш. То есть это не полностью параллельный алгоритм, стадия reduce тоже довольно тяжелая. Плюс мы получаем огромное количество переключений контекста на одну картинку. Так что сжимать фреймы целиком все-таки лучше.
Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
Выкинуть армы, оставить один для управления.
Сверху напаять плисину (плюс покупная библа) или дсп-шку.
Профитттт! :)
>Хм. На SO, например. Какой там опыт нужен? Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.
Вот поэтому я всегда настороженно отношусь к олимпиадникам и любителям всяких хакерренков. Зачастую они вот так и мыслят.
Архитектуру приложения нельзя нагуглить. Написать код, который работает, может любой дурак. Написать код, который эффективно работает, может куда меньше кто. Разработать же архитектуру, которая выдержит годы развития проекта без его превращения в набор костылей и подпорок, могут единицы. А это в сто раз важнее. Алгоритм всегда можно оптимизировать локально, а неудачная архитектура — глобальная проблема.
«Алгоритм-мен» никогда не сможет решить практическую задачу
И чем эта практическая задача принципиально отличается от алгоритмической? Типа горе от ума? Отсортировать списки он сможет, а сложить 2 числа — уже нет, слишком просто?
А если базы данных c SQL не используется? В гуглах и яндексах всякие свои распределенные системы хранения со своими интерфейсами.
Как человеку помогут знания алгоритмов в написании эффективного запроса
Отличный вопрос, кстати. Как человек, у которого нет знаний в алгоритмах, может проанализировать план запроса и понять, почему он неэффективно работает? Или как он может понять, почему индекс надо перебалансировать, например? Зная алгоритмы, по крайней мере, отдаешь себе отчёт, чем там занимается СУБД, выполняя твой запрос, а не воспринимаешь её как чёрный ящик.
Вы всё с ног на голову перевернули. Человек умеющий оптимизировать запросы
… является человеком, который в той или иной мере изучал алгоритмы. Ну нельзя хорошо уметь оптимизировать запросы, не имея бэкграунда. СУБД — это как раз та редкая область в ИТ, которая буквально напичкана алгоритмикой.
тем более если он вообще о субд ничего не знает.
Ну очевидно же, что если мы берём человека, который ничего о СУБД не знает, то наверное не на должность DBA или DB Performance Engineer? ;)
… является человеком, который в той или иной мере изучал алгоритмы. Ну нельзя хорошо уметь оптимизировать запросы, не имея бэкграунда. СУБД — это как раз та редкая область в ИТ, которая буквально напичкана алгоритмикой.
Все верно, но обратное — не верно.
Ну очевидно же, что если мы берём человека, который ничего о СУБД не знает, то наверное не на должность DBA или DB Performance Engineer? ;)
Зато если отбирать на указанные должности строго алгоритмистов-олимпиадников есть шанс на довольно знатное веселье.
100 раз "да". Ситуация абсолютно уникальная — одна хорошо прорисованная "ментальная модель базы данных" (ну там парсер, кэш запросов, оптимизатор, эвристики, память, буфер сортировки, redo, диск, ...) превращает способного слушать литкодера в достаточно полезного специалиста по отладке запросов СУБД. А гуглить — просто умрешь, сумасшедшее количество деталей и ручек/кнопок (особенно Oracle какой-нибудь).
понять, почему он неэффективно работает
О как, а вы только исходя из знания алгоритмов, можете понять почему запрос неэффективно работает? Поделитесь сим сакральным знанием пожалуйста, а то знаете мы то думали что тут 100500 нюансов.
Зная алгоритмы, по крайней мере, отдаешь себе отчёт, чем там занимается СУБД, выполняя твой запрос, а не воспринимаешь её как чёрный ящик.
Серьезно? То есть обладая общим знанием алгоритмов вы сходу можете понять почему последняя версия пг строит r-tree индексы на порядок быстрее?
Нечеткостью критериев.
Я вам в другой ветке писал про различия между "смогут" и "сделают" — вот лично наблюдаемый случай у меня был как раз такой: х2 времени на разработку и очень сложно поддерживаемый код от двух олимпиадников-снежинок там, где вместо всех примененных наворотов можно было взять чужую либу (работающую медленнее, чего уж там, только это не играло никакой роли).
Могли они сами взять чужую либу? Да конечно же могли. Взяли? Нет, не взяли. Лишние пара недель разработки (и потом еще пара недель на то, чтоб после них подтереть) — это та самая нерешенная практическая задача.
"Взять либу" — это вы только до предпоследнего уровня дошли. На последнем смотришь сколько у этой либы активных авторов, какая лицензия, как быстро они баги закрывают и на что живут при этом, зачем им эта либа вообще. Потом читаешь код, чтобы убедиться, что и сам бы также написал. В общем если надо написать 20 строк я бы не стал тащить либу, слишком много надо сделать, чтобы притащить ее правильно.
Практическая задача — это не просто сложить два числа. Это написать код так, чтобы он был понятен и легок в поддержке. Это правильно декомпозировать его, написать читаемые имена переменных (а не «a, b, c»), сделать его расширяемым для будущих изменений бизнес-логики, грамотно написать тесты, и тд.
Мы же не про сферического коня в абсолютном вакууме, а про некий реальный процесс, работающий в окружении десятков, сотен, тысяч других процессов. И нам важна не только скорость, но и ресурсоемкость этого процесса. Что толку в его скорости, если он под себя отбирает столько ресурсов, что все остальное встает колом пока он работает?
В результате задача уже формулируется примерно так: «есть временное окно, в котором загрузка сервера составляет XX%. Необходимо уложиться в это временное окно так, чтобы загрузка сервера не превысила YY%»
А это уже те аспекты, про которые на олимпиадах нет.
«Алгоритм-мен» никогда не сможет решить практическую задачу. Потому что он наловчился только списки сортировать. А опыту за пределами алгоритмов откуда взяться?Оттуда же, откуда и у тех, кто ни в алгоритмы, ни в сложность, очевидно. Только у него будут дополнительно важные знания и навыки.
ттуда же, откуда и у тех, кто ни в алгоритмы, ни в сложность, очевидно. Только у него будут дополнительно важные знания и навыки.Угу. А еще он на скрипке играть умеет — это тоже очевидно.
Вспоминайте, вводный курс теории вероятности. Что более вероятно: (а) Вася хорошо умеет в алгоритмы или (б) Вася хорошо умеет и в алгоритмы, и в архитектуру?
Что более вероятно: (а) Вася хорошо умеет в алгоритмы или (б) Вася хорошо умеет и в алгоритмы, и в архитектуру?Если Вася успешно потратил при изучении алгоритмов мозговых усилий кратно больше ленивого Пети, то статистически и в любой другой области, в которой он профессионально позиционируется, очевидно, будет разбираться не хуже Пети. Потому что может укладывать в голове сложные объекты и действия над ними, а Петя — ну так, со скрипом. И потому что Вася умеет упорно добираться до недр изучаемого предмета, а Петя — ну как уж получилось.
Так что даже нельзя сказать, что статистически Петя подобен Васе, только без необходимых знаний. Без знания алгоритмов — Петя слабый, просто негодный архитектор. Вот потому-то архитектура, построенная вообще без представления алгоритмической сложности работы с ней — явление куда более распространенное, чем хотелось бы.
статистически и в любой другой области, в которой он профессионально позиционируется, очевидно, будет разбираться не хуже Пети.
Ни откуда это не следует, это вы придумали двух каких-то персонажей. Я тоже могу придумать Григория, который как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметь, и Константина, который работал на работе и изучал алгоритмы «в полях», и вообще молодец.
Из этих двух персонажей, Григорий очевидно слаб, глуп и достоин порицания.
Ни откуда это не следует, это вы придумали двух каких-то персонажей.Вы же точно тред сверху прочли?
Я тоже могу придумать Григория, который как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметьМожете придумать, ну пусть будет, почему бы нет. И, внезапно, раз Григорий ничего не умеет, то у него и не получится позиционировать себя в какой-то востребованной области. Тем более так, чтобы это было не замечено в начале первой же беседы. Еще раз подчеркну: если ваш Григорий ничего не умеет, то и проблемы его отсечения не существует. А если умеет как надо, то это не ваш Григорий, который
как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметь
Их желание и способности к погрызу гранита будет с неизбежностью статистически выводить Васю и Константина-молодца к познанию, Петю к накапливающимся фейлам, а Григория к невидимости.
Но ладно, это уже лирика, так можно бесконечно переписываться о том, что для кого очевидно и что не очевидно.
Факт в том, что в «оперативной памяти» хранятся наиболее часто используемые знания и навыки. Чем реже и меньше человек что-то использует, тем с большей вероятностью он это забудет (или положит в «холодное хранилище в долгим временем доступа», если продолжить говорить метафорами).
Если происходит сортировка людей по одному признаку, то первые места занимают те, у кого этот признак «на кончиках пальцев». Если критерий — алгоритмы, то победят те, кто знают алгоритмы лучше других. А кто может знать алгоритмы лучше других? Правильно, тот, кто совсем недавно закончил их изучать. Если человек хотя бы лет так 5 поработал программистом, то, скорее всего, реально изучал алгоритмы он как раз лет так 5 назад. Сейчас ему интересно другое — архитектура, паттерны проектирования, и прочие высокоуровневые штуки. К примеру, вместо того, чтобы сравнивать скорость разных алгоритмов сортировки списков, он сравнивает разные способы организации и получения данных в какой-нибудь базе, типа постгреса.
Вот и получается, что, задавая вопросы в стиле «реализуйте сортировку пузырьком» или «повращайте мне дерево», больше всего баллов наберут студенты, олимпиадники, разработчики чего-то низкоуровневого, типа компиляторов, и всякие кванты, занятые высокочастотной торговлей, когда каждая миллисекунда промедления означает убытки. А, ну и те, кто страстно желают попасть именно в эту компанию, и последние полгода прорешивали литкод. Обычные инженеры, которые первые минут 10 (особенно, если запретить пользоваться справочниками) будут только вспоминать, как именно работает под капотом алгоритм с тем или иным названием, будут в пролёте. А учитывая, что вряд ли много квантов хотят работать в яндексе, то будут они нанимать в основном новичков.
Вот алгоритмист так же, считает что у него крутой «мыслительный аппарат», а на деле он дальше алгоритмов ничего не видит.Дальше алгоритмов он видит не хуже остальных. А так как сразу на автомате прикидывает сложность работы, то лучше остальных. В сложных случаях — намного лучше. Да что там в сложных — вон по тому, как ворочается эта страничка (вы же заметили?), видно, что хабр далеко не алгоритмисты писали.
Факт в том, что в «оперативной памяти» хранятся наиболее часто используемые знания и навыкиЭто не факт, это ваше допущение, особенно в части навыков. На самом деле строго наоборот: чем более мыслительный аппарат разносторонен и тренирован (ага), тем легче и успешней даются прочие действия в смежных областях.
Чем реже и меньше человек что-то использует, тем с большей вероятностью он это забудетВот только нет ни одной причины, по которой умеющие в алгоритмическое мышление вдруг в повседневной работе что-то использовали реже остальных. Вы тоже фантазируете про шарообразных алгоритмистов в вакууме, а они точно так же работают над обычными задачами, используя те же технологии, что и неспособные в алгоритмику. Только с лучшим результатом в силу более развитых способностей видеть сложность целого.
А кто может знать алгоритмы лучше других? Правильно, тот, кто совсем недавно закончил их изучать.Алгоритмы нужно не «знать и помнить наизусть», а помнить в целом, какие они есть, а главное — моментально оценивать сложность разных подходов, когда приходит время выбора. Да, архитектуры это тоже касается, если вообще не в первую очередь.
К примеру, вместо того, чтобы сравнивать скорость разных алгоритмов сортировки списков, он сравнивает разные способы организации и получения данных в какой-нибудь базе, типа постгреса.Ох… Вы знаете, я вообще-то sql'щик, и мне особенно больно видеть, какие способы организации и получения данных в какой-нибудь базе изобретают неумеющие в базовую алгоритмику/сложность. И чаще всего быстро и прозрачно пофиксить это невозможно, это фиксится через кровь и развороченные кишки. Ну просто написано вообще без мысли «а как это потом будет работать». Даже не «и так сойдет (с)», а просто люди не видят последствий, не привыкли автоматом просчитывать пути и алгоритмы наперед. Пока данных немного, оно без проблем работает. А когда/если проект вырастает, начинаются веселые старты с поминанием незлым тихим словом непонимающих, что алгоритмы и сложности — они на самом деле везде, просто они не обучены сразу видеть это на каждом шагу.
ЗЫЖ кому вы написали последний абзац, я не знаю. Про описанный процесс найма я не слова не писал, это выбор яндекса, а их проблемы и профиты от этого процесса мне неинтересны.
Решить может и может, но заточеность на решение сложных алгоритмических задач часто мешает ему сделать простое и поддерживаемое решение, в итоге буде плохокод
Если человек владеет инструментами, но алгоритмы сочинять не умеет, то он застрянет на вполне себе практических задачах вида «отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты»
Ну, слушайте, для такого не надо быть алгоритменом, достаточно просто немного иметь голову на плечах, а в ней — мозгов.
«алгоритм-мен» всегда может решить практическую задачу.
Да если бы. Уж сколько я в промышленной разработке повидал умудренных опытом профессоров, которые могут потратить год на то чтобы оптимизировать до ниточки алгоритм какого-нибудь специфического обхода фрезой внутреннего радиуса малого диаметра, но не способных, под угрозой штрафа, смерти и увольнения, за месяцы и месяцы, не способных этот алгоритм написать и встроить в общую инфраструктуру так, чтобы оно запускалось хотя бы, не говорю уж об исполнялось.
У некоторых из таких теоретических профессоров задачки с литкода вообще никаких проблем не вызывают, вот прям совсем. У них нерешимая задача это склонить репу с гита, или данные из модуля передать чем-то кроме global static void*.
Ну вот поэтому на интервью просят решать задачики, а не проводят теоретический экзамен. Чтобы отсеять в том числе таких профессоров.
Что?
Сначала вы пишите, что есть профессора, которые могут натеоретизировать заумного computer science, но не могут писать код. Я вам говорю, ну вот же, на интервью просят писать код. Не заумный — задачки простые! И тут вы каким-то непостижимым мне образом делаете вывод, что если заставлять людей писать код решающий эти простые задачки, то его пройдут исключительно профессора "не могущие написать код"? Раскройте свою логику по шагам — она мне вообще не понятна.
Человек умеющий решать code puzzles совсем не обязательно умеет производить продукт работая программистом на работе. Потому что в реальности задачи стоят не в виде условий от экзаменатора, а в виде ситуации в реальном мире, превратить которую в задачу решаемую инкапсулированным куском кода — тот еще нетривиальный навык.
И два эти навыка — писать программы и уметь решать code puzzles — друг в друга не транслируются. Сопудствуют, но не транслируются.
Отсюда люди, умеющие решать пазлы, но не умеющие решать практических задач, зачастую даже не могущие понять как подходить к решению практичексих задач.
Задачки в посте и прочие простые задачки на интервью — они и есть задачки.
Эти задачки (или нечто очень похожее на них) постоянно возникают во время работы. Вам так сложно представить, что в Яндексе где-то программисту придется выбрать общие элементы из двух списков?
Отсюда люди, умеющие решать пазлы, но не умеющие решать практических задач, зачастую даже не могущие понять как подходить к решению практических задач.
Не могу себе это представить. Как раз алгоритмическое мышление и умение решать пазлы тренеруют построение математической модели задачи. Это очень помогает решать практические задачи.
Потому что в реальности задачи стоят не в виде условий от экзаменатора, а в виде ситуации в реальном мире
Есть еще отдельная секция про проектирование систем — вот там как раз проверяется умение решать большую, нечеткую задачу. Там не просят писать код (то, что человек код писать умеет видно по алгоритмическим секциям). Но там как раз смотрят, как человек разбивает задачу на подзадачи, как выковыривает из интервьювера недостоющую информацию.
Ее не задают на начальные позиции, потому что люди на этих позициях в основном "копают от сюда и до обеда". Им ставят вполне фиксированные задачи.
Я ищу программиста которы умеет на Java и выбивает 7+ из 10 (0-нуб, 10-бог, условно). Задаю вопрос по почте «пожалуйста прочитайте 17.4 спецификации языка, и подумайте, зачем оно». Ни один из кандидатов (многие с 20+ годами опыта) нормально не ответил, либо не могут прочитать, либо не могут нагуглить разжеванный вариант, либо начинают хамить прямо сразу и говорить, что это не надо. Так что да, профессия загибается.
Я его по-английски задаю, и всем немного по-разному, чтобы рекрутер не понял паттерн, но все с “can you please, if you have time, ...”, плюс — это тоже тест, насколько легко вас втянуть в конфликт.
А зачем, собственно, вы втягиваете программистов в конфликт?
Я спрашивал (в смысле что делать если у вас с коллегой разные предпочтения). На собеседовании все либо говорят, что они взрослые люди, что можно договориться, что надо форматирование автоматическое делать в pre-commit делать, либо (когда совсем без опыта и не понимают что будет с историей в гите) — что это пофиг и пусть каждый как хочет так и кодит. А после найма — большинство тихонько делают по-своему и меняют форматирование в каждом коммите, пока "начальник" не скажет как надо.
Я понимаю всё это. Я просто не могу придумать как делать лучше. Когда кандидат мне пишет “я 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 у нас малореально…
Версия самой ОС 7.4 вышла в прошлом году. TR-ы (обновления внутри версии) выходят регулярно (мы сейчас в процессе перехода с 7.3TR9 на проде на 7.4TR3 которые уже раскатаны на тестовых средах)
Да, у нас она не популярна (я знаю три банка, которые на ней работают — Альфа, Райф и Рос, ну может еще где-то есть). Но в мире она достаточно распостранена — банки, страховые компании, госструктуры.
Просто на фоне всеобщего засилия мобильной и вебразработки это выглядит нишево, но ниша эта стабильна.
В целом, это свой рынок, вполне устойчивый. Аналогично можно сказать и про многие другие аспекты разработки — та же промавтоматизация, встроенные системы. Уступает по объему вебразработке, но средняя квалификация работающих там людей достатчоно высока.
Видимо да, наименее затратный подход для обоих сторон. Или вообще только через знакомых искать (но это будет не совсем честно).
А потому что нафиг это никому не нужно в реальных задачах.
Это ровно противоположное разговору двух специалистов, это никак не про то, может ли человек работу работать, это очередная итерация агрессивного экзамена, где цель экзаменатора найти чего экзаменуемый не знает, и радостно поставить ему неуд. А если найти не удается сразу, начать трюки разные, лишь бы где-нибудь ошибся.
А ссылку даете?
Кстати, один из кандидатов был русский чел из гугла. Элегантно отвертелся от низкоуровневых деталей 17.4, затроллил offline coding task на игре слов, сделав совсем не то, что просили но настолько круто, что всем очень понравилось — совершенно другая лига, футболист с мячом, а не бурлак на Волге, условно говоря. Ощущение, что просто приходил убедиться, что в гуле ОК, несмотря на иногда скучную работу.
«17.4. Спецификации — ДНК, код — РНК
Даже в давние времена PDP-7 Unix-программисты всегда (больше чем их коллеги, работающие с другими системами) были склонны рассматривать старый код как непригодный к повторному использованию. Это, несомненно, было продуктом Unix-традиции, которая акцентировала внимание на модульности, облегчающей выбраковку и замену небольших блоков систем без потери целого. Unix-программисты уяснили из опыта, что попытки сохранения плохого кода или плохого дизайна часто являются более трудоемкими, чем создание проекта заново. Там, где в других культурах программирования инстинкт подсказывал бы исправлять неповоротливые монолиты, потому что в них вложено много труда, инстинкт Unix-программиста обычно ведет к выбрасыванию старого кода и созданию нового.
Традиция IETF усилила этот инстинкт, научив нас считать код вторичным по отношению к стандартам. Стандарты являются тем, что позволяет программам взаимодействовать; они связывают технологии в единое целое. Опыт IETF показывает, что тщательная разработка стандартов, стремящаяся к сбору лучшего из существующей практики, является той формой сдержанности, которая достигает гораздо большего, чем претенциозные попытки переделать мир по образу нереализуемого идеала. ...»
Не понимаю где они берут специалистов с таким подходом?
Второй путь через рекомендации тех кто уже работает в Яндексе, в этом случае вас не будут мучить этой ерундой.
Вы уверены? Я слышал ровно наоборот от коллег, которые пробовали кого-то рекомендовать.
Наоборот это как? Тех кто пришел по рекомендации спрашивают в 2 раза больше дурацких задачек?
Надо понимать что Яндекс большая компания и все процедуры включая собеседования могут сильно отличаться от отдела к отделу.
Наоборот, это что они (порекомендованные) сначала долго ждут, когда с ними свяжутся, и не всегда даже дожидаются, а потом их отправляют на тот же стандартный набор секций.
Собственно, это даже логично, учитывая, что рекомендовавшему за нанятого по рекомендации дают приличный бонус.
А то, что стараются нанимать по рекомендации, вовсе не противоречит необходимости решать при этом задачки.
Но к сожалению почему то политика не становится более адекватной.
П.С. на входе два прохода по 7 интервью (из них 7-8 задачки), провел в офисе Я 2 дня)))
4 из 6 тех собеседований — программирование, причем варианты — правильно сделать вот так (например не хранить состояния мелких процессов/докеров локально) — отметались как неподходящие, «правильно» писать в темп файл локально.
сетевое номер один — все норм, кроме того что я не отгадал «правильную» причину возможной потери пакетов (я назвал штук 20 по уменьшению вероятности, эта проблема была где то в моем списке месте на 50, я ее в итоге после выпытывания назвал, но «уже было поздно»)
единственное норм впечатление (как относящееся к вакансии) оставило архитектурное интервью
вот так я и не стал частью ФБ
там их штук 6 — 8 было
все удаленные
прогерские — часть норм (пытаются понять что ты знаешь, как думаешь)
часть — нам нужен ответ который у меня в голове, угадывай,
то что их больше профельных слегка удивило
профильные — архитектурный — прикольно и интересно
чистая сетевка — угадай ответ (на простых, стандартных вопросах не проблема, в сложной проблематике — как указал выше — я привел с десяток потенциальных проблем (из опыта) вызывающих заданную проблему, попытки переключить интервьюрера из режима «угадай мой ответ» в режим «давай вместе проведем траблшут / сужение и найдем варианты» не удалась — от этого интревью осталось самое плохое впечатление
скорее всего — просто не повезло
общее впечатление от всей серии положительное, но локальные перегибы позабавили
HR один из немногих случаев когда они вполне разбирались в базовой тематике и нормально знали требования / альтернативы (например CCIE им достаточно как подтверждение сетевого опыта)
Это у них, видимо, так, потому что наемом занимаются люди, которые никакого отношения к тому проекту не имеют. Поэтому у них подход чисто формальный: озадачить кандидата задачкой и поставить оценку, которая зависит от того, насколько его решение соответсвует тому, что они ожидают. Им так проще.
А вот насколько способность быстро решать логические/алгоритмические задачи на интервью кореллирует с практикой разработки программного обеспечения, это еще вопрос. По мне так не сильно.
Очень хотелось бы прочитать историю человека, который прошел все этапы в Яндекс (или другую крупную компанию), о том, чем он занимается ежедневно. Доступным языком.
Расскажу схожую историю про одного моего знакомого))) Он смог попасть в госкомпанию (назовем это так) на три буквы первая Ф. Отбирался год примерно, куча этапов, сложнее только у космонавта отбор… Потом ходил гордый, на вопросы чем занимаешься не отвечал — тайна. В итоге через общих знакомых узнал, что он 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 раза короче по коду и сильно проще для чтения — даже мысль не придет
А потом смазать это построчным вызовом запроса в бд и вообще ляпота. Без шуток, видел много раз такое в «крайне оптимизированном» коде.
. А то, что тут можно динамическим программированием вместо 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).
Быстрое решение ещё и короче (в строках кода).
Но по записи быстрого решения понятно что мы делаем на уровне бизнес логики — только в случае, если человек уже разобрался с этой задачей (встречал её в олимпиадном \ литкодном прошлом или на каком курсе).
В итоге быстрое решение хоть и короче — но скорее хуже с т.з. понимаемости.
Вот прям хотелось бы пример!
Я эту задачу сейчас сам на интервью использую. Поэтому не буду приводить.
Но по записи быстрого решения понятно что мы делаем на уровне бизнес логики — только в случае, если человек уже разобрался с этой задачей
Это лечится одним комментарием вроде "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.
Размен скорости на память и наоборот делаем регулярно, страшных алгоритмов типа trie на практике не реализовывал и не использовал, но знаю где в соседней команде заиспользовали и зачем.
4 часа.
Реальная работа это, извините, сommitment и от вас и от компании на как минимум много месяцев или даже уже лет, плюс с большим количеством денег на кону.
Жаловаться что вас крутят 4 часа по алгоритмам это показать свое непонимание процессов найма, их практичности, неумение оценки реальности внедрения более «правильных» с вашей точки зрения процессов найма, неуважение к людям выстраивающим этот процесс за счет отметания с ходу вероятности того что возможно это именно вы что-то неправильно понимаете.
Даже если бы вы решили идеально все представленные задачи, изложенное вами отношение и мысли в этом посту с таким подходом вида «Все говно, а я Д`Артаньян» не помогают уже вам заслужить уважения в ответ. Лично я бы вас не принял никуда ни на какую роль после такой демонстрации, рад за вас что вам на текущем месте хорошо.
Да, 4 часа это много когда вы и не собирались устраиваться на работу, а пришли поразвлекаться.
Реальная работа это ...
Найм на работу — это ещё не работа. Во-первых — время не оплачивается. "Во-вторых" после этого уже не требуется.
Надо хоть немного совести иметь и понимать это, а не жаловаться что все про все заняло на 1-2 часа больше времени и бугуртить до уровня написания поста на хабр.
Еще надо понимать что собеседования по удаленке куда сложнее для интервьюера чем лично, поэтому очевидно что их надо больше чтобы лучше понять что за человек пришел. Очевидно это временно. Очевидно что винить компанию за это крайне несправедливо.
Если кто не в курсе, то до ковида яндекс и так при приглашении на личные интервью покупал вам и билеты на самолет и гостиницу оплачивал. Требовать чтобы еще больше они вам что-то компенсировали это вообще тотальная наглость. Что они вам еще должны, оплатить пару дней на уровне реальной зарплаты? Рожа, извините, не треснет? При ковиде теперь то конечно не лично получается, но и время вы экономите не собеседуясь лично.
На каждого программиста, который считает что ему все обязаны, найдется не менее десятка сравнимого уровня тех, кто понимает что ему эта конкретная вакансия нужна больше, чем он нужен компании. И кто готов «потратить» десятки, а то и сотни часов на весь процесс прохождения на желаемую вакансию в желаемую компанию. И я лично рад что такие как ОП, а также неготовые потратить несколько часов бесплатно, отсеиваются в описанном процессе найма. Классическая фича, а не баг.
на найм дефицитных и востребованных кадров
Такие то вы дефицитные, что даже у яндеса найдется десяток людей на ту же вакансию с соразмеримым уровнем, но куда меньшим чсв, чем у вас, не говоря уже о гуглах и им подобных. Продолжайте кукарекать о своей незаменимости.
Давайте их пожалеем?
Эх, сейчас бы помечтать о том как мой будущий работодатель будет тратить уйму денег ради оплаты чсв кандидатов, которые приходят на интервью почесать оное чсв, а не на повышение зарплаты работникам, которым я, как настоящий кандидат, вроде как собираюсь стать.
Впрочем, если не собираюсь и не имею достаточно эмпатии чтобы поставить себя на место такого кандидата, то да, я могу вредных советов насоветовать, попризывать не жалеть бедненькие компании.
Соответственно, не понятно в чём тут экономия времени для кандидата, если его будут больше собеседовать.
Уровень понимания и осознания написанного на абсолютном дне. До ковида — телефонное интервью плюс переговоры с рекрутером + Полеты туда-сюда до Москвы/Питера/etс. отнимающие больше суток. После ковида — чуть больше онлайн интервью чем их было бы на месте. Экономия очевидно на сутках потраченных на полеты туда-обратно, плюс-минус пара часов здесь вообще ни что не влияет.
Ну, в том то и дело, что то было до ковида. Если компания оплатит перелёт и проживание, то можно и 8 часов лично собеседоваться, тут нормально всё.
При этом вы все равно потратили больше суток своего времени и не получили на выходе никаких денег в кармане, только оффер или нет.
Без полетов вы потратили условные 4 часа, и на выходе получили оффер или нет.
В первом случае вам типа норм, а во втором вам типа недоплатили. Задумайтесь, не унюхиваете маразм и отсутствие логики?
они ничего не тратят кроме денег на зарплату интервьюеру.
А это как бы мало? 4 условных интервьера плюс-минус, каждый тратит какое-то время на подготовку интервью с вами, само интервью, потом пишет отзыв, каждый тратит на вас в среднем допустим часа 3. Потом рекрутер сколько своего времени тратит, я не знаю, но пусть допустим еще 3.
А сколько еще затрачено на отвлечение программиста от непосредственной работы в плане уменьшения его производительности за счет отвлечения на интервью с вами? Можно еще по часу накинуть. А время изначальной подготовки каждого программиста к интервьюированию? Пару десятков часов, которое потом будет окупаться и размазываться по всем интервью. Думаю далеко не каждый программист за все время работы в яндексе проведет хотя бы 20 интервью чтобы подготовка размазалась хотя бы до часа. Но пусть будет 20 в среднем, еще час можно накинуть.
Итого получается 4 интервьюера * 5 часов зарплаты на каждого, плюс время рекрутера. На этом фоне оплата билетов и гостиницы даже не удвоит эти траты для компании. А вот вы при полетах в несколько раз увеличите затраты своего времени.
пришли поразвлекаться
А ничего что "они первые начали"? Не автор к ним просился, а они его всяко зазывали. Значит — в данном случае им нужнее! Поэтому:
- И чего бы не поразвлечься?
- Почему бы потраченное на вас время не оплатить?
Помню каким то образом в компанию прошел человек «сеньор помидор» который спросил «Парни, а что такое классы? не понимаю как они работают»
Я за то, чтобы кодинга онлайн было меньше, но он необходим :-) хотя бы физбаз
На сколько я понимаю на западе даже большие компании начали отказываться от такого подхода. Например в Амазоне уже давно не только алгоритмы и задачки а сильно лучше
В гугле, во всяком случае, было так.
По вопросу почему так в Яндексе, ну да, знание базовых вещей сильно помогает потом разобраться в местных велосипедах. А что еще спрашивать? Про высоконагруженные сервисы тоже будет секция, если код пройдешь.
Но почему на кодирование 4 собеседования?! Они были не уверены после первого? Вроде бы и кодит, но что-то тут не то, давайте ещё 3 раза повторим.
Дешевле не нанять хорошего разработчика, чем нанять плохого.
ЕМНИП, чтобы уменьшить влияние мнения одного человека. Ок, один не получил то что хотел, но трое других были в восторге.
Обычно в таком случае все четверо приходят вместе. И спрашивают из широкого спектра, а не одни и те же задачки.
Я после 11 класса, помнится, и олимпиадные задачки решал, и сортировки все помнил… Но могли бы меня с теми знаниями взять сейчас на сеньора? Да упаси Нортон!
Сейчас уже все эти сортировки забыл за 20 лет, но знаю где лучше применить RabbitMQ а где Kafka, на каком сервере расположить сервисы и как их связать. А сложность сортировки я нагуглю быстро, если надо.
RabbitMQ
С удовольствием бы почитал, а то, как человек, от которого развве что ноги торчат из бд, никак не возьму в толк зачем выводить за пределы транзакции критичные вещи (а все этим радостно занимаются)
Во! Норм вопросы на позицию сеньёра-бекендера,
Я могу ошибаться, но вроде бы нельзя шарить задачи, которые были на интервью?
В гугле, во всяком случае, было так.
Ну если автору плевать — почему нет?
Я могу ошибаться, но вроде бы нельзя шарить задачи, которые были на интервью?
Под NDA нельзя поставить что-то без полноценного заведения оной NDA, с подписями, контролем доступа и всем таким, причём строго через "И".
Поэтому всякие подписи в письмах от рекрутеров "вот это письмо, которое пришло к вам без всяких подписанных бумаг, шарить нельзя" — фикция. Во всяком случае в России.
Устно договориться "давайте Вы не будете делиться?" — это только на уровне устной договорённости. То есть можно, но не обязательно.
но вроде бы нельзя шарить задачи, которые были на интервью?
С каких это пор нельзя? часто ребята идут «по трупам друзей». Первый идёт, кому не сильно надо — разведка боем, просто собирает максимум инфы все вопросы что запомнит / запишет. Потом идёт более подготовленный товарищ, с уже заготовленными ответами на вопросы которые спрашивают на эту позицию. Последним идёт тот, кому нужно больше всего, и которому коллеги добыли максимум инфы. Ко мне всегда отделами ходят на собеседования из глобалов/интеллиасов/люксофтов. Правда такая подготовка для меня — очевидна.
А вы сделайте им такое собеседование, к которому нельзя заранее подготовиться :)
1. Дан PNG с изображением мяча. При загрузке страницы мяч должен появиться в центре окна браузера и начать двигаться в случайном направлении с заданной скоростью, отражаясь от границ окна.
2. Разработать архитектуру Веб-чата, для простоты — с одной комнатой для всех. Обосновать принятые решения и предложенные фреймворки/библиотеки.
2. А вот это неплохо. Вполне себе типичный вопрос на архитектуру.
Только зря вы про фреймворки и билиотеки. Какие у вас приняты те и берем. Какая разница в конце концов?
Если ничего подходящего у вас нет, то окей Гугл самое массовое и типовое. Опять же какая разница что брать?
2. Это не холивара ради — а проверить, насколько человек «в теме» (а WebSockets почти у всех в CV). Если он/а может обьяснить и нарисовать, как это все должно работать (или работало в их предыдущих проектах) — то ничего искать и не нужно. Кстати, по поводу Гугла — мы дали предложение человеку, который честно сказал что с таким раньше не сталкивался, но за то время что мы ему дали — нагуглил что-то похожее, разобрался и вот что получилось.
2. Про фреймворки и библиотеки — тут как раз нетривиально, как архитектор говорю. Вопрос «как будете строить решения и что из библиотек/фреймворков» используете как раз позволяет оценить, как человек принимает архитектурные решения. «Гугл самое массовое и типовое» — это лишь один из стилей, он, кстати, кое-что говорит о кандидате :)
Вопросы вызывает только часть про фреймворки. Я допустим чаты не делал. При этом распределенные системы делаю и знаю. Бекенд, но не суть.
Я назову Спринг как отраслевой стандарт и окей Гугл что угодно для вебсокетов. Вроде же на них модно сейчас такое делать? Если что-то подходящее есть в Спринге это и берем, нет смотрим от Апаче итд. Что там будет мне глубоко все равно. Проблема точно решенная в разных библиотеках и в большей части библиотек она точно решена хорошо.
А дальше уйду в дебри кеширования и распреденных БД. Чтобы работать отказоустойчиво и вызывать максимум авто реконнект пользователей при выпадении чего угодно. И не падать когда набегут тысячи пользователей в комнату и начнут постить гифки с котиками.
Это все от фреймворков и конкретных технологий не зависит примерно никак. Хотите Редис, хотите Тарантул, хотите Постгрес, хотите Mysql. Хотите кубер, хотите пакетами можно катать все на любое число серверов. Все работает примерно одинаково. Можно сделать на любых стандартных технологиях.
У меня, например, первые вопросы:
1. Это встраиваемое в портал решение, или автономное? Или встраиваемое, но должно быть отдельным сервисом? От этого сильно зависит, как делать авторизацию — прокидывать ли ключи от главного сервиса, или как-то еще.
2. Ну, предположим, делаем модельное решение — доступ по ключу входа, без всяких проверок. Вопрос — на какой объем пользователей? Если у нас миниатюрный сервис до 50-100 участников и мы тестируем гипотезу, я бы почти вообще без библиотек сделал (ну, кроме сокетов, конечно, и, может, хранения сообщений, если есть что толковое под рукой). Зато выкатил бы через несколько дней. Или же у нас есть платная/бесплатная часть? Тогда как выделяем инстансы?.. В общем, тоже, уходим в дебри кеширования и распределенных сервисов (мне, кстати, ближе простенький монолит, но я и высоконагруженными системами не занимаюсь)
Ну, как-то так.
Про фреймворки — это, условно, вопрос «что вы вообще возьмете и зачем». Будете ли фреймворком закрывать архитектурные решения, или возьмете библиотеки и сами их склеите. Что сделаете сами, что делегируете библиотеке (я вот сокеты точно делегирую).
Пользователь приходит с кукой. Мы эту куку передаем внешнему сервису, он возвращает все что нам положено знать про этого пользователя.
Работает само и независимо. Это как то место где изоляции мало не бывает.
Кеширование в этом месте или запрещенно вообще или минимальное.
Распределенный монолит это хорошо и правильно. Его размер не выглядит слишком уж большим. Распределение делать все равно надо. Нагрузку на балансерах надо как-то распределять по бекендам, да и ребутать без даунтайма хочется иметь возможность. Как именно их синхронизировать и кешировать дело вкуса.
Мне нравятся зукипер, редис и любая sql бд. Если нужно сделать на etcd, Тарантуле и Монге могу и на них сделать. Ну потрачу я недели две чтобы разобраться с новыми технологиями. Мелочь по сути.
Делать один инстанс чего угодно без возможности подключить второй — это самая большая ошибка которую только можно совершить при проектировании. Исправлять очень дорого и сложно. Как правило проще выкинуть и написать заново чем исправить такое.
Если планируется настолько маленькая штука что даже два инстанса с синхронизацией делать кажется дорого, то стоит вообще не делать а походить по рынку поискать готовое решение.
Фреймворки - это "мета-вопрос", проясняющий несколько аспектов сразу:
- Случилось ли кандидату действительно работать с тем, что у него/нее в CV написано - или это копипаста откуда-то
- Понимает ли он/она преимущества и проблемы использования библиотек/фреймворков
- Понимает ли он/она "внутреннюю кухню" фреймворка и его API (я люблю .NET-чиков спрашивать, как Task выполняется - почти никто не знает)
- Как кандидат обьясняет свой выбор и реагирует на вопросы
Разумеется, я никогда в жизни не сталкивался и с половиной предлагаемого (например Spring или React) - но если человек действительно на этом писал или хотя бы знает принципы, это сразу видно.
Смотря что понимать под «нельзя».
Неэтично — да, конечно. А в принципе то как запретишь? Даже если в Яндексе установлен режим коммерческой тайны и они как-то умудрились притянуть к нему эти задачки, кандидат — не сотрудник, как ему доступ к коммерческой тайне оформлять?
Шарить задачки, которых нет в интернете — подло с точки зрения компании, но яндекс в этот круг компаний не входит, тк взял все задачки с литкода и ничего нового не придумал.
Ну стиль у меня такой ¯_(ツ)_/¯ Да, всё субъективно — рассказал, как это выглядело с моей стороны и что я чувствовал.
Какой смысл в сухом изложении, если большинство пойдет и получит такой же эмоциональный фон в подобной ситуации — это же не вопиющий случай, а политика компании. Наверно будь это не яндекс, было бы куча оговорок — "я не знаю как у других", "может зависит от того кто собеседует" и тд. и тогда сухое изложение может быть было бы уместно, а бурю эмоций можно было бы скрыть под спойлер
Меня на моей предыдущей работе тоже на собеседовании жестко гоняли по алгоритмам и большому О. Когда приступил к работе, выяснилось, что из алгоритмов в ПО используются только геттеры и сеттеры)
Да, и стандартная библиотека олимпиадникам не нравится, они ее сразу переписывают сами :)
на самом деле алгоритмы в реальной работе нужны не очень часто
"На самом деле огнетушитель в машине нужен не очень часто". Зачем их вообще требовать и проверять на техосмотрах?
Дело в том, что олимпиадники, в подавляющем большинстве случаев, смогут использовать готовые библиотеки, перекладывать данные отсюда туда и всякую другую рутину. Плохой стиль кода у олимпиадников лечится всего за пару недель, если в компании есть код-ревью. А вот не умеющий в алгоритмы программист даже не заметит, что вот тут эта самая алгоритмическая задача возникла. И впендюрит n^2 вместо n log n. Потом внезапно прод станет тормозить, когда нагрузка возрастет всего-то в 10 раз. И придется экстренно искать это место и переписывать.
Да-да, олимпиадник. Он как раз вместо того чтобы взять готовое решение будет сам месяц писать велосипед. Потому что его натаскивали именно на задачи "война, stdlib убит, напиши свое".
У нас в гугле такого не вижу. Да, есть всякие внутренние фреймворки и библиотеки, которые имеют распространенные аналоги, но практически все они в компании сделаны раньше, чем эти распространенные появились. Есть собственная замена почти всему из stdlib в репозитории, поддерживаемая специальными командами (и работает сильно быстрее почти всегда). Никто из моей команды каких-то велосипедов не пишет.
Мой коммент:
У нас в гугле...
Вы приводите ссылку на статью о том, что технологии применяемые в гугле не стоит бездумно перенимать, ибо они заточены под реально большие объемы, которых в большинстве других компаний почти точно нет. Что вы хотели этим сказать?
Если вы про контекст этого поста — то он о яндексе. Как конкурент гугла, хоть и на локальном рынке, Яндекс как раз одна из тех немногих компаний, где гугловые технологии тоже нужны. Опять же, я не понимаю, при чем тут ваш коммент.
Ну вообще, интернет большой. Искать по всему интернету — даже с учетом фокуса на рунете у яндекса — охренительный объем данных. Не знаю, сколько у них датацентров, но предполагаю, что далеко не один. Так что яндексу 100% нужны самопальные решения. Потому что если можно соптимизировать std::string на 1% — это огромная в абсолютных цифрах экономия, хоть и ничтожная в относительных.
ха-ха-ха
При этом я не раз видел как довольно быстро «готовое решение» «олимпиадникам» удавалось ускорить раза так в 3 а там где performance matters это довольно полезный скилл.
«олимпиадникам» удавалось ускорить раза так в 3 а там где performance matters это довольно полезный скилл.
Я правильно понимаю, что ускорить в 3 раза можно только тот алгоритм который изначально имеет сложность О(1) и О(N)?
Нет. Не обязательно. Взяли вместо O(N^2) сделали O(N log N). Там уже от навороченности алгоритма (константы) и конкретного значения N может получиться что угодно — хоть в 3, хоть в 100 раз быстрее.
В моей практике, n-кратное ускорение обычно может быть достигнуто знанием архитектуры, но не алгоритма.
Обычно 2 порядка производительности лежат там где убираются списки, убираются денормализованные числа, заменяются деревья на хэш таблицы или данные перепаковываются что бы уложиться в кэш процессора, или распараллеливается, или чтото типа фильтр блума применяется, или замещаются сики на отображаемые в память файлы. Один порядок производетльности лежит в оптимизациях предсказания ветвлений. Процентов 20 лежат в неоптимальном TLB. Еще префетчер есть. Часто бывает что сложность алгоритма компенсируется латентностью памяти и переключением банков, инвалидации кэша, межпроцессорной инвалидацией данных. Часто где критична производительность и алгоритмов хитрых и не встретишь, просто терабайтные таблицы предвычисленных значений или другие ухищрения.
Дело в том, что олимпиадники, в подавляющем большинстве случаев, смогут использовать готовые библиотеки, перекладывать данные отсюда туда и всякую другую рутину.
И конечно же это чистое совпадение, что именно компании-средоточия-олимпиадников являются же главными центрами по производству софтверных решений, которые устраняют исключительно фатальные недостатки в самых разнообразных существующих технологиях.
Ну и уже на личном опыте: смогут использовать готовые библиотеки? Да, безусловно смогут. Будут ли использовать готовые библиотеки там, где их можно прекрасно было использовать? Скорее нет, если только не придёт признанный авторитет и не скажет таки использовать.
И конечно же это чистое совпадение, что именно компании-средоточия-олимпиадников являются же главными центрами по производству софтверных решений, которые устраняют исключительно фатальные недостатки в самых разнообразных существующих технологиях.
И еще одно забавное совпадение: большое количество этих "велосипедов" без фатального недостатка появилось раньше этих разнообразных существующих технологий.
Олимпиадниками нужно руководить, без руководства они естественно могут начать делать совсем не то что надо. Но любыми программистами надо руководить чтобы они не делали совсем не то что надо. И олимпиадниками руководить зачастую проще. Они, в числе прочего, умеют выбирать из готовых решений там где другие не видят особой разницы.
Они, в числе прочего, умеют выбирать из готовых решений там где другие не видят особой разницы.
Не наблюдал никакой корреляции. Умеют выбирать — те, кто умеют выбирать (как правило это те люди, которые уже обжигались на плохих выборах, или те, кто были свидетелями таких случаев). Олимпиадники к этому относятся ортогонально.
И конечно же это чистое совпадение что именно компании-средоточия-олимпиадников являются лидерами рынка и «разнообразные существующие технологии» создаются зачастую именно ими.
И стали лидерами они до перехода на "строго олимпиадники" или после?
И пруф на "создано именно олимпиадниками" очень хотелось бы увидеть.
В яндексе всё свое, им нафиг не нужны Ваши знания библиотек, фреймворков и т.п. А еще они большие и хотят сделать наем более объективным. Я видел в других местах ситуации когда лид набирает людией под себя и после его ухода их всех только увольнять, другие с ними работать не хотят.
В общем причины почему так нанимают есть. Но вот платят они мало и потому только студентов олимпиадников и могут нанять..
Вспмонилось как один кандидат спросил "чтО большое?"
к интервью не готовлюсь
Жму руку. Как там… быть, а не казаться.
Но не исходя из моего высочайшего морального облика, а по эгоистичной причине — меньше тревожусь.
Вроде как если я зазубрил все типичные вопросы интервью, то я выдал себя за кого-то другого, и потом грызет синдром самозванца.
А если я просто прошёл собес «чистым» без подготовки, то что уж тут, глаза видели, кого брали:) И мне становится гораздо спокойнее, когда я с какой-то задачей разбираюсь не так быстро, как хотелось бы
Есть теория, что Яндекс понимает кого ищет.
Ищет людей с хорошим знанием алгоритмов и привычкой всюду смотреть на O(?).
Как найдет, дальше всему научит сам.
Мне такой подход не близок, но я не Яндекс.
Про то, что спрашивать про джанго на собеседованиях не нужно, я как раз с Яндексом согласен. Если ты крутой, дадут методичку, выучишь.
А вот то, что не надо искать человека именно с опытом Джанго и спрашивать от него каких-то хитрых подробностей фреймворка, если ему придется работать с Джанго на текущем месте работы — с этим согласен.
А алгоритмы сам Яндекс форсит учить перед собеседованием. Вот как раз по ним и надо давать методичку
Выучить джанго все-таки на порядки проще, чем научится алгоритмическому мышлению и способности решать задачи.
Выучить джанго все-таки на порядки проще, чем научится алгоритмическому мышлению и способности решать задачи.
С этим не поспоришь. Но хватит и пары задач чтобы это выяснить. А вот реальный опыт очень важен.
У меня есть хороший пример — на прошлой работе был коллега, матерый программист, еще TCP-стек для какого-то микроконтроллера реализовывал 30 лет назад, писал на всем что горит… Кинули его и меня на новый проект с Джангой. Дали книжку, которую мы за неделю прочитали и уяснили суть.
Как матерые ООПшники порадовались идее ORM и кинулись в бой. Красиво реализовали все на классах, а потом как пошла нагрузка — поняли что база не совсем любит наш подход и select_related не зря придумали.
В том-то и дело, что Яндексу не нужен опыт. Нужна голова и способность принять условия игры. Несколько раз сказали — выучи, повтори алгоритмы. Если (а) согласишься (б) успешно и быстро подтянешь — то потом, когда тебе скажут разобраться с «Яндекс.Велосипедофреймворк», ты (а) не будешь спорить (б) быстро разберешься.
Система грейдов — чтобы удерживать людей со знанием «Яндекс.Велосипедофреймворк» в компании.
И да, система найма Яндекса устроена так, что сеньоров с рынка они почти не нанимают.
P.S. На всякий случай — я не из Яндекса, инсайдов нет, это мои наблюдения.
но я человек ответственный, поэтому к интервью не готовлюсь. Это кстати я не шуткую, реально: если вы ответственный человек, ты вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах.
ну тут двоякое, большинство все еще любят упарываться в типовые вопросы, знание ответов на которые никак и ни разу тебе не пригодятся в будущей работе и вообще никогда не пригодятся ни на одной из будущих работ
Мне кажется, вы словили джекпот — вам подсунули все самые популярные в Яндексе задачки на собеседованиях (сам, когда работал в Яндексе, очень любил задачку про симметрию задавать).
При этом, вы их все слили в интернет, так что сейчас все будут бегать кругами и придумывать новые.
Я надеюсь, что что-то поменяется. А вообще leetcode большой. На крайний случай могу накидать 10 аналогичных по классу задач и предоставить Яндексу на безвозмездной основе.
вы их все слили в интернет, так что сейчас все будут бегать кругами и придумывать новые
Ящитаю, это очень хорошо. Человечество от этого только выиграет. Если все так и будут
всегда поступать, со временем сформируется "база знаний" автоматизирующая решение подобных задач, высвобождая время для более полезных вещей. Хотя, конечно, есть некоторая вероятность, что потеря такого фильтра навсегда лишит общество некоего жизненно важного градиента, оставив нас в локальном минимуме эффективности. Но это скорее в предельно длительной перспективе, а на наш век всё-таки — одна выгода.
Автор молодец, я хорошо посмеялся, а я просто возьму и оставлю это здесь
https://blog.ploeh.dk/2021/03/22/the-dispassionate-developer/
И вот тут как раз со стороны яндекса это именно то, что они от вас хотят — чтобы кандидат мог стабильно сидеть и кодить что сказали, без фигни. А то если каждый будет выдумывать как ему и что делать, каждый подтянет свои любимые библиотеки в проект — любой проект на дно пойдёт.
Так что может это вам было не интересно, а яндекс-то как раз проверяет всё как надо яндексу.
Например, дать необычную (странную) либу со странной же документацией, дать задание разобраться и сделать, а самим следить за моральным состоянием кандидата и тем как он реагирует на подсказки/напутствия?
По моему многие просто неправильно понимают суть собеседования в яндекс.
Добавьте сюда ещё другой аспект: когда к тебе стоит очередь из желающих пособеседоваться, её надо бы как-то проредить с минимальными затратами для компании, чтобы не тратить время на тех, кто и не собирается становиться сотрудником, но хочет большую честь или там строчку в резюме ну хоть кого-нибудь.
Одного мема «в Яндексе/Гугле/Иксе гоняют по алгоритмам» достаточно, чтобы часть из этой очереди поумерила пыл — и вообще не пришла сразу, а ушла готовиться — не тратя время компании на это.
Всё ещё слишком много времени уходит на собеседования? Добавляем в ротацию домашнее задание и отсеивается ещё часть людей, которые не хотят тратить своё время — и таки образом не будут тратить время компании.
Всё ещё не помогает? Полируем раундом-двумя-тремя онсайт-интервью на четыре часа — часть людей отвалится сразу как только их об это предупредят, а с «выжившими» можно и поговорить.
Ну потому что автор — это питон и это конечно же смишно))
Ну а яндекс вообще ничего не спрашивает про железо, и это тоже смишно)
Ибо не зная как работает конкретная ОС, как она настроена, какие железки стоят т.е. контроллеры и винты и т.д. — почитать и распарсить файлик за минимальное время совсем не получится. И что бы опиративку оно не выжрало как не в себя. И что бы у бгмерского коллектора голова не закружилась. Слушайте, а тогда зачем вам это всё?)
Кому вообще нужен мееееедлееееееенный код? Идиотам? Хз хз… Даже теряюсь в догадках…
Какие то абстрактные кони в вакууме…
п.с.: Нет, я категорически не против алгоритмов и я категорически не против вхлам тормозного питона, однако же я против того, что существует так называемое абстрактное программирование. Нет, это не ооп. Абстрактное программирование — это программирование насмерть оторванное от железа. Однако же если юзать такое вот абстрактное программирование — ничего хорошего не получится, причём по определению. Сие даже не нуждается в доказательствах.
Абстрактное программирование — это программирование насмерть оторванное от железа
А чем вам AWS Lambda не угодил?
Закусывайте.
Для себя сделал такой вывод:
1. Большой поток кандидатов, сложно объективно и индивидуально подходить к каждому.
2. Решая алгоритмические задачи, кандидат показывает свои когнитивные способности. Способность понимать подсказки интервьюера, способность находить и обрабатывать крайние случаи. Отбираются кандидаты с хорошей соображалкой, а уж по скиллам место внутри многотысячной корпорации найдется.
3. Подготовленный кандидат (over 50-100 решенных задач на leetcode, например) также показывает свою мотивацию получить работу в компании.
+ Насколько вменяемо кандидат общается с интервьювером в процессе решения задачи,
+ Как кандидат себя ведёт, если встречает алгоритмическую задачу, которую раньше не видел. Пробует примерить на неё все паттерны подряд, делает решение «в лоб» и оптимизирует, залез под стол и кричит?
+ Как он то, что понаписал, собирается тестировать? Код хоть приблизительно читаем?
+ Нашёл ли кандидат крайние случаи, уточнил ли все места где задача была недостаточно определена, смотрит ли на вычислительную сложность…
Автор, кстати, хорошо показывает откуда берутся статьи «Винда полчаса сортирует значки рабочего стола» и «GTA V зачем-то парсит гигантский json на каждый чих». А что, «сложность алгоритма в реальном программировании нужна целых 0 раз», интерсектом бахнем да и норм :)
Автор, кстати, хорошо показывает откуда берутся статьи «Винда полчаса сортирует значки рабочего стола» и «GTA V зачем-то парсит гигантский json на каждый чих». А что, «сложность алгоритма в реальном программировании нужна целых 0 раз», интерсектом бахнем да и норм :)
Теперь бы еще понять, откуда берутся статьи «Гуглопочта весит 6.7Мб и её практически невозможно* открыть на плохом канале».
Ах да, это же не про сложность алгоритма, какие могут быть претензии.
* — в прошлом, с некоторых пор гугл изволил починить логику отображения ссылки перехода на «легкую» версию гуглопочты, и теперь по крайней мере её можно без проблем нажать
Гуглопочта написана на собственных технологиях гугла.
1) Так что же, их собственные офигенные решения не такие уж офигенные?
2) Куда делись все олимпиадники при написании гуглопочты?
Это, конечно, звучит как "сперва добейся"… Но попробуйте сделать гуглпочту более лучше. Я не встречал ни одного другого почтового клиента с таким набором фич, с поддержкой того же количества трафика.
Я не встречал ни одного другого почтового клиента с таким набором фич, с поддержкой того же количества трафика.
Гуглопочта, до того момента, как она стала гуглопочтой на 6.7Мб — была такой же гуглопочтой, но весьма более скромного размера.
А еще до этого она была гуглопочтой без SPA (это то, что сейчас существует как "облегченная версия"), и там с размерами и скоростью загрузки тоже было всё просто наишоколаднейше.
Так что вот "другие клиенты с фичами и траффиком" — это всё та же гуглопочта, просто не то, что сейчас предлагается по умолчанию, а исторические её варианты.
была такой же гуглопочтой, но весьма более скромного размера.
И там не было ни автодополнения, ни отмены отправленных сообщений, ни чата и кучи других функций.
Да ну нет конечно. Тот же hangouts в почте с незапамятных времен, и в прошлой он тоже был. И в новой он, подозреваю — один из самых скромных по размеру компонентов. И вообще в момент радикального утолщения почты там не было никаких прорывных фич добавлено, по крайней мере относящихся непосредственно к почте.
Фичи уже потом пошли. И самое забавное, что размер гуглопочты они особо не увеличивали.
И там тоже есть автодополнение, чат, оффлайн режим?
Чат в одном клике. Правильное продуктовое решение.
Оффлайн режим есть в мобильном приложении. В вебе нет. Тут вы правы.
Если такая тяжесть gmail обусловлена оффлайн режимом, то стоит сделать галочку для его выключения. 10х ускорение работы стоят того.
Чат — лучше бы его можно было выключить, если им не пользуешься. Hangouts — боль и страдание, с проблемами входа в комнату и подобным. Ух я им наелся, когда с гуглерами работал, у которых кроме него ничего нет.
А offline mode — а он не работает фактически. Да, он позволяет открывать письма в текущем ящике (правда при этом отваливаются пиктограммы над письмом), но к примеру в черновики не попасть.
Зачем оно нужно вообще в таком виде?
Тут же меня спросили, какова сложность алгоритма — ок, норм, это нужно знать, потому что в реальном программировании мне это потребовалось целых 0 раз
Да, это нужно. Тут вам повезло, что словарь в питоне работает быстро. Но если не знать что как работает, то можно, например, написать то же самое со списком. Получить квадратичный алгоритм и получить дикие тормоза, когда нагрузка на прод возрастет.
Ну тут ещё вопрос культуры языка и среды. В C++ (STL) алгоритмическая сложность каждого метода является частью спецификации и прописана в документации. Соответственно, даже если человек вообще не очень в алгоритмах смыслит, ему эти "линейное время" и "логарифмическое время" постоянно глаза мозолят. И хорошо что мозолят, везде бы так.
Как еще делать в большой компании, чтобы избежать влияния личности на результат, и чтобы можно было сравнить нескольких кандидатов между собой?
Если что, мне тоже не нравятся алгоритмические собеседования и тем более, подготовка к ним.
PS Дополнил спустя 5 минут. Еще нужно попутно держать в голове, что нужно избежать проблему кумовства, найма по знакомству, «он хороший человек», по принадлежности в группе (к примеру, он из моего универа, города) и т.п. В маленькой компании эти проблемы не важны, в крупной — я думаю будет не в кайф оказаться в коллективе, где все друг друга знают по еще какому-то признаку и прикрывают друг друга, а сторонний человек становится изгоем.
Как еще делать в большой компании, чтобы избежать влияния личности на результат, и чтобы можно было сравнить нескольких кандидатов между собой?
Автоматизировать? Предложить решить 100 задач на том же литкоде в удобное время?
Нет, лучше назначить в рабочее время звонок на минимум час времени и сопеть в наушники пока кандидат потеет в стрессе. Повторить через день. И потом еще неделю так же.
Где-то видел чей-то комментарий на тему "когда меня спросили есть ли у меня вопросы я сказал что есть — мне хотелось бы тоже знать уровень тех, с кем я буду работать. И тоже предложил им решить при мне задачку". Мне кажется это может немного охладить интервьюеров иногда.
По крайней мере интервьювер видит кандидата. Тупо подсказки соседа и гуглеж уже невозможны. Хитрости со скрытыми наушниками еще работают, но в интервью при живом общении такие странности видны. Если кандидат после каждого вопроса несколько минут тупит, а потом идеально отвечает — это будет отражено в отчете интервьюера.
Предложить решить 100 задач на том же литкоде в удобное время?
Та же проблема что и с предложением принимать профиль на гитхабе на интервью.
Списывание, читерство и обман.
При этом само решение тут, гм, решающей роли не играет — по большому счету, вы можете ее даже не решить или решить неправильно, но все равно набрать себе очков, если все делали правильно (и это логично, потому что кому нужны олимпиадники и литкод-ковбои в продакшене :) ).
И да, я (уже) не провожу собеседования в яндекс, это просто мои соображения, основанные на том, как сейчас мы собеседуем к себе. И конечно же есть нерадивые интервьюверы, которые из-за лени или по запарке просто посмотрят на формальное выполнение задачки и потом дадут отписку эйчарам, мол, этот решил — его берите, а этот не решил — его не берите.
При этом само решение тут, гм, решающей роли не играет — по большому счету, вы можете ее даже не решить или решить неправильно, но все равно набрать себе очков, если все делали правильно (и это логично, потому что кому нужны олимпиадники и литкод-ковбои в продакшене :) ).
Эта популярная отмазка Яндекса ("вы, если чё, можете решить всё неправильно, мы принимаем комплексное решение, основываясь на всех аспектах") не бьется с практикой: тем, кто на задачособеседованиях решает неправильно, тут же говорят "извините, дальше мы вас не будем собеседовать".
А если он даже с подсказками не может решить, то это явный звоночек о проблемах.
Ха-ха (сквозь слёзы).
И ведь работает, набирают, кодит у них там кто-то.
Когда вас гоняют по (иногда?) тупым задачкам, хотят вовсе не получить их решение, а достать т.н. «сигналы» — как кандидат себя ведет, как размышляет, как комментирует свои действия, как тестит свой код (каким бы простым он ни был)Ну вообще человек, который понимает, что его время тратят по большому счёту зря, при этом ожидая к себе какого-то уважительного отношения, раздражается, и правильно делает. А умение сохранять покерфейс при работе с неприятными людьми нужно обычно менеджеру, а не программисту (да, даже в продуктовых компаниях и внутренней разработке при общении со стейкхолдерами оно нужно очень ограниченно). Потому, ну, что проверяете, то и получаете.
При этом само решение тут, гм, решающей роли не играетКак уже сказали, это утверждение неверно.
кому нужны олимпиадники и литкод-ковбои в продакшенеЯндексу. Почему-то. Хотя зачем люди идут унижаться в Яндекс за всем этим, когда можно пойти хотя бы в Гугл с теми же предусловиями (плюс английский, окей), мне совершенно непонятно.
Другое дело, что, к сожалению, программисты — зачастую, очень неприятные люди :) Поэтому частенько нарываешься на такой отвратительный подход к проведению интервью — формальный, на отъебись, лишь бы эти чертовы эйчары отстали и можно было бы вернуться к любимому перекладыванию жсонов. И эйчарам, в свою очередь, насрать на то, как эти интервьюверы работают — лишь бы вакансию закрыть худо-бедно.
Так и живем.
Почему зря?Потому что если вы спрашиваете однообразные задачи, которые даже не из разных сфер знаний алгоритмики более двух раз — а примеры выше реально однообразные и практически друг друга не дополняют — вы тратите время зря, притом и своё, и кандидата. Это не добавляет новой информации, это проверяет терпение кандидата, а для программиста ангельское терпение не является ключевой компетенцией. Возможно, потому что процессы поганые, возможно, потому что конкретные интервьюеры/рекрутёры не справляются с задачей (в этот конкретный раз или систематически — другой вопрос).
к сожалению, программисты — зачастую, очень неприятные людиЛюди вообще зачастую очень неприятные, чивоуштам. А если чуть серьёзнее — так задача менеджмента и отдела по работе с персоналом выстроить процессы так, чтобы очень неприятные люди как минимум не собеседовали кандидатов за исключением крайней необходимости, а в полном идеале так вообще не попадали в компанию (но это уже сложнее, и ещё и платить надо деньгами, и вообще шевелиться много), или, если попали, исправлялись по мере возможностей.
Без обид, разбор задачек крутой)
Имхо имеет смысл спрашивать что-то в духе «а что тебе больше нравится из этих вот технологий?». Ответ показывает и знание и заинтересованность (которой у самозванцев нифига нету)
Во-первых, удачи, во вторых я бы подождал постить это, так как они могут увидеть и, сам понимаешь, тайна компании, и.т.д.
А так, скоро наверное и GIL с Multithread будут ненужны, за них всю работу будут делать сервисы Амазонки и Ажура. Вот тогда наверное и будут спрашивать о них :)
При всем этом, Яндекс остается хорошей компанией для работы.
Самое веселое, что эти собеседования, скорее всего, результат «работы» очередного эффективного менеджера. А репутация не манагера, а компании. Ну и вспоминается анекдот про строителя мостов и овцу.
В гугле 3-4 алгоритмических интервью. Но это не 10 задач. Обычно дают 1 задачу с дополнительными вопросами. Вроде: сначала напишите совсем простой случай. Потом а что если у вас данные вот такие придут?
но и понять, как кандидат думает и насколько хорошо вливается в коллектив разработчиков.
Возможно, навыки, необходимые для решения таких задач, положительно коррелируют с результатами в Яндексе.
Учитывая количество внутренних велосипедов в Яндексе, часто у кандидата могут актуальные навыки только на таком низком уровне (stdlib, конечно, тоже, но тут не знаю, почему её знание не проверяют).
Сам недавно проходил такие секции — впечатления неоднозначные.
Вот, сходил даже за первым попавшимся примером:
1) вакансия в яндекс на дата аналитика:
Middle от 130к до 200к; Senior от 200к до 300к + полугодовые премии
2) ниже сразу какая-то небольшая контора из питера, тоже дата аналитик:
Middle 2500 — 3500 USD; Senior 5000 — 6000 USD
Ну опять вот это всё. Смиритесь уже, что никого не волнует знание Django или SqlAlchrmy. Это всё наживное, если мозги есть, человек разберётся. А вот закодить эффективный алгоритм для хай лоада — это уметь надо.
И как на интервью проверить, что мозги есть? Понятно, что лучший способ — взять человека на испытательный строк в пол года, чтобы уж наверняка. Но это непозволительно дорого.
Вроде уже несколько раз прозвучало выше что яндекс таким образом нанимает людей, которым можно внушить корпоративные ценности и которые не будут задавть лишних вопросов. Как показывает эта статья — со своей задачей они справляются, автор отсеился, а если бы прошел то сам бы свалил в течение пары месяцев "задачи мусор и инициативы вообще не дают".
Это раз, второе — когда у вас гигантский поток заявок то нужно отсеивать хоть по каким-то признакам. Хоть по цвету кожи, хоть по гороскопу, хоть по байке "зачем нам нужны неудачники". Если вы физически не можете проводить единолично 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
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. Интервьюеры Яндекса тратят свою жизнь впустую, вместо работы на результат. - Яндекс это отличный тренажёр, чтобы почувствовать себя уверенным на собеседованиях в другие компании.
Дана строка (возможно, пустая), состоящая из букв A-Z: AAAABBBCCXYZDDDDEEEFFFAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBB
Нужно написать функцию RLE, которая на выходе даст строку вида: A4B3C2XYZD4E3F3A6B28
О, по моему скромному опыту, это одна из самых любимых задач у всех собеседующих. Не раз задавали на собеседованиях в самых разных компаниях. Возможно это как то связано с тем что она всегда выпадает в топе выдачи по запросам вроде «какую задачу дать программисту на собеседовании»
В JS она тривиально решается однострочником с регуляркой.
Плохая идея. Почти наверняка будет на порядки медленнее. Регулярки — сильный инструмент, но им очень легко выстрелить себе в ногу.
В JS она тривиально решается однострочником с регуляркой.
А можете показать этот тривиальный однострочник? не троллинга ради, просто интересно.
Могу, эти сведения не содержат гостайну. Выражение вернёт новую строку, можно проверить в консольке браузера.
str.replace(/(.)\1*/g, (s, c) => s.length > 1 ? c + s.length : c)Вряд ли это будет на порядки медленнее, как предположил wataru. Регулярка тут простая, линейная, забирает подстроку и тут же заменяет. Вручную ничего не выиграем, по крайней мере в js.
* имеет преимущество перед + или это просто на скорую руку так получилось?str.replace(/(.)\1+/g, (s, c) => c + s.length)
Извиняюсь за некропост, не смог пройти мимо и не попробовать измерить. Я не знаток js, так что не смог бы угадать результат измерения:
> 'a'.repeat(1e7).replace(/(.)\1*/g, (s, c) => s.length > 1 ? c + s.length : c);
Thrown:
RangeError: Maximum call stack size exceeded
at String.replace (<anonymous>)по сути Яндекс не могут проверить ТС на реальных задачах (потому что не знают или потому что секурность или потому что хрен знает что надо делать завтра) и гоняют его на простых задачах, как проверяют выпускников вуза/курсов
Чтобы понять, как у него мозг работает, вынослив ли :)
ну как если бы грузчика нанимали, дал ему мешок и пусть туда-сюда 100-метровку бегает
самого выносливого (и терпеливого) берешь :)
— Какова сложность сортировки персонала при подборе?
Разделяю мысли автора. Сам завалил собес в Яндексе на первом этапе на вопросах вроде:
- какая здесь сложность в о-нотации?
- что такое чистые функции?
- что такое генераторы в PHP?
Суть в том что это используется каждый день и гуглится за 5 минут, а сложность интуитивно понятна и без этих о-нотации. Зато не было ни одного вопроса по архитектуре приложений (рука-лицо). С тех пор Яндекс и его дочки обхожу за километр.
UPD. Ребзя, я тут понял, что фраза "интервью шли один за другим" может быть неправильно понята. Сорри, я имел в виду, что 2 и 3 интервью были одно за другим, а вообще между 1, (2и3) и 4 собеседованиями проходило несколько дней а то и неделя. Так что тут я не в претензии, время я выбирал удобное мне. так что за это яндексу плюс.
Статью отредактировать не могу, у меня зависает UI хабра, даже в разных браузерах.
Дрочат людей, пока не остаются самые покорные олимпиадники, которые «хотят» попасть в могучий и всесильный яндекс. Это позволяет эксплотировать людей, рассказывая о великий целях, занижать зарплату, тормозить карьерный рост и удерживать кадры.
Ибо очевидно, что обычный человек с нормальной психикой и уже имеет опыт работы в других компаниях уже после 2 собеседования сказал бы, что это какая-то мудохрень, и у него нет больше времени и желания играть в литкод по 5 раз без фидбека в пустоту.
___
Поэтому очевидно, что если вы адекватный спец с опытом работы — то лучше просто игнорировать офферы от яндекса. Ибо вы не тот человек, который им нужен. Просто потратите свое время, пока они поймут, что вас нельзя задрочить.
Уже работая там где работаю :-) получил неожиданно письмо от яндыхового рекрутера. Некоторое время пытался объяснить девочке что работу уже не ищу, что текущая работа устраивает и все такое. Как об стену горох. То ли ей за каждого кандидата, которого она на собес затащит, баллы идут вне зависимости от результата, то ли она действительно уверена, что яндых есть предел мечтаний для каждого разработчика.
Ладно,
Знаешь, кто такой зануда? Это человек, с которым легче переспать, чем объяснять, почему ты этого не хочешь!
(с) Ностальгия
договорились что встречусь по скайпу просто поговорить. Чем занимаются они, что умею я, что мне могут предложить…
Началось с того, что в назначенное время в скайп засунулся интервьюер и сказал что интервью переносится на полчаса. Ну ладно… Может форсмажор какой…
Через полчаса наконец состыковались. И началось сходу «я тут вам подготовил ряд тестовх заданий...»
Стоп. Мы так не договаривались. Я уже давно вышел из возраста юноши пылкого со взором горящим, олимпиадные задачки меня не интересуют — это вы для джунов оставьте. Мне интересно чем вы там вообще занимаетесь и есть ли там для меня какой-то интерес.
Хотите проверить — задавайте конкретные вопросы из жизни. Как решить вот такую проблему. Или с какой стороны я бы подошел вот к такой задаче. На понимание сути, так сказать.
В общем, проговорил ему что-то в этом плане и попрощался. Товарищ, похоже, так и не понял. Ну и бог с ним.
Эм… Вы все еще ждете ответа после фразы "мы вам перезвоним"?
После моего супер-провального собеседования в 2019 (были две задачи: про отель и нули с единицами, обе решил частично) мне через две недели прислали письмо, сказали что не подхожу, надо решать задачи на литкоде и попробовать ещё раз через полгода.
Я бегло посмотрел ваши решения и хочу сказать что вам надо подтянуть базовые знания о LIFO/FIFO и рекурсии. Многие представленные здесь задачки имеют лаконичные решения через стек или рекурсивный обход. Удачи!
Насчёт рекурсии — они ж обязательно спросят, а что будет если на вход подадут 10k элементов?
Ну вот тут LIFO и понадобится. Любую рекурсию можно переписать в цикл+стек. Зачастую и стек не нужен, как в каноничном примере с факториалом.
Теперь понятно, почему у сервисов яндекса столько простых проблем.
И да, на картинке «Этапы интервью» ни слова про soft skills…
Но с другой – Яндекс ведь ищет тех, кто им нужен? Схема отработана уже абсолютно.
Тут у него не было обязанности сделать процесс собеса максимально простым и комфортным.
Была задача отсеять ненужных и найти нужных.
Астанавитись!
JustDont
не бьется с практикой: тем, кто на задачособеседованиях решает неправильно, тут же говорят «извините, дальше мы вас не будем собеседовать».
Может, в этом случае человек не только решил неправильно, но и показал себя, как не умеющего думать? Это вовсе не взаимоисключающие, а скорее, наоборот, связанные вещи.
В этом принципиальная особенность — большая компания может себе позволить нанять вас и не ждать, что вы начнете бешено закрывать таски как только вас пустят в сеть. Постепенно, нагрузка ваша будет нарастать постепенно. Но постоянно :)
Важно понимать, что пройти собеседование — это не конец. Ну наточились вы конкретно на алгоритмы или вам повезло — вы продали себя дороже, чем вы стоите. Значит дальше вам будет очень сложно и тяжело. Вывезете — отлично, все в выигрыше. Не вывезете — ну вас выгонят после испытательного срока. Риск для вас тут даже выше, чем для компании.
Так что собеседования вроде описанных — просто фильтр, нужный для того, чтобы уменьшить количество соискателей до разумного предела. Все самое сложное и интересное начнется позже :)
Простите, вы про наем кого сейчас говорите? Студентов на джуниорские позиции? Тогда ок, обучайте сколько угодно.
Смысл брать опытного разработчика в том, чтобы он принес свой, возможно новый, опыт в компанию/проект.
Какого именно опытного, из тех 30 опытных, что претендуют на 1 место в команде?
А вот нет у меня формулы универсальной, простите. Я всегда предпочитал чтобы человек сам рассказал о своем опыте. Заодно видно насколько он общительный или конфликтный.
Если человек собеседуется на вакансию senior Django developer и рассказывает как он, к примеру, писал API (и какие библиотеки использовал), какие были проблемы и как решались (не обязательно им самим, а командой) — то я не буду его заставлять писать сортировку если он адекватный. И уж точно я не буду давать ему 10 разных задачек на алгоритмы.
Ну, вот представьте, что у вас 30 таких адекватных, которые писали API, а выбрать надо одного.
А вот нет у меня формулы универсальной, простите.
А вот в этом и основная проблема. Многие ругают алгоритмические собеседования, но не предлагают альтернативы. Альтернативы для компаний уровня ФААНГА, когда на одно место претендуют десятки человек.
Алгоритмические интервью (если они проводятся правильно) — это не интервью на знание алгоритмов, это проверка того, как кандидат может думать. Потом, кстати, обычно следуют интервью на системный дизайн и поведенческие, не нужно думать, что все ограничивается одними задачками.
Ну, вот представьте, что у вас 30 таких адекватных, которые писали API, а выбрать надо одного.
Очень просто — если их 30 человек и все адекватные (и прямо все подходят), то до последнего просто не дойдет очередь. Уже после 5 собеседований я перестану тратить время и выберу из пяти. Субъективно, конечно же.
У вас собеседования идут параллельно, вы не можете себе позволить год собеседовать. И, естественно, эти 30 адекватных идут вместе со 170 неадекватными. А еще будет печально, если последний окажется самым талантливым с самым ценным для вас опытом.
Вы мыслите категорями маленькой компании. В гуглах и амазонах мыслят по-другому.
Я вот недавно собеседовал человека, который говорил, что он писал апи, казался адекватным, владел теорией и т.д. А как попросил его написать код, даже не алгоритмичускую задачку решить а написать банальный кусок, похожий на то, что каждый программист пишет каждый день, понял, что код писать человек не умеет. Он ключевые слова языка неправильно писал.
У вас собеседования идут параллельно, вы не можете себе позволить год собеседовать
Ога, зато по 4 часа (как минимум) собеседовать каждого по одной только теме вы можете себе позволить..
А когда вы, наконец, прошли все эти 200 собеседований и выбрали самого-самого, наняли его… И через неделю вам попадается самый-самый-самый! Вы будете увольнять предыдущего?
Давайте не будем углубляться в какие-то непонятные споры. Тут все приводят уже совсем странные примеры.
Суть статьи — на собеседовании на позицию "Senior Django developer" компания провела 4 собеседования для одного кандидата и еще ни разу не зашел вопрос о Django и чем-то хотя бы смежном. Вы считаете это нормальным? Сколько еще будет считаться допустимым?
Ога, зато по 4 часа (как минимум) собеседовать каждого по одной только теме вы можете себе позволить..
Вы правда думаете, что гугл, амазон, фейсбук и прочие не умеют считать деньги?
И через неделю вам попадается
Не попадается, вакансия закрыта, набора на нее больше нет.
Суть статьи — на собеседовании на позицию "Senior Django developer"
Я пишу про ФААНГ, там обычно собеседуют на позицию software developer engineer, а не django developer или jquery developer.
Не вижу проблемы взять на позицию синьора человека, который джанги в глаза не видел. Это не принципиально. Если он действительно синьор, разберется. Если это, конечно, не набор на временный проект, который через пол года завершится. Пока вы ищите и умного и красивого, конкуренты возьмут умного, а красоту наводить его потом научат.
Я согласен с оратором выше: возможно, OptimalBest(A[0;5]) > StrangeBest(A).
При должной фантазии, она элементарно масштабируется на любое количество кандидатов (например каждый интервьюер собеседует неделю или только 10/20/n кандидатов и передаёт лучшего наверх; можно ещё потом сравнивая лучших обратить внимание на вторых/третьих среди отсечённых, поиграться с весами выборок, закодить на основании этого нейронку и так далее).
Можно даже предложить решать эту самую задачу по найму в Яндекс/Гугл/Али/etc. кандидатам, всё веселее будет (а заодно и давать максимально прозрачную обратную связь о критерии отбора и месте сотрудника в этом общем рейтинге). Можно пойти дальше и автоматизировать данный процесс, давая людям задачки и ведя рейтинг лучших. В этом случае рекрутеры собеседуют постоянно, а найм происходит только когда человек:
- Понадобился
- Находится первым в рейтинге среди доступных кандидатов
- Готов к найму
Или математическое решение, алгоритмы и автоматизация это не для крупной компании?
Upd: Ниже ссылка на эту задачу уже есть, проглядел (и извиняюсь), но оставлю в рамках шуточного предложения алгоритмической задачи на собственный же найм.
Ох и представьте себе, сколько же ненависти по поводу собеседований вы будете читать от людей, которые вошли в "калибровачную" стадию, если такой подход использовать.
Но даже без этого, тут есть большая разница. В задаче о невесте нет никакого знания о качестве вариантов. Там могут приходить числа любой размерности. При найме же предел отлично известен (все знающий и умеющий сеньер). Еще, особенно в больших компаниях типа яндекса-FAANG, нужно нанять не одного кандидата, а многих и поток кандидатов можно считать неограниченным. Вот и получается, что идеальное решение — установить нижнюю планку требования кандидата и при прохождении ее сразу нанимать.
Что до сходств и различий…
Есть обобщение задачи, где каждому можно сходу дать абсолютную оценку (пусть будет та самая близость к сеньору в вакууме, работающему за идею). Да и известность предела при найме лично для меня под сомнением: сеньор в вакууме — это как бесконечность при сравнении конечных множеств (а людей всё же меньше 8 миллиардов и далеко не все из них могут подавать заявки на найм). Вроде и очевидно, что больше любого из вариантов, а вроде и информации никакой не даёт. Поэтому с данным аспектом не соглашусь.
Что до найма не одного, а 100/1000/N кандидатов из бесконечного потока — так я потому и писал, что задача масштабируется элементарно: нужно выбрать лучшего из бесконечного потока — решение есть и известно. Нужно выбрать второго лучшего — убираем первого и решение тривиально. Чтобы не гонять цикл — можно запоминать статистику и вести рейтинг. Чтобы держать рейтинг актуальным — добавить всяких весов типа как давно собеседовался, на каком этапе поиска был найден, как сравнивался топ из этой выборки с топами из другой выборки, чтобы оценить в принципе состав исходной выборки и так далее.
Нет, не думаю. Все ваши предположения перечеркиваются одним простым фактом: в фаанге полно адекватных разработчиков и очередь тех, кто туда готовится очень велика. Я раньше тоже думал, как многие тут. А когда стал решать литкод и глубже изучать алгоритмы изменил свое мнение на прямо противоположное. Имхо, это нужно любому синьору, оно, в итоге, помогает в работе и приводит мысли в порядок. Особенно сисдиз.
А зачем стали решать литкод и изучать алгоритмы, что за область применения? Просто для себя решил пока не тратить время на Кнута, вроде оно в вебе не ценится.
Это как-бы стандарт интервью в фаанг. Если вы не Линус Торвальдс, у вас будет такое же интервью, как и у всех.
А зачем стали решать литкод и изучать алгоритмы, что за область применения?
Хочу в фаанг. Но потом просто интересно стало. Более глубокое понимание алгоритмов, их сложности, применимости и т.д. помогает в работе. Я это с удивлением заметил. И не только я.
Просто для себя решил пока не тратить время на Кнута, вроде оно в вебе не ценится.
Я фуллстек. Начните не с Кнута, а с лекций Седжвика на курсере. Начните решать литкод, там есть челлендж, когда в день нужно решать 1 задачку. Вот апрельский. Это правда интересно само по себе.
В телеге есть группы единомышленников.
Это называется «карго-культ». Один придумал остальные подхватили, причем без понимания того, надо оно действительно или нет.
Бывает и такое, да. Почему вы решили, что в случае с Яндексом это так? У вас есть какой-то инсайд, вы работали в компании на найме не линейным специалистом?
Это не отвечает на поставленные вопросы. Линейным специалистам часто некоторые вещи кажутся глупостью, потому что они не видят всей картины.
Отвечает в достаточной степени. Я не буду вам щас расписывать всю подноготную ради вашего праздного любопытства, особенно учитывая вашу предвзятость.
> Линейным специалистам часто некоторые вещи кажутся глупостью, потому что они не видят всей картины
Зато карго-культисты видят всю картину, ага-угу.
Dixi.
Написание абстрактных алгоритмов на коленке переоценено. Умение проектировать архитектуру и видеть пути оптимизации — бесценно. Эти навыки пересекаются мало.
В задачке 4 subranges не нужен, там достаточно помнить текущий максимум, длину предыдущего ренжа (либо 0, когда справа от него него более чем на один нолик) и накапливать текущий. Вот вам и O(N) памяти на пустом месте…
Ну и в 10 задачке картина похожая. Накапливаем текущий ренж, пока он меньше суммы. Если превысил, сдвигаем начало вправо. Тоже всё линейно и без доп. памяти.
Автору спасбо за крутой слог и лёгкий стиль изложения. Браво!
ПС я там не работаю
Давно так не смеялся. Автор, с меня пиво если пересечёмся!
С другой стороны — позиция Яндекса в этой ситуации вызывает мягко говоря недоумение. Предлагать пройти весь этот ад из собеседований с однотипными задачами, что бы потом получить… 200К? Видимо, работать у них — большая честь.
Два раза ходил в Яндекс на собеседования just for fun, а потом в профиле на линкедине написал «Яндекс не предлагать».
Прикольный офис, прикольные ребята. Из приятных воспоминаний симпатичная блондинка, гонявшая меня по плюсам. Программист, с которым мило поболтали про файловую систему линукса (тут моих знаний было мало). И то ли синьёр, то ли лид, который мне доказывал в терминах big-O, что моё решение работать не будет, но я ему прогнал несколько итераций на бумажке и показал, что работает как требовалось, ушёл задумчевый.
Осталось впечатление, что Яндексу не нужен мой опыт, им нужно отличое знание спецификации языка и умение решать олимпиадные задачи.
Помните, тут нельзя ничего запускать, вместо этого тут принято запускать интервьюера, который интерпретирует ваш код прям в голове и говорит какие случаи не работают, чтобы вы могли пропатчить код.
В фейсбуке такие же интервью предлагают. И причем их надо рожать в моем случае на свифте, ны котором в силу специфики работы обычно не держишь в голове всякие там строковые сдвиги и вещи как из Char получить String и обратно плюс всякие там copy-on-write и даже если помнишь какое то решение из универа для свифта его надо модифицировать. И это при точ что я в итоге родил им за 5 часов собеседования все алгоритмы. В итоге они остались чем то недовольны. На что я им сказал что они уже на этих алгоритмах наняли 2х моих бывших коллег которых я нахожу одними из самых паршивых программистов и я переписывал за ними то что они наархитектили, и раз они еще чем то не довольны, значит наверное мне не место в этой компании. А самое забавное что эту же моду взяли самые захудалые мелкие конторы.
Я не минусовал.
В целом, да — интервью прошло не так как ожидал человек. Но по вашему комментарию можно понять будто вы думаете что это что-то плохое.
У человека же есть какое-то самоуважение. Вы 10 лет работали над довольно сложными задачами, у вас опыт на реальных проектах, вы идете общаться с людьми, которые вроде бы даже должны быть выше вас по уровню… Но вас спрашивают то же самое что и студента 4 курса, а об опыте, который нужен по описанию вакансии — ни слова.
Это обидно, в первую очередь. Конечно, 1-2 задачи — без проблем, но 4 часа! А остальное будут спрашивать? Еще 8 часов?
суть поста в том, что человека отинтервьюировали не так, как он хотел?
суть поста в том, что сторона нанимателя ушла в
while True:
passed = check_candidate(task_type="algo",task_level="easy")
if not passed:
break
Где, укажите мне, прописаны каноны, по которым надо проводить собеседования?
А почему он не может написать свое мнение? Обязательно только позитив писать?
1) перед собеседованием вас попросят подготовиться к решению алгоритмических задач (Ок)
2) вас будут гонять от 2 до 10 раз по собеседованиям с разными людьми, на которых вы будете решать одинаково несложные задачи от easy до, если повезёт (или не повезёт, зависит от вашего отношения к таким задачам), middle уровня сложности.
3) вас будут спрашивать «а можно лучше/быстрее? помните про сложность алгоритмов». иногда будут подсказывать.
4) вас не будут спрашивать про интересные вещи, теорию, устройства интерпретатора/компилятора или давать задачи сколько-нибудь похожие на задачи с бизнес-логикой.
Вполне себе знание.
Хочешь в Яндекс? Полируй алгоритмы, и терпение, потому что без терпения 10 раз сходить на одно и то же упражнение не все смогут :)
Где, укажите мне, прописаны каноны, по которым надо проводить собеседования?
Где, укажите мне, прописаны каноны, по которым кандидат не может сказать своё «фи», в том числе публично?
Если нанимаемого не устраивает, он волен покинуть «театр абсурда», а не писать потом негатив в сторону нанимателя.Почему-то вы сами своим же советом не воспользовались, и, вместо того, чтобы молча покинуть эту статью, начали комментировать её. Так стоит ли требовать от других людей того, чего сами же не выполняете?
Это называется «фидбэк». Надеюсь нанимающая сторона это понимает.
Думаю, многие из отписавшиеся тут пишет со стороны соискателя, а не нанимателя. Я за свою карьеру уж давно провел больше сотни собесов, и могу с уверенностью сказать, что умение болтать, рассказывать про фреймворки и технологии вообще никак не коррелирует с написанием кода. Бывает, кандидат рассказывает, как он там всю архитектуру проекта заделал, как он там всех техлидил, на всех существующих языках писал, а по факту даешь задачку как из поста выше, и человек ее даже за час нормально без багосов написать не может. Было, что и пропускали таких кандидатов, и потом это реально оборачивалось проблемами для всех.
Самые крутые кандидаты, с которыми я общался, а потом и работал, на собесах быстро и молча щелкали такие задачи. Прочитал, рассказал, что будет делать, пару минут постучал по клаве, сдал. Смотришь — лаконичный код, все граничные условия проверил, сложность оптимальная, багов нет. Классный кандидат за полчаса решит три задачи из поста, и это почти стопроцентная гарантия, что кандидат и в работе будет классным как специалист.
Когда ты раз сходил на такой собес — кажется, ой, ну какие-то дураки там сидят, фигню спрашивают. А по ту стороны сидят ребята, у которых уже глаз наметан на эти задачи, на типичные ошибки, на понимание того, как кандидат мыслит. Иногда даже по уточняющему вопросу на задачу можно понять, какого уровня приблизительно сидит кандидат.
Болтовня ничего не стоит. Покажите мне код.
— Linus Torvalds
Спрашивать про django, sqlalchemy и т.д. практически бессмысленно, потому что внутри на все есть свои либы. То есть спрашивать такие вопросы норм в компаниях, инфра которой строится на них, но это точно не про Яндекс и FAANG. Если человек не может быстро взять какой-то инструмент и начать им пользоваться (в т.ч. языки программирования), то в таких компаниях на большинстве позиции он вообще будет профнепригоден.
Дальше, чтобы там не говорили про собесы в Яндекс, коллеги там реально крутые, то есть система отбора все-таки работает. Среди твоих коллег всегда будет кто-то круче тебя, всегда у кого-то будет шире компетенция, всегда есть у кого поучиться. Джуны и мидлы уходят на старших/ведущих разрабов в другие компании, а старшие и ведущие вообще валят куда хотят, потому что уровень и кругозор их сильно выше, чем в среднем по рынку (тут, на мой взгляд, Я внутри в этом плане ведет плохую политику, но это уже за рамками поста).
И чисто мое мнение: публиковать задачи один-в-один, какие бы они не были — какой-то адский зашквар для специалиста. Где-то на уровне обиженного админа, который паролит доступы для бывших коллег после своего ухода. Я даже когда кому-то из друзей рекомендации куда-то делаю, не рассказываю про задачи, только в общих чертах (разберись с этим, почитай то, освежи память здесь). Опять же, получается, система подбора Яндекса выиграла, что не наняла вас, раз вылились такие вещи.
// мимо бывший яндексоид
Даже когда были вопросы на собеседованиях про круглые люки (да, я сам их тогда задавал тоже, прошу прощения у всех!), то тоже всегда были люди которые говорили что без них нельзя, почти дословно, простите на сарказм:
Когда ты раз сходил на такой собес — кажется, ой, ну какие-то дураки там сидят, фигню спрашивают. А по ту стороны сидят ребята, у которых уже глаз наметан на эти задачи, на типичные ошибки, на понимание того, как кандидат мыслит.
Если человек не может быстро взять какой-то инструмент и начать им пользоваться
Ну да, быстро нагуглил трендовые инструменты и понеслась! Помним mongoDB в каждом сайте 10 лет назад?
то тоже всегда были люди которые говорили что без них нельзя
Я не знаю, про каких людей, компании и задачи вы говорите. Но чисто для статистики могу сказать, что среди моих друзей, кто увлекается какими-то интеллектуальными играми (ЧГК, Квизы и прочее) больше толковых разрабов, чем из нет, кто не увлекается. Вероятно, с люками также.
Ну и надо понимать, что найм людей в условный гугл и в местячковый КБ с IT отделом — совершенно разные случаи.
Ну да, быстро нагуглил трендовые инструменты и понеслась
Да, как-то так. Чтобы поправить строчку в Го сервисе, мне не надо изучать Го. Потом, принципиально новых инструментов не так много появляется, большинство крутятся вокруг какой-то идее со своими нюансами.
Чтобы поправить строчку в Го сервисе, мне не надо изучать Го.
Чтобы поправить строчку, надо сначала ее найти. Среди тысяч других. А чтобы найти (по описанию дефекта типа «у нас тут должно быть так, а по факту вот этак») нужно этот код прочитать и понять что и как он делает.
Сегодня Го сервис поправить, завтра запрос в базу долговато ходит, послезавтра что-то ручка пятисотит. Умение быстро диагностировать проблемы и решать их — ценно, и за это бизнес готов платить деньги.
Могу поспорить, что Вы не скажете в чем тут ошибка:
if %check(%trim(chDInp): '0123456789') = 0;
Оно скомпилируется. И будет работать. Но неправильно. И будет дефект.
Или вот такое:
setgt (CRF: DInp: Ist: qdsGZRRL1.GZOSI) RRU01LF;
if %found(RRU01LF);
…
endif;
Тоже скомпилируется. И тоже будет работать. Но неправильно.
Чтобы понять почему надо таки знать язык на котором это написано. И тонкости работы его встроенных функций.
1) найти автора кода и спросить у него
2) найти группу, которая ментейнит код, и спросить у них
3) не пропускать код на ревью, который никто не понимает
4) использовать языки, где не будет проблем с пониманием
Могу поспорить, что Вы не скажете в чем тут ошибка:
Вы же не предлагаете это все спрашивать у кандидата? Или вы ищете жестко под одну задачу заточенного человека?
Чтобы поправить строчку в Го сервисе, мне не надо изучать Го.
И привел пример того, что не зная языка, Вы просто не увидите ошибку. Вы не сможете по тексту понять что оно должно делать и что делает на самом деле. И скорее всего не найдете даже то место, где надо править.
Если, конечно, это задача чуть сложнее уровня «Hello World!».
найти автора кода и спросить у него
Уволился пять лет назад.
найти группу, которая ментейнит код, и спросить у них
А зачем тогда Вы там нужны?
не пропускать код на ревью, который никто не понимает
Те, кто пишут на этом языке, прекрасно его понимают. Тут проще не допускать до ревью того, кто не знает этого языка.
использовать языки, где не будет проблем с пониманием
Проще использовать тех специалистов, которые понимают основной язык, используемый в разработке в данной области. И не использовать тех, кто берет на себя смелость править код, не понимая языка на котором он написан.
Вам так не кажется?
Вы же не предлагаете это все спрашивать у кандидата? Или вы ищете жестко под одну задачу заточенного человека?
Я как раз предлагаю не гонять кандидата по олимпиадным задачам. Но в денном случае речь не о том. А об одной конкретной Вашей фразе.
И привел пример того, что не зная языка, Вы просто не увидите ошибку
Почему вы так считаете?
Например, в соревнованиях CTF приходится и в brainfuck уязвимости искать, и ничего, люди находят.
Ну и мы все-таки говорим не о каком-то абстрактом коде и абстрактных языках, в которых, в общем случае, вы будете правы. Яндекс пишет сервисы и около того на пачке одобренных языков типа C++/Python/Go/Java/JS и т.д. Не вижу проблемы переключиться с плюсов на го, чтобы разобраться в каком-то участке и что-то пофиксить.
Многим такая модель не подходит. Но компании такие навыки ценят.
Уволился пять лет назад.
Если никто про этот код не знает, то поднимать вопрос, кто его дальше будет ментейнить (и нужен ли он вообще). Если Вы, то разбираться — тут уже ничего не поделать.
А зачем тогда Вы там нужны?
В вашей компании, я так понимаю, не 300+ разработчиков, которые ежедневно коммитят в один проект под сотню ПРов? Потому что в таком случае люди пишут код сильно быстрее, чем его можно успеть прочитать. И если вместо того, чтобы быстро спросить у коллег, куда надо копать, вы сами будете копать неделю не туда — ну, это плохо.
Те, кто пишут на этом языке, прекрасно его понимают.
Ну, вы же нанимаете людей на языке, на котором пишете, да? Мы же не говорим про случае, когда разработчику на питоне вдруг дают код на VHDL.
Я как раз предлагаю не гонять кандидата по олимпиадным задачам.
Какая задача из этого поста является олимпиадной?
Почему вы так считаете?
Например, в соревнованиях CTF приходится и в brainfuck уязвимости искать, и ничего, люди находят.
Находят ошибки в логике. Но ошибку, связанную с особенностями языка можно увидеть только зная этот язык в тонкостях.
В вашей компании, я так понимаю, не 300+ разработчиков, которые ежедневно коммитят в один проект под сотню ПРов?
Честно скажу — не знаю сколько у нас разработчиков. Больше сотни только на стороне AS/400 это точно (разбиты на много команд — Ядро, модуль пластиковых карта, лимитный модуль, тарифный модуль, универсальный кассовый модуль, система расчетов — это только те, про кого знаю, есть еще) — георгафически расположены в трех городах — СПб, Мск и Екб.
Есть еще вебразработка, мобильная разработка, разработчики Pega, WBI…
В нашем гите несколько десятков проектов. В каждом проекте не один десяток репозиториев (каждая продуктовая линейка — свой репозиторий). Могу сказать как один из ревьюверов (это помимо основной работы) в проекте ядровых функций — за день может пару десятков ПР прилететь на ревью (естественно, что я не один, ревьюверов много и мы делим репозитории между собой иначе на основную работу просто времени не будет)
Ну, вы же нанимаете людей на языке, на котором пишете, да?
В силу ряда особенностей, мы нанимаем разработчиков и готовим их (первые три месяца) на язык и платформу под которую пишем.
В силу ряда особенностей, мы нанимаем разработчиков и готовим их (первые три месяца) на язык и платформу под которую пишем.
Вот мы и пришли к тому, о чем говорю я, и что делает Яндекс, и что делаете вы — нанимаете думающих разработчиков, которых готовите под свои инструменты.
Согласитесь, если человек не умеет писать работающий код на питоне (который он как бы знает), тогда на специфичных для вашей отрасли языках шансы разобраться драматически снижаются.
И уж точно код никто писать не заставит. Спрашивают чем занимался раньше, какие задачи решал. Максимум, могут подкинуть что-то из реальной практики и спросить как бы это стал решать. Без кода, просто на словах в общих чертах описать алгоритм.
Наша практика показывает что этого более чем достаточно. Не помню случая, чтобы после трех месяцев «испытательного срока» (а фактически это обучение), кому-то сказали бы «не подходишь».
Те, кто пишут на этом языке, прекрасно его понимают. Тут проще не допускать до ревью того, кто не знает этого языка.
У меня с опытом все сильнее складывается ощущение, что с ростом экспертизы разработчик перестает быть С++ или там Java девелопером а становится просто Software developer, который баг на любом языке от питона до хаскелля может пофиксить за разумное время, а выбор языка для сервиса будет основывать на "готовые либы чтобы сделать Х и иметь поменьше юзеркода/что знает команда/что со спецами на рынке/...", а не по принципу "ну я С++ дев буду на С++ писать".
У меня с опытом все сильнее складывается ощущение, что с ростом экспертизы разработчик перестает быть С++ или там Java девелопером а становится просто Software developer
Вот этим согласен на все 100.
который баг на любом языке от питона до хаскелля может пофиксить за разумное время
На мой взгляд не совсем так. Я бы сказал что он сможет любой новый язык изучить за разумное время.
выбор языка для сервиса будет основывать на «готовые либы чтобы сделать Х и иметь поменьше юзеркода/что знает команда/что со спецами на рынке/...», а не по принципу «ну я С++ дев буду на С++ писать»
Это верно, в общем и целом. Хотя в нашем случае выбор языков ограничен и делается по принципу «какой наилучшим образом подходит для эффективного решения данной задачи».
Но тут своя достаточно узкая специфика.
О чем и идет эта статья.
дальше можно не читать
Конечно, лучше сразу комент жахнуть.
Со старших/ведущих позиций с длинным хвостом опционов из Яндекса вообще не очень понятно, куда в России уходить — ну просто физически столько денег на рынке не предлагают (зачастую, в т.ч. и за границей).
С мидлами сложнее, потому что их в Я много, не у всех получается быстро расти, hr за ними охотятся и выгодно их продают в другие компании (потому как спрос есть). Но это уже совершенно другая комплексная проблема.
Ну и задачи из поста — ну это же правда смешно. Там же даже каких-то хитрых алгоритмических задач нет, просто аккуратно реши бытовуху. Что так всех бомбит — не пойму.
с длинным хвостом опционовДа куда угодно, где этот хвост компенсируют пропорциональным сайнапом (в деньгах, акциях или опционах), что вообще-то совсем не нонсенс.
Что так всех бомбит — не пойму.То, что человека просят делать одни и те же довольно тривиальные вещи по кругу 10 раз на нескольких собесах, притом иногда ставя откровенно абсурдные ограничения (и да, невозможность использовать стандартную библиотеку языка — абсурдное ограничение, куда полезнее, если зачем-то очень хочется, обсудить, как она работает, и в каких случаях используемые алгоритмы неприменимы/неудачны — по скорости, памяти или чему-то ещё).
1) оплачивают в акциях или опционах
2) в их штате чуть больше людей, чем основатель и его кореш — технический директор
3) своим сайнапом они перекроют зп ведущего разработчика с хвостом опционов в Я
С высокогрейдовых позиции в плане финансов и в FAANG не всегда выгодно ротироваться, не то, что выбирать из 1.5 компаний тут.
Можете объяснить, что такое "хвост опционов" в Яндексе? У каких-то старых сотрудников эти опционы уже должны были конвертироваться в акции которые можно продать и уйти куда угодно?
Например, сейчас вы вместе с окладом выводите опционы за 2015, 2016 и 2017 года, что дает хороший буст к доходу (на высоких грейдах он вполне может быть выше оклада).
3) Тут буквально 3-4 месяца назад слышал, что на 17 грейде в Яндексе оценка С на ревью даёт примерно +250 баксов к месячному окладу в чистом виде, что, в общем-то, совсем негусто. А хвост — ну он на то и хвост, что он когда-то потом будет.
это без хвоста
с хвостом примерно +1000
> хвост — ну он на то и хвост, что он когда-то потом будет
это верно
но те, кто пришли чуть раньше и нарастили его к 2020 году, получили при тех же условиях (17С) гораздо больше, +1500 или даже +2000 в месяц. Да, это не навсегда, а только пока вестятся акции, которые выдавали, когда курс был 30 за акцию, а сейчас стал 60. Если курс дальше не вырастет, то такого больше не будет. А если вырастет — то будет.
А оклады по грейдам это какая-то тайна или нет? Можете примерную табличку с грейдами (и всеми "хвостами" переведенными в условные тугрики) привести? Ну типа мидл — 200к на руки, сениор — 300к на руки, лид — 400к на руки, архитектор 500к на руки? Ну, просто чтобы как-то предметно было.
А то слов сказано много, а понимания что к чему — непонятно. По идее грейды на весь яндекс скорее всего одни и те же и условно в общем доступе, поэтому хотя бы примерно обозначить на что могут рассчитывать разработчики определенного уровня было бы неплохо. Тот же фаанг на levels.fyi эти цифры например показывает
Хм, никогда бы не подумал.
Ну оттуда следует что средненький сениор получает 50к на руки за год
Что кажется вполне неплохо. G18 получает уже 110к на руки, т.е. 8.5 миллионов за год.
Не похоже на "ниже рынка"
Это не сениор, это миддл. По крайней мере приставки "старший" в названии должности у такого нет. Сениор — это 17.
G17 — сеньор.
G18 и выше — ведущий.
Вилка там достаточно широкая, но моя статистика и levels.fyi более-менее бьются.
Ну окей, то есть получается 50000 мидл (321000 рублей в месяц), сениор 75000 (474000 рублей в месяц).
Не знаю в каком мире это "ниже рынка". Если посмотреть отчеты "Моего Круга" тут же на хабре то там в средних красуются смешные по сравнению с этим цифры в 100-150к для мидла. Конечно там регионы вносят лепту и тд итп но все же. Можно на хх поискать мидл вакансии на 300к ради интереса — нет ни одной. А в тех что есть скромненько через слеш пишется senior. Да и вакансий 6 из 1735.
Это не к вам лично вопрос, а скорее в воздух про людей у котороых яндекс — это выжималка, в которой ни денег не заработать ни задач нормальных. И если второе возможно верно (как и для любой крупной компании впрочем), то первое видимо далеко от истины
Ну 32к base для мидла — 200к, что выглядит вполне норм.
В общем-то, я в этом треде и пишу, что с цифрами, особенно для высоких грейдов, там все нормально.
Я лишь могу подтвердить, что числа на левелсах — адекватные. Понятно, у кого-то меньше будет, у кого-то больше, но в целом все так.
я знаю некоторое количество таких
Ну о том и речь, что в РФ таких компаний — даже пальцев одной руки будет много.
Ниже уже скинули зарплаты с levels.fyi.
просто платить хорошие бонусы, которые в некоторых компаниях тоже бывают.
У меня есть друзья во всех топовых российских и не только компаниях, с которыми мы периодически пьем пиво и обсуждаем, где солнце лучше греет. Разве что сбер тут может похвастаться жирными годовыми бонусами, которые с лихвой перекроют опционный хвост 17 грейда. Но это, сами понимаете, вариант с нюансами.
что на 17 грейде в Яндексе оценка С на ревью даёт примерно +250 баксов
Ниже уже обсудили, что это далеко не всегда так.
Надо только понимать, что по большей части эти крутые коллеги пришли еще до того, как начался этот театр абсурда с собеседованиями.
// тоже бывший яндексоид
Надо только понимать, что по большей части эти крутые коллеги пришли еще до того, как начался этот театр абсурда с собеседованиями.
Ну такие собесы в Я появились не вчера. Я какой-то корреляции не заметил.
Вот, кстати, еще один комментарий в похожем треде: " Как проходят алгоритмические секции на собеседованиях в Яндекс" в блоге самого Яндекса.
Прошло два года, ничего не поменялось.
Я думаю, это все первопричина ухудшения качества новых сотрудников, а не задачки на собесах.
Я вот не могу вспомнить сходу что-то такое приходилось делать…
Зато сплошь и рядом попадаются задачи, которые требуют некоторой фантазии для решения. Например как один запрос «в лоб», выполняющийся 3 секунды, разбить на несколько, выделить высокоселективные предвыборки на основе частотного словаря, уйти от использования медленных агрегатных функций, и в результате получить тот же результат, гарантированно укладываясь в 150-200мс. Вот это вполне реальная задача, решающая реальную проблему бизнеса.
Или как оптимизировать параллельную многопоточную обработку большого массива данных, которая занимает 15-17 часов, не трогая собственно обработчик, только за счет оптимизации механизма распараллеливания, уменьшив время обработки до 9-ти часов при том же количестве потоков.
Подобных задач на самом деле у нас встречается очень много. И для каждой требуется индивидуальный подход. И тут важнее умение человека думать нестандартно, чем знание им заученных алгоритмов и типовых задачек.
И лично в моей практике есть примеры людей, которые приходили совсем нулевыми, но буквально за полгода раскрывались в достаточно перспективного разработчика. Алгоритмические задачки таких отсеивают сходу, а вот вопросы на подумать скорее помогут распознать потенциал.
А вот скажите, как часто в работе попадаются задачи из тех, что предлагаются на собесе?
Это же совершенно про разное. Задачи на собесе нужны для того, чтобы понять, как человек думает, что говорит, как пишет код, насколько внимательный к деталям и т.д. Есть человек работает по принципу хренак-хренак и продакшен — зачем он кому-то?
Поймите, что в таких компаниях задачами «оптимизировать параллельную многопоточную обработку большого массива данных» занимается какая-то отдельная «группа параллельной обработки большого массива данных», куда вас, очевидно, не собеседуют. Вас вполне могут нанимать на перекладывание джейсонов, а не на оптимизацию работы с БД. А еще надо понимать, что в таких компаниях можно встретить каких-нибудь core разработчиков БД (или даже ЯП), которые уже давно все оптимизировали.
но буквально за полгода раскрывались в достаточно перспективного разработчика. Алгоритмические задачки таких отсеивают сходу
В таких компаниях обычно девиз: «лучше не нанять хорошего разработчика, чем нанять плохого». Вы же понимаете, какой там поток резюме? На одного потенциально хорошего джуна там придет десяток уже крутых мидлов — зачем тогда тратить время?
Приходит такой Линус Торвальдс на собес в Яндекс.Лавку, говорит — "я Linux напи..."
А ему — "нам наплевать что вы там написали, давайте посчитайте сколько тут символов в строке"
Михаила Парахин ушел из Microsoft на позицию технического директора в Яндекс (потом, правда, вернулся). И, кстати, будучи в ТОП-менеджменте, он даже фигачил код. Помню, была какая-то отличная либа на AVX.
Не надо сравнивать позиции обычного копателя джейсонов и рок-звезд. Очевидно, автора поста собеседовали на мидловские позиции, и он совсем не Линус Торвальдс.
Они что, всерьез думали, что я пойду «перекладывать джсоны» со своей текущей позиции? Вот вот прям серьезно? Все брошу и побегу?
Я понимаю мальчиков, которых на рынке рупь за пучок так гонять…
Понятно, что бизнес всегда хочет купить нас подешевле, а мы продаться — подороже.
Главный разработчик ЦБС (Центральных Банковских Систем) в Альфа-Банке. Чтобы понятнее — это бэкенд глубже некуда — команда ядровых функций АБС (Автоматизированной Банковской Системы). Т.е. все, что происходит «наверху» так или иначе приходит к нам. А также все, что крутится в фоне, обеспечивая работу банка.
Работает все это на платформе IBM i (бывш. AS/400) на серверах IBM PowerS9. Пишем на IBM'овском языке RPG (ну и частично на C/C++ там, где нужно более глубокое взаимодействие с системой). Впрочем, до этого я работал в совсем другой области и на С, а позже на С++ пишу года этак с 89-90-го (т.е. стаж в разработке кой-какой имеется, равно как и понимание как надо и как не надо в достаточно широком круге вопросов от работы с БД, распараллеливания обработки больших массивов данных до межпроцессного взаимодействия в гетерогенных распределенных системах).
И решать олимпиадные задачки яндыха до того, как определены позиции что мне могут предложить, что могу предложить я и насколько все это взаимно интересно — ну как-то совсем не с руки.
Девочка-рекрутер мое резюме читала и была в курсе что к чему. И я сразу поставил условие что для начала будет просто разговор для определения позиций. А дальше уже решим.
Но интервьюер был или не в курсе, или просто не в состоянии отойти от привычного шаблона — сходу завалить олимпиадными задачками.
Ну а мне не настолько нужны деньги чтобы прогибаться.
Оффтоп: я биллингом раньше занимался, и там почти вся финансовая часть была на коболе. У вас был и вы его выжгли напалмом, или не было? Или вообще до сих пор живёт с вами?
Но кобол поддерживется в концепции ILE (С/С++, CL, RPG, COBOL) и его компилятор встроен в систему. Так что возможность писать на нем формально есть :-)
АБС бывают разные. Вот пример. Обслуживался когда-то в одном небольшом банке. И, видимо, АБС там была достаточно простой. Ибо ситуация такая: есть счет, к нему привязаны две карты. А надо понимать, что остаток на счете и остаток по карте — это две разные вещи. И было там так. Есть на счет 10тр. В статике обе карты показывают по 10тр доступных средств. Заходим в магазин, покупаем что-то на 10тр, расплачиваемся первой картой. После этого смотрим остатки. Остаток по счету 10тр. Остаток по первой карте (которой платили) — 0р. Остаток по второй карте 10тр. Заходим в другой магазин, покупаем еще на 10тр, расплачиваемся второй картой. Смотрим остатки — по счету 10тр, по обеим картам 0р. На следующий день (иногда через день, все это сводится воедино и на счете получается технический овердрафт в -10тр. Так работает АБС.
У нас такое невозможно — АБС работает в реальном времени и все эти остатки синхронизируются в течении нескольких секунд. Но ценой нагрузки на сервер, конечно — все это должно обрабатываться быстро.
Второй пример. Баланс (который притча во языцах каждого бухгалтера) в банке сводится не раз в месяц, а каждый день. Это называется EOD — End-Of-Day (переход на следующий операционный день) и занимает несколько часов ночью. Некоторые АБС на это время приостанавливают работу банка (т.е. все операции как бы проводятся, но фактически складываются в кеш и проходят уже после EOD следующим днем). Но, опять же, не у нас. У нас перед началом EOD создается т.н. «юнит ночного ввода» как копия основного юнита и все операции переносятся туда и продолжают выполняться. А в основном юните проходит EOD. По завершении которого юнит переходит в следующий день и все изменения, что произошли в течении EOD в ночном юните «накатываются» в дневной. Тоже лишние танцы с бубном, но обеспечивают непрерывную работу системы. Естественно, все это автоматизировано.
Открывает клиент счет — банк должен предоставить данные в налоговую. Система сама отслеживает изменения в таблице счетов и как только бухрежим по счету перешел из состояния «зарезервирован» в состояние «активен», сама формирует сообщение для налоговой и отсылает его через MQ в соотв. внешнюю систему, которая уже отвечает за передачу данных.
Карточки клиентов (клиентские данные) — это тоже часть АБС. А там много чего понавешаено. Те же риски клиентов (страновые, репутационные...) — все это обрабатывается автоматом по изменению клиентских данных.
Комплаенс. Моя тема. Росфинмониторинг регулярно присылает списки всяких злодеев. Разбираются и раскладываются по базе они автоматом (последнее время как раз этим занимаюсь). Пришел новый список, разложился — запускается процедура серки клиентов. Это прогоняются все активные клиенты (несколько десятков миллионов если что) и для каждого производится поиск совпадений со списками злодеев — по именам, ДР, ДУЛ (документ удостоверяющий личность), ИНН, адресам. Формируется отчет по совпадениям (полные, частичные). Это все автоматом тоже. Соответсвенно, есть набор APIшек для проверки совпадений… Тоже наша работа… Они же используются для контроля платежей — от кого, кому (а не пособствуем ли мы финансированию террористов?)…
Все это и еще очень много чего является функциями АБС. И любое изменение требования регулятора приводит к необходимости доработки той или иной функции. Чем мы и занимаемся :-)
В результате на серверах одновременно крутятся тысячи фоновых процессов. Тут, кстати, проявляется одно из преимуществ AS/400 — она изначально сделана для такой работы. В силу ряда особенностей в ней минимизированы до предела накладные расходы на смену контекста при переключении между процессами. Так что она еще очень долго будет жить и развиваться в этой нише — там, где требуется одновременная работа многих процессов.
Что касается скуля… По нашим наблюдениям он далеко не всегда является оптимльным с точки зрения производиетльности и потребления ресурсов. Просто потому что перед выполнением требует времени и ресурсов на построение плана запроса. С этим можно мирится для статических или параметризированных запросов — один раз построил план и пользуйся им. А вот если запрос динамический и формируется на лету… И при этом вызывается десятки тысяч раз в секунду… Получается очень дорого.
Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных. По нагрузочной статистике на это уходило до 36% времени и до 33% процессорных ресурсов данной процедуры. К счастью, RPG позволяет не только скулем работать, но и прямым обращением к таблицам (функции позиционирования по индексному файлу, чтения из таблиц...). Переписал, избавившись от скуля. Да, больше кода. Но стало быстрее работать и меньше грузить процессор. А функция была критичная — как раз поиск совпадений по наименованию со списком злодеев. Т.е. вызываться она могла в определенных ситуациях десятки миллионов раз подряд.
Фактически скулем пользуемся когда надо делать большие сложные выборки по нескольким таблицам. И можно использовать статический параметризированный запрос.
А вот прочитать одну запись из таблицы по ключу (или выбрать десяток-сотню записей) — это быстрее «нативным» RPG. Или проверить наличие в таблице записи с заданным значением ключа (просто есть или нет — содержимое записи не интересует) — тут даже в саму таблицу лезть не надо, просто посмотреть индексный файл.
В общем, там очень много тонкостей, требующих знания языка, платформы на которой работаешь… И смешно читать как человек «правит код на Go самого Go не зная».
Но, справедливости ради: многое из перечисленного, если не все, можно решить и без усложнения АБС (хотя, что дешевле — вопрос тот еще).
Веселуха с картами на бывшей работе (не топовый банк в топ-50)была при переходе на новый процессинг, но потом пофиксили — онлайн синхронизация (с некоторыми дополнениями для предотвращения теховера).
При закрытии дня работа не останавливалась, тут к сожалению деталей реализации не знаю, работал все-таки аудитором, а не разрабом.
При этом была высока доля ручных операций, что впрочем было не из-за архитектура («сложилось исторически»)
По скулю — если отключить оптимизацию запросов нельзя обойтись без построения плана запроса?
P.S. вам-то, наверное, в работе нужно знание алгоритмов.
Насколько знаю бизнес-логика пишется на Java и прочих Haskell-ах, а тут ассемблер среднего уровня (если C++ есть ассемблер высокого уровня).
Java мы используем только для вебсервисов и под них выделен отдельные сервер в кластере. Ибо работает медленно, а памяти жрет как не в себя.
С Хаскелем не сталкивался — нет его у нас…
Основной язык — RPG Вполне себе высокого уровня. На нем пишется основная часть кода. Что-то системное пишется на С/С++.
Причем, на AS/400 есть такая концепция — ILE Вкратце — можно написать несколько модулей на разных языках (из состава поддерживаемых в ILE — Cobol, RPG, C/C++, CL) и собрать их в одну программу. Т.е. из процедуры, написанной на RPG можно вызывать функции, написанные на С/С++ и наоборот. Главное — правильно описать прототипы.
Ну или можно напрямую из RPG программ вызывать функции С-шной библиотеки (работа с файлами, qsort, bsearch и т.п.) — компилятор их сам найдет :-)
Компиляторы всех ILE языков есть часть системы. Ну вот простейший пример (кусок инсталлятора на языке CL — это системный язык AS/400):
CRTCPPMOD MODULE(QTEMP/DTAQ) SRCFILE(&ASRC/&SRCF) SRCMBR(DTAQ) OUTPUT(*PRINT)-
DBGVIEW(*SOURCE)
CRTCPPMOD MODULE(QTEMP/BATCHM) SRCFILE(&ASRC/&SRCF) SRCMBR(BATCHM) OUTPUT(*PRINT)-
DBGVIEW(*SOURCE)
CRTCPPMOD MODULE(QTEMP/BATCHMWRP) SRCFILE(&ASRC/&SRCF) SRCMBR(BATCHMWRP)-
OUTPUT(*PRINT) DBGVIEW(*SOURCE)
CRTSQLRPGI OBJ(QTEMP/ELB03S) SRCFILE(&ASRC/&SRCF) SRCMBR(ELB03S) DBGVIEW(*SOURCE)-
COMMIT(*NONE) OBJTYPE(*MODULE) RPGPPOPT(*LVL2) SRTSEQ(*HEX) OUTPUT(*PRINT)-
LANGID(RUS)
CRTRPGMOD MODULE(QTEMP/ELB07PROC) SRCFILE(&ASRC/&SRCF) SRCMBR(ELB07PROC)-
DBGVIEW(*COPY)
CRTPGM PGM(&ALIB/ELB03S) MODULE((QTEMP/BATCHM) (QTEMP/BATCHMWRP) (QTEMP/DTAQ)-
(QTEMP/ELB03S) (QTEMP/ELB07PROC) ) BNDDIR((*LIBL/LESBNDDIR) ) ACTGRP(*CALLER)-
TGTRLS(*CURRENT) STGMDL(*SNGLVL) ALWUPD(*YES) ALWLIBUPD(*NO) ENTMOD(QTEMP/ELB03S)
Сначала компилируем модули:
CRTCPPMOD — модуль написан на С++
CRTSQLRPGI — модуль написан на SQLRPG — RPG с использование SQL команд внутри RPG кода
CRTRPGMOD — модуль на «чистом» RPG без SQL
CRTPGM — собираем все модули в один программный объект
Если на С функция выглядит как
extern "C" int WordsCount(char *pBuffer, int nBuffLen)
то на RPG ее прототип будет:
// количество слов в строке
dcl-pr WordsCount int(10) extproc(*CWIDEN : 'WordsCount');
pBuffer char(65535) const options(*varsize);
nBuffLen int(10) value;
end-pr;
И оно вызывается и работает.
Посему, что проще на RPG — пишем на RPG. Что проще на С/С++ — пишем на С/С++ :-)
Есть достаточно сложные реализации, например, у меня есть реализация SkipList на С++ (с классами, объектами), к ней Сишный враппер и RPG прототипы, позволяющие создавать из RPG объект SkipList (возвращается хендлер объекта) и потом работать с ним уже из RPG программ.
Есть и более сложные вещи — скажем, батчмашина для распараллеливания обработки. Сама машина написан на С++, но используется из RPG
// Создаем многопочку
Master = Batch_CreateMaster('*LIBL' : 'ELB07S' : '' : 'ETLPROC' :
DtaQLib : 'DQELBMAST' : 'DQELBWORK' :
WorkersCount :
(%size(t_qdsClient) * SendBlockSize) :
(%size(t_qdsClient) * SendBlockSize) :
PingTime : ResendCount : RecieveTimeout :
strError);
Тут через spawn запускается несколько процессов (JOB) — обработчиков (программа ELB07S), количество процессов указано в WorkersCount.
Создаются очереди для обмена данными DQELBMAST — Мастер->обработчики и DQELBWORK — обработчики->мастер
А затем мастер готови пакеты данных для обработки и выдает их в очередь
Batch_MasterSendData(Master : pData : DataLen : ErrStr)Ну и всякая обвязка — контроль за состоянием очереди, состоянием заданий и т.п. Все это прописано внутри объекта на С++ НО используется из RPG.
При закрытии дня работа не останавливалась, тут к сожалению деталей реализации не знаю, работал все-таки аудитором, а не разрабом.
Ну формально она не останавливется. Просто операции откладываются до нового дня.
Я не говорю что у нас лучше всех :-) Просто есть так а есть этак. Вот у нас так…
При этом была высока доля ручных операций
Ну вот мы стремимся эту долю сокращать всемерно.
По скулю — если отключить оптимизацию запросов нельзя обойтись без построения плана запроса?
Нет. План запроса все равно строится. Хотя бы для того, чтобы понять какие индексы подцепить.
В ряде случаев скуль эффективнее. А в ряде нет. Наша задача — понимать где как лучше :-)
вам-то, наверное, в работе нужно знание алгоритмов
Да на самом деле не сильно. Логика у нас в целом туповатая в 99% случаев. Больше общие паттерны — как ту же батчмашину эффективно построить, как правильно распределить роли между мастером и обработчиками…
Очень много требований к обработке ошибок, их логированию и мониторингу.
Ну систему с ее особенностями представлять надо. А система ни на что не похожа. Она «объектная» — «все есть объект». И очень много специфических типов объектов. Надо их понимать как оно работает и что когда и где использовать.
Ну иногда нестандартное что-то бывает, конечно, но там просто фантазию включать надо :-)
Нет. План запроса все равно строится. Хотя бы для того, чтобы понять какие индексы подцепить.Тогда понятно почему для скорости используется MongoDB, хотя в основном mongoose используется, чтобы привлечь к работе тех, кто не знает SQL.
Есть программа, запущенная в отдельном задании (JOB). И она вызывает другую программу (много раз, скажем, несколько миллионов за цикл свой жизни) в котрой требуется получить какие-то данные из БД.
Если данные получаются статическим sql запросом (строка запроса захардкожена на этапе разработки, меняются только параметры — значения host переменных), то все хорошо — план запроса построится один раз при первом вызове а все последующие будут выполняться уже по ранее построенному плану.
Все плохо, когда это невозможно и строку запроса приходится формировать в рантайме. Вот тогда план будет строиться каждый раз что отнимает и время и ресурсы.
К счастью, на DB2 for i есть два способа работы с БД — через sql и прямым доступом (поиск записи по значению ключа).
Прямой доступ никакой подготовки не требует, только открыть файл (опять же, он открывается только при первом вызове, дальше сохраняется открытым до конца жизни задания).
Посему, когда нам надо получить большие объемы данных и можно использовать статический скуль — используем его. Если же речь идет об одной записи по известному значению уникального ключа — проще прямой доступ.
Или, например, проверить наличие записи с заданным значением ключа — прямой доступ позволяет вообще не читать ее из файла а только посмотреть есть ли ссылка на эту запись в индексе.
Или, например, такое — нужно определить есть ли в файле запись с заданным ключом, а если есть, то одна или несколько — тут тоже прямой доступ эффективнее — нам не надо считать все записи. Если нашли, то проверяем — есть ли еще хотя бы одна. Если есть — все, выходим.
Ну и так далее… Т.е. всегда смотрим и думаем — что в данном случае будет эффективнее — скуль или не скуль.
На следующий день (иногда через день, все это сводится воедино и на счете получается технический овердрафт в -10тр. Так работает АБС.Жесть какая-то. Так не работает нормальная АБС. Не из нашего времени. Устриц ел, если что.
В результате на серверах одновременно крутятся тысячи фоновых процессовЕдиницы сотен — могу понять. Какая-то жуть в архитектуре.
И любое изменение требования регулятора приводит к необходимости доработки той или иной функцииВезде так. У у всех. Да и по-другому быть не может. В-общем, наверно, не понял примера и к чему он.
А вот если запрос динамический и формируется на лету… И при этом вызывается десятки тысяч раз в секунду… Получается очень дорого.
Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных
Да, больше кода. Но стало быстрее работать и меньше грузить процессор. А функция была критичная — как раз поиск совпадений по наименованию со списком злодеевО боги… еще тысяча и один пример из серии таких же «возьмите уже грамотного sql-разработчика один раз и не мучайте железо и весь отдел дикой самопальщиной».
Вот смотрите. НА вход приходит фраза. Ее надо разбить на список слов. Это список надо дополнить словоформами для каждого слова (из таблицы словоформ)(фактически — для каждое слово из входной фразы в списке должно присутствовать во всех 6-ти падежах + двух вариантах транслитирации на латинице). Это первый запрос.
Второй запрос — поиск совпадений по другой таблице. Там ищутся совпадения слов из списка с тем, что есть в таблице (ну плюс еще несколько дополнительных условий).
Фраза каждый раз разная. Количество вызовов только в одной задаче (а функция вызывается много где еще) — несколько десятков миллионов раз за время работы задачи.
Что тут сделает «грамотный разработчик SQL» так, чтобы запрос можно было сделать статическим с парамтерами, а не формирующимся на лету в процессе выполнения и требующим prapare в каждом вызове?
Разбить все это на несколько запросов? И в чем профит? У нас есть возможность работать с индексом напрямую, без скуля.
Одиночный запуск версии со скулем в лоб на тестовой среде — 21мс. Одиночный запуск нескулевой версии на тестовой среде — 7мс.
На копии промсреды вся задача (использующая эту функцию) целиком. 34648 вызовов. Старая версия 7.98сек, новая 6.71сек при меньшей процентов на 30 загрузке процессора.
Причем, основные претензии именно по загрузке процессора.
Из PEX статистики работы XXXXXXX видно, что 33% времени и 36% ресурсов CPU тратится на выполнение QSQRPARS в программе YYYYYYY, т.е. парсинг статических выражений при подготовке SQL запроса
Вот эти 33% времени и 36% ресурсов процессора мы исключили отказом от скуля в пользу прямого доступа к таблицам.
Ну и фразы типа "Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных" кричат о необходимости грамотного разработчика. А кусок про поиск словоформ — и вовсе о необходимости грамотного архитектора.
Есть список наименований (это могут быть имена, названия организаций и т.п.). Кириллица, латиница… Несколько сотен тысяч.
И есть «фраза» (имя, наименование) в произвольном падеже или одном из нескольких вариантов транслитерации. Нужно найти совпадение.
Т.е. если в таблице присутсвует «Иванов Иван Иванович», то фраза «Ivanovu Ivanu Ivanovichu» должна дать положительный результат на совпадение.
Эластиков в наличии нет. Библиотек тоже.
Частота вызовов очень большая. Из самых разных мест. Кешировать бесполезно т.к. придется держать в памяти всю таблицу со всеми вариантами написаний, такой возможности нет.
Входная фраза произвольная.
Что ему нужно для работы? JVM?
И кто будет его сопровождать? Следить за тем чтобы все работало?
Какую дополнительную нагрузку он дает на сервер?
Как у него с поддержкой — в случае возникновения проблем кто-то готов быстро их решать?
Вы поймите — банк, это не яндекс лавка. Потери от недоступности системы тут серьезнее (в том числе и материально). Поэтому используются очень консервативные, проверенные решения имеющую серьезную поддержку производителя.
И тащить кучу всякого зоопарка под каждую локальную задачу сюда никто не даст. А это локальная задача. Одна из очень многих.
Повторюсь — она решена. НА том уровне, который удовлетворяет требованиям бизнеса и сопровождения.
Решение занимает 500 строк кода (17кб исходник) со всеми обвязками.
Реально:
- Получение списка словоформ 77 строк кода
- Получение списка совпадений (всех, включая частичные) — еще 65 строк кода.
- Анализ списка совпадений с выбором полных — 24 строки кода.
Итого смысловая часть 166 строк кода.
Вы предлагаете ставить непонятную хрень, которая будет жрать ресурсы там, где можно обойтись одной функцией из 500-т строк кода? Серьезно?
Может быть яндекс не так и неправ, когда отсеивает кандидатов, неспособных решить тривиальные алгоритмические задачки без использования сторонних библиотек и фреймворков?
А функция была критичная — как раз поиск совпадений по наименованию со списком злодеев. Т.е. вызываться она могла в определенных ситуациях десятки миллионов раз подряд.
Прикрутите себе кеш уже. И будет у вас один фулл скан таблицы на каждое обновление кеша раз в N минут. Не очень дорого.
Не надо из sql kv хранилище делать. Оно работает конечно, но плохо.
И будет у вас один фулл скан таблицы на каждое обновление кеша раз в N минут.
Это очень дорого в наших масштабах. За такое разработчика сразу за причинное место на всеобщее обозрение повесят. В назидание другим.
Я не знаю баз для которых раз в несколько минут один раз прочитать одну табличку полностью дорого. Естественно у таблички должен буть приемлимые размер, в вашем описании он как раз такой.
Если у вас можно производительность закручивать хинтами или ещё как вниз то надо закручивать. В этом месте можно работать дольше.
Конкретно эта таблица может использоваться из многих заданий. Т.е. придется городить еще одно задание, которое будет хранить кеш, потом для этого задания делать механизм запрос-ответ, который позволить получать данные кеша из других заданий…
Все это даст неслабую дополнительную нагрузку на систему в целом.
Для всех у которых большая нагрузка по kv паттерну. А что тут такого? Так примерно все и делают. Чтобы нагрузку держать и sql базу не грузить.
Просто читать не из sql, а из общего кеша. Порефактрить код придётся, но опять же ничего страшного. Вы и так рефакторили чтобы читать как-то по другому.
Есть порядка 40млн возможных фраз. Каждую из них надо проверить по вышеуказанному алгоритму — разобрать на слова, составить список слов со всеми возможными словоформами… (фраз среди которых ищутся совпадения несколько сотен тысяч). Что тут кешировать?
И это всего одна таблица. А их… да фиг знает сколько у нас таблиц в БД. Это наверное только сопровождение может сказать. Все будем кешировать?
Не, в понимаю, когда в БД десяток таблиц и примерно столько же процессов, их использующих. А если тысячи? Таблиц и процессов…
То, что я описываю, это всего лишь одна маленькая частная задачка.
У вас есть табличка в которую летит большой rps по kv паттерну. Проверить наличие по ключу или по строке это именно он и есть.
40 миллионов с формами это ну пусть миллионов 400 без оптимизации даже.
Инмемори влазит без проблем.
Берёте и кладёте эту табличку в любой инмемори кеш. Любой стандартный подойдёт. Настраиваете периодическое обновление. Прочитать раз в 5 минут табличку на 40 миллионов записей вообще не проблема для БД.
Дальше переводите всех клиентов на обращения к этому кешу вместо sql таблички.
Для каждой следующей таблички с аналогичным паттерном нагрузки повторяете.
Получаете маштабируемое решение. Вам становится просто все равно на нагрузку в этом месте. Типовые вещи на небольшом железе вытягивают вообще любой rps. Sql база перестаёт испытывать нагрузку.
Прочитать раз в 5 минут табличку на 40 миллионов записей вообще не проблема для БД.
Вы так уверены? Пробовали читать 40 миллионов записей в каждой из которых лежит мегабайтный jsonb?
Там в условиях фамилии.
Делать kv поиск по полю с мегабайтом данных как-то неразумно. Класть такое поле в табличку вместе с обычными данными тем более неразумно, если у вас не колоночная БД.
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
Это наша система. Данные достаточно старые, сейчас еще больше.
Насколько помню цифру — сейчас порядка 3млрд изменений БД в сутки.
Вы предлагаете закешировать в памяти все 15 тысяч таблиц? И все их перечитывать фулсканом каждые 5 минут? Гениальное решение, что сказать…
Тот пример, что я привел, это всего лишь маленький кусочек. И далеко не самый критичный.
И там решение есть. Оно лежит вне рамок SQL (который не всегда и не везде оптимален, хотя имеет свои преимущества в ряде случаев). И вот эту его неоптимальность и пытаются компенсировать костылями типа кешей. У нас в том нет необходимости (т.е. кеши локальные используем там где это реально необходимо — справочники всякие и т.п. но глобально держать всю БД в памяти нет возможности, да и необходимости тоже) т.к. есть альтернативный, noSQL, способ доступа к данным.
При чем тут вообще масштаб всей системы? Явно же не во все таблички идёт большой rps по kv схеме. Ну и значит и не надо все так делать.
Делается мониторинг, собирается статистика. Находятся больные места. И именно они обвешиваются кешами.
Альтернативный — это читать с других железок. Читать все всегда с одной железки рано или поздно упирается в эту самую железку.
Основная проблема у нас — ресурсы процессора. Даже не скорость — ее хватает в целом. А вот за эффективность использования процессоров боремся всесильно. Так что регулярный фулскан тут — очень плохое решение.
Нужно с таких монстров переводить нагрузку на обычные контейнеры, крутящиеся на обычных серверах. Ресурсы обычных серверов стоят минимум на порядок меньше чем на ваших мега железках.
Ресурсы х86 процессоров не стоят почти ничего. Они ну очень дешевые. Чаще упираешься в шину памяти.
Кеш который я предлагаю это ну пусть три ноды по 2 ядра. 6 ядер и сколько там памяти. Хватит на десятки тысяч рпс точно. Это такие копейки по железу что даже говорить не серьезно.
Требования к надежности и устойчивости банка достаточно высоки. Отдельные части системы имеют очень жесткие ограничения на периоды недоступности (дальше начинаются штрафы от регулятора «за неисполнение обязательств перед клиентами», в особо тяжких случаях до отзыва лицензии).
По поводу стоимости и производительности серверов
Если в курсе — расскажите про организацию АБС в банках из топ-10. Просто для сравнения. И назовите банк, где все это «на обычных серверах» построено.
в особо тяжких случаях до отзыва лицензииесли мне не изменяет память, самое быстрое событие для отзыва лицензии — это неотправка рейсов в Банк России в течение 4 дней.
Я описал стандартную архитектуру всех яндексогуглов. Это работает. Стандартным образом. Стабильнее Сбера уж точно.
Все типовое, взаимозаменяемое и быстронакатываемое. Ну вылетела железка и ладно. Просто берётся запасная. Автоматика сама на неё накатит софт и подключит слейвом к двум оставшимся.
Ну вылетела железка и ладно. Просто берётся запасная.
Даже комментировать это не буду.
По нашим оценкам:
Час простоя АБС может стоить банку до 24 миллионов рублей
прямых финансовых потерь при кратковременной недоступности.
Это не учитывая репутационных потерь, которые могут привести
к прекращению банковской деятельности в целом.
Цена выхода из строй одной «железки». Яндекс может такое себе позволить. Мы — нет.
Строго говоря, у нас архитектура распределенная. Все, что можно вынести за пределы АБС, вынесено.
АБС – это сердце банковской системы.
От него зависит жизнеспособность подавляющего
большинства банковских сервисов.
Его остановка приведет к почти полному прекращению
предоставления автоматизированных банковских услуг.
К АБС подключено более 60 банковских систем,
обеспечивающих работу различных бизнес направлений.
Большинство фронт приложений используют АБС,
как основной источник информации и функциональности.
Все эти 60 систем для АБС есть «внешние системы» общающиеся с ней через WS или MQ.
Внутри АБС сконцентрировано то, что не имеет смысла дробить дальше без ущерба надежности, функциональности и сопровождаемости — слишком высоки и дороги риски.
можно сделать АБС параллельной
Что имеется ввиду?
АБС фактически является комплексом из множества одновременно работающих процессов, обрабатывающих информацию и запросы от внешних систем.
Например, есть очередь MQ. Есть «монитор» очереди, который извлекает оттуда сообщения и по заголовкам сообщений определяет в настроечных таблицах обработчик для данного типа сообщения и запускает его в отдельном процессе, передавая ему содержимое сообщения.
Есть процессы, которые запускаются фоном по определенным событиям или в определенных фазах работы.
Фактически, там многое что работает параллельно.
Но все это крутится на одном сервере. Есть еще резервный сервер, на который в любой момент возможно полное переключение всей системы (регламентное время недоступности системы в случае отказа основного сервера порядка 5 минут).
Можно раскидать все это на много железок, но начнутся потери производительности на коммуникационной шине плюс для сопровождения следить за одним сервером проще чем за несколькими железками. И каждую железку придется дублировать отдельно.
Фактически, там многое что работает параллельно.наверное, я не очень точно выразился — имел ввиду каждый бизнес процесс седлать разделяемым на множество и разнести все это по разным машина.
Но все это крутится на одном сервере
Интуиция подсказывает, что на каких-то объемах уже придется это делать, но как уже сказал
это теоретические рассуждения, а практического опыта в таком у меня нет.
Все, что возможно, уже вынесено на уровень «внешних систем».
Понимаете, все что я говорю, я говорю лишь относительно ядра АБС. Но ядро это далеко не весь банк. Это… Ну в общем, ядро оно ядро и есть :-)
И писал уже — внешних систем у нас порядка 60-ти штук. Самых разных. Они обмениваются данными с ядром через ESB шину, через WBI-MQ… Но работают вне его и вне ядрового сервера. Если ляжет внешняя система, на работоспособности ядра это никак не скажется. Если ляжет ядро — ляжет весь банк.
Дробить ядро уже невозможно — там все между собой достаточно тесно интегрировано.
Ну вылетела железка и ладно. Просто берётся запасная.
Даже комментировать это не буду.
Речь про то, что потеря одной (и более) железок вообще не должна сказываться на работе сервиса. Либо время частичного простоя измеряется долями-единицами секунд. Речь про такую систему.
В целом же сравнивать нужно сравнимое. Например, архитектуру серверных решений банков из ТОП-10 (тех, у кого сравнимая нагрузка). Тогда можно будет говорить о преимуществах и недостатках того или иного подхода.
Для быстрой реакции (переключения) нужен, конечно, резерв, причём горячий. И мощности закладываются так, чтобы фактор репликации учитывался в запасе мощности. Иначе, как вы и привели пример, при отказе и временном росте нагрузки, все может стать ещё хуже.
В случае использования стандартного железа (без подходов вертикального масштабирования), это стоит адекватных денег и окупается примерно после первого сбоя, если сервис критично важен. Но тут, конечно, не могу сказать за всех, проекты бывают разные.
10-20% запаса от серверов в проде достаточно для любой горячей замены.
Это не касается уже работающих в проде серверов естевенно. Тут как минимум от одного любого сломавшегося сервера до отключенного ДЦ надо учитывать. Так чтобы это не влияло на пользователей.
Сломалось что угодно и ладно. Все работает как раньше. Сервер из горячего запаса наливается автоматикой. Через час-два готов ко включению слейвом в любую БД или принимать нагрузку если там данных локальных не нужно.
Через час-два готов ко включению слейвом в любую БД или принимать нагрузку если там данных локальных не нужно.
Я писал выше — час недоступности у нас стоит порядка 24млн.
Переключение на горячий резерв в нашей системе — не более 5мин недоступности.
И еще приводил статейку выше — трехнодовый сервер на Power L922 (12 ядер) с производительностью 3064QpH обойдется в $817k.
Такой же сервер на Xeon SP (48 ядер) с производительностью 2891QpH обойдется в $1899k.
Или вы предлагаете банковские сервера строить на компах из М-Видео или DNS?
Вы специально пропустили все кроме этой фразы про час?
Зачем М-Видео? Сервера много кто делает. 2к это нормальная цена. Даже недорого ещё. Я думал там под 5к уже.
А вот 817к это неразумно.
За такие деньги можно огромное резервирование обеспечить и еще на огромный запас производительности останется.
2к это нормальная цена
Не 2к Смотрите вниматлеьно — 1899 тысяч долларов США
против 817 тысяч долларов США.
Но это за все «решение целиком» — 3 ноды с софтом (железо, виртуализация, ос, бд). Железо конечно скромнее — $37k за сервер на L922 против $52k за сервер на Xeon SP.
Ну и о каких серверах мы говорим? ДЛя контор типа «ООО Сукин и Сын» может и подойдет сервер за 2к, а для банка из топ-100 с несколькикми десятками миллионов клиентов и сотнями миллионов счетов — сильно сомневаюсь.
Мне почему-то не кажется что у того же яндкса или не дай бог гугля, сервера за 2к стоят…
Как раз столько и стоят. Ну может 5к.
Смысла нет платить больше. Проще взять побольше и организовать резервирование. И в прод лишний сервер добавить и в запас поставить. Так и дешевле и надежнее.
Вы все время пытаетесь принизить все остальные проекты, не надо так делать. Мы тут тоже большие вещи делаем. И даунтайм тоже много денег стоит.
Вы просто скажите — сколько таблиц у вас в БД, сколько процессов вокруг этого крутится, какой примерно объем таблиц. И, главное, сколько стоит час недоступности вашей системы в деньгах и прочих рисках.
Ну или приведите конкретный примерт типа «вот ВТБ работает на серверах по 5к и у них все замечетельно».
Я просто пытаюсь сказать, что банк — это очень много данных. Это не только счета-проводки, но и огромное количество других операций с данными, которые проходят постоянно. И огромное количество отчетности. И очень жесткий контроль со стороны регулятора (ЦБ, Росфин, ФНС...). И очень жесткие требования к устойчивости и надежности. Тем более жесткие, если банк считается «системообразующим».
Если вы скажете, что ваша система управляет, скажем, АЭС (или хотя бы энергораспределительной системой крупного региона) — я готов поверить, что решение на серверах за 5к может быть надежным (просто немного представляю те требования, которые там предъявляются к устойчивости системы).
И да, я ничего не имею против серверов за 5к. Там, где этого достаточно.
Или вы думаете, что в банке не умеют считать деньги? И там сидят дурачки, которым эти деньги девать некуда, что они просто ради понтов покупают системы за сотни килобаксов? Так у нас не государственный банк. Мы живем ровно на то, что зарабатываем сами. И если было бы дешевое решение, удовлетворяющее требованием надежности, масштабируемости и сопровождаемости, то он давно бы уже работало.
На обычных серверах за 5к работает примерно весь интернет. Да-да Гуглы, Яндексы и иже с ними.
Я вообще ничего не придумываю, я просто описываю типичную схему работы любого крупного сервиса.
Но, начинали они именно с идеологии «максимально дёшево, но заменяемо». По слухам, так живут и сейчас.
Максимально дешёвые серверы, состоящие из материнки и минимального набора компонентов, чтобы оно не вывалилось из стойки, и не сгорело.
Общий принцип — многократное резервирование и контроль за тем, что именно сгорело. Вроде бы работает: на серваках Гугла (включая youtube, и других), чуть ли ни четверть мирового интернет-трафика.
Основной идеей выбора именно такой основной идеи было то, что поставщики серверов дерут втридорога, и всё-равно не способны обеспечить даже 3 девятки.
Горячий резерв с автоналивкой новых серверов.
Отказоустойчивость всех систем к вылету любой одной единицы. Подозреваю что у Гугла это ДЦ целиком.
И типовое недорогое железо. Зато много железа.
Гугл типовое железо может удешевить сделав свою карманную контору по сборке серверов, ну и хорошо. Те кто не могут такую сделать просто на рынке покупают.
Ну какова цена того, что кто-то вдруг не сможет посмотреть ролик на трубе прямо сейчас? Да никакая. Ну посмотрит через полчаса. Ну пошумят из телевизора «ах, на гугле что-то сбойнуло». Все.
А теперь представьте что вы пытаетесь расплатиться картой в магазине, а вам говорят «извините, ваша карта не работает потому что ваш банк не отвечает». А потом выясняется, что он начал отвечать, но пропали последние несколько операций по вашей карте, которые не успели отзеркалиться на резерв перед тем как упала железка на которой они хранились.
Т.е. тут надо не просто иметь резервную железку, тут надо еще чтобы эта железка в реальном времени зеркалилась с рабочей. И так для всех железок в системе…
Да, можно одну большоую дорогую железяку заменить на много маленьких и дешевых. И для каждой создать горячее зеркало. Но будет ли это дешевле в итоге? В том числе и в сопровождении? Вот не факт.
И такой момент — у того же гугля — труба отдельно, почта отдельно, диск отдельно. Это разные системы, достаточно независимые. Их можно разнести.
В банке тоже много разных независимых систем: инетбанк, мобильное приложение, процессинг, рассылка уведомлений — все это внешние системы, их можно отделить физически. Но ядро АБС неделимо. Там все данные очень тесно связаны между собой (практически все таблицы имеют перекрестные связи так или иначе) и падение любой из них в той или иной степени затронет всю систему целиком.
Разнеси все это на 10 дешевых железок — надежность только уменьшится т.к. падение любой железки будет означать падение всей системы целиком.
А теперь представьте что вы пытаетесь расплатиться картой в магазине, а вам говорят «извините, ваша карта не работает потому что ваш банк не отвечает».у нас такое постоянно с самым крупным банком — приват. Примерно пару раз в год их терминалы не работают и расплачиваться в магазинах можно только наличкой.
Правда видел во многих супермаркетах ставят по два терминала. Один из которых не приватовский. Видать страхуются от таких вот сюрпризов
А если еще у приоритетного клиента в это время не прошел платеж на несколько миллионов — тут уже не отмоешься.
Те же карты — два часа не работают — это ЧП для банка.приватбанк смотрит на вас с недоумением )))
Вот буквально неделю назад https://www.interfax.ru/russia/758335
Крупнейший банк. Упал серьезно. И всем пофиг.
Не переоценивайте надежность или ценность аптайма банков. Падают за милую душу. Чаще Гугла. В разы чаще.
Сбер — во-первых это фактически государственный банк. Там клиентам деваться некуда — бюджетников тех же туда просто загоняют силой. Во вторых, сбой продолжался несколько минут. Т.е. сопровождение быстро все подняла.
В третьих, я не знаю что там у них за АБС. Возможно, это как раз те «сервера за 5к».
Т.е. тут надо не просто иметь резервную железку, тут надо еще чтобы эта железка в реальном времени зеркалилась с рабочей. И так для всех железок в системе…
Для обычных серверов лучше иметь минимум три такие железки. Резервирование это абсолютно нормально.
Но ядро АБС неделимо. Там все данные очень тесно связаны между собой (практически все таблицы имеют перекрестные связи так или иначе) и падение любой из них в той или иной степени затронет всю систему целиком.
Напомню что началось все с того что я предложил вместо магии использовать типовой кеш. Для kv нагрузки на одну из таблиц. И сразу нагрузка упадет.
Кажется там много таких мест. Которые можно безболезненно вынести.
Напомню что началось все с того что я предложил вместо магии использовать типовой кеш. Для kv нагрузки на одну из таблиц. И сразу нагрузка упадет.
Кажется там много таких мест. Которые можно безболезненно вынести.
Напомню, что это одна таблица из тысяч. И далеко не самая большая и не самая важная. И дорогой по ресурсам кеш легко заменяется 500-ю (со всеми комментариями) строками кода на написание которых уходит час-полтора (придумать-написать-проверить).
Если для Вас это магия — Вам не надо в разработку. Лучше заняться чем-то попроще.
Вот у меня по одной из последних задач — 33 таблицы (включая журнальные и архивные) и 80 индексов. Это нормально. Задачка не относится напрямую к счетам-проводкам. Это по линии комплаенса. И что, предлагает и это все закешировать?
И таблицы клиентских данных (которых тоже не одна и не две)? И таблицы счетов? Карточек, проводок? К ним всем идет очень плотное обращение…
И, главное, зачем все это нужно? Все решается, просто нужно немного подумать и выбрать наиболее эффективный способ. А Кеш, который будет регулярно, надо, не надо, фулсканить тысячи таблиц — это очень плохое решение. Даст дикую и абсолютно ненужную нагрузку на сервер.
Кроме того, таблица — это всего лишь хранилище. А доступ к ней идет по индексам (это называется логический файл). У таблицы этих индексов может быть десяток и более — разные процессы используют разный порядок доступа (логический файл может сразу объединять данные по нескольким таблицам, может содержать разные дополнительные условия) — все это тоже как-то кешировать?
Костыли в последсвии навредят больше чем пользы принесут. Проверенно не одним поколением разработчиков уже.
Зачем сюда тащить все остальное? Декомпозиция знаете про такое? Есть задача — решаем ее.
У другой задачи может быть другое решение. Это нормально. И ее надо решать отдельно от первой. Уменьшение связности — хорошая штука.
Здась это не так. Задача — одна из множества, одновременно выполняющихся на сервере. И проблема ее была совсем не в том, что она выполняется долго. Проблема была в том, что она потребляет несоразмерно много ресурсов.
Ваше решение будет потреблять еще больше ресурсов, пусть не в рамках самой задачи, а в рамках того, что обеспечивает ее работу.
Ваш подход аналогичен тому, чтобы под строительство собачьей конуры подводить фундамент как под 50-этажный небоскреб.
А то, что вы называете «костылями», на само деле и есть работа разработчика. Не интегрировать стандартные решения без оглядки на их эффективность (это не только скорость, но и ресурсоемкость), а находить оптимальное решение с точки зрения баланса скорости и нагрузки на процессор.
Фактически в наших условиях всегда решается задача —
есть временное окно в рамках которого загрузка системы составляет XX%. Необходимо построить решение так, чтобы уложить решение в рамках заданного окна, не превысив общей загрузки системы в YY%.
Если вы найдете решение, которое укладывется во временное окно с двукратным запасом, но при этом загрузка системы превысит заданный порог — это настолько же плохое решение, как и то, которое не превышает пороговой загрузки, но не укладывается по времени.
Я понимаю, что это не сразу укладывается в голове — видеть не только свою задачу, но всю картину целиком. Но со временем к этому привыкаешь и на многие «стандартные решения» начинаешь смотреть иначе.
Вообще, разработка в системе, которая изначально ориентирована на одновременное выполнение и разделение ресурсов на множество процессов немножко отличается от разработки в системе где об этом не надо заботиться.
Сейчас нет разделения ресурсов, нет одновременных задач. Есть изоляция всего. Обычные точки пересечения и разделения ресурсов это sql БД. Поэтому на них нагрузку снижаем всеми силами.
Прочитать табличку со слейва раз в 5 минут это очень дешево. Поставить три виртуалки с 6 ядрами и 15 гигами оперативки на всех это тоже очень дешево.
И это маштабируется как угодно. Будет нагрузка в 10 раз больше? Не вопрос, докинем железа и переварим без проблем. Делать вообще ничего не надо.
Впихивать все больше кода, логики, данных и rps в одну самую большую машину это путь в никуда. Ее ресурсы имеют свойство заканчиватся и не маштабироваться никак. Лучше пораньше начать выносить с нее нагрузку чем потом когда упретесь в ресурсы делать тоже самое в авральном режиме.
Но вы не сказали сколько, например, обновлений БД в сутки проходит у вас. Сколько процессов крутится вокруг БД. Ну чтобы проще понять — вот пришел запрос — что происходит? Поиск в БД и возврат ответа? Или если это (к примеру) запрос на изменение данных, он вызывает длинную цепочку множества вторичных изменений, различных проверок, формирование отсылок данных в различные внешние системы…
Что произойдет если пропадет, скажем, одна запись в БД?
Сколько денег вы потеряете за эти 15 минут простоя?
Ну вот для примера — есть Госуслуги. Которые регулярно встаю колом в момент записи детей в школы. Шуму по этому поводу из каждого утюга. И что? Да ничего…
А если в банке произойдет сбой в системе контроля платежей и пройдет платеж в сторону получателя из списка росфина, кричать по телевизору о том не станут. Но регулятор выкатит штраф с очень многими нулями.
Если произойдет сбой в других системах, то сотни тысяч клиентов по всей стране могут оказаться в магазине перед кассой с невозможностью расплатиться картой «нет ответа от банка».
Повторюсь — я не думаю, что в банке не умеют считать деньги. И была бы возможность обойтись сервером за 5к — обошлись бы.
Повторюсь — я не думаю, что в банке не умеют считать деньги. И была бы возможность обойтись сервером за 5к — обошлись бы.очень сомневаюсь, думаю там действуют по принципу — «работает — не трогай» )) Ну и да, экспериментировать там себе дороже будет. Поэтому и сидят на таких монстрах с ораклом за 100500$. Ынтерпрайз он такой — суровый и беспощадный
умаю там действуют по принципу — «работает — не трогай» )) Ну и да, экспериментировать там себе дороже будет.
Да. Классический пример — один австралийский банк (по-моему, Банк Содружества Австралии или что-то в этом роде) повелся на модный ныне тезис «долой легаси, писать нужно на современных языках» и решил переписать весь банковский софт (работающий) с кобола на что-то современное.
В итоге обошлось им это в $750млн, пять лет работы (не знаю уж сколько там народа работало, но по объемам нашей системы могу предположить что не одна сотня человек) и потом еще глюки вылавливали долго. В том числе и такие как обнуление кредитных задолженностей всех клиентов :-)
Так что что-то менять — это очень дорого, да.
Но ведь был момент когда все это строилось с нуля. И в этот момент изучался опыт, выбиралась платформа… Одни банки выбирают оракл, другие еще что-то. У нас вот выбрали as/400 (ibm i) и db2. Что лучше что хуже — тут нет однозначного ответа.
Тут еще есть момент поддержки производителя. Которая тоже входит в стоимость оборудования. Знаю что у нас есть свой представитель в IBM. Знаю что мы можем с любой проблемой туда обратится и ее будут решать незамедлтельно. Знаю что мы можем заказать аудит производительности — приедут спецы, проедут аудит, покажут тонкие места, дадут рекомендации по оптимизации… Все это входит в цену платформы на котрой мы работаем
Знакомый рассказывал, что у них на сервер IBM был установлен RHEL7 и была подписка, какой уровень точно не помню. И возникли проблемы с драйверами raid контроллера, который естественно был сертифицирован IBM и RedHat
В итоге, сам RedHat исправили багу в драйвере и отдали им исправленную версию драйвера
Уровень подписки не знаю какой, знаю что есть представитель (его почему-то называют «адвокат») — что-то типа персонального менеджера непосредственно в IBM.
Если ваш основной бизнес это интернет-поиск (условно, вы — Гугл), то вам для снижения расходов и повышения эффективности логично переписать половину ОС или применить необычные паттерны, создав новый язык программирования, но при этом вы будете держать основные деньги на обычных счетах юрлица в нескольких нацбанках и получать банковские переводы «на следующий день».
А если ваш основной бизнес это финансовые услуги — (условно вы — Industrial and Commercial Bank of China) вам для снижения издержек и повышения эффективности логично захеджировать рискованные активы, не позволять деньгам сверх необходимого лежать на коррсчетах, участвовать в маржинальных сделках по всему миру и т.п., но вы купите проверенные серверы у надежных производителей и используете зарекомендовавшие себя в банковской сере подходы к разработке софта.
АБС у нас тоже не на 100% своя. Купили основу (позже выкупили исходники), которая обладает базовым функционалом плюс позволяет писать свои расширения к ней. И с тех пор расширяем ее функционал для обеспечения автоматизации наших бизнес-процессов и соответствия текущему законодательству и требованиям регулятора.
Т.е. у нас ест стандарты, обусловленные структурой базовой части АБС плюс набор уже наших нефункциональных требований, обусловленных эффективностью и производительностью программных модулей.
Из плюсов: пропадение строчки в некоторых местах допустимо. Но чтобы БД теряла за последний год я не припомню. Это скорее бонус обработке. Можно немного менее параноидально писать код. Терять даже 1% недопустимо. Тут речь именно про потерю любой одной записи.
Сколько денег вы потеряете за эти 15 минут простоя?
Деньги меряются в милионах за минуты простоя. Точнее не скажу. Много в общем.
Повторюсь — я не думаю, что в банке не умеют считать деньги. И была бы возможность обойтись сервером за 5к — обошлись бы.
Гугл как-то обходится. Только не надо говорить что у вас надежность больше чем у кор сервисов Гугла. Или что вы потеряете больше денег чем они.
Думаю, Ваш случай — это косяк HR (а с ними постоянно косяки). То, что ваши пожелания сразу не были учтены — это вот самый первый признак того, что где-то в цепочке между HR, который с вами общался, и интервьювером, что-то сломалось (а там может быть много человек).
Вас вполне могут нанимать на перекладывание джейсонов, а не на оптимизацию работы с БДТогда организаторов интервью-процесса надо уволить за профнепригодность, потому как они не проверяют ключевые компетенции кандидата.
лучше не нанять хорошего разработчика, чем нанять плохогоВы-таки не поверите, но можно хорошо задрочить литкод и в целом алгоритмическую базу и всё равно быть плохим, даже отвратительным разработчиком, просто не в тех же аспектах, что и Senior Spring/Django/Symfony Developer, который не умеет сортировать массив быстрее, чем за O(n^2 log n) (да, я утрирую, я знаю, что это медленнее пузырьков и прочих сортировок вставками)
Тогда организаторов интервью-процесса надо уволить за профнепригодность, потому как они не проверяют ключевые компетенции кандидата.
Я не утверждаю, что найм в Я идеальный (и даже хороший). Просто он такой. Такой же он и в FAANG.
В таких компаниях не смотрят навыки работы с технологиями, а смотрят алгоритмы, структуры данных, умение быстро решать задачи и т.д. Кому-то это подходит, кому-то нет. Это как спорить с тем, что вода с более высокой позиции течет в более низкую.
Вы-таки не поверите, но можно хорошо задрочить литкод
Вот знаете, среди тех, кто круто задрочил литкод, я не видел плохих разработчиков. Есть обратные примеры?
Да, много кто теоретизирует, что «задрочить литкод — фигня», «олимпиадники не умеют писать код» и т.д., но на практике это все самые топовые разрабы, которые могут вообще в любой проблеме разобраться, а не только список развернуть. Я лично с такими долго работал, и говорю это со всей серьезностью — это лучшие разрабы, у которых я очень многому научился.
Senior Spring/Django/Symfony Developer
Эти все нужно вне больших компаний.
Ведь чем больше система тем сильнее «и так работает»/«ни чего же не произошло»/«так сложилось исторически», а уж если нужда не заставляет меняться то ни какие инициативы снизу (по крайней мере по непрофильным вопросам) не пройдут через руководитво.
«олимпиадники не умеют писать код»
Порой действительно не умеют, но быстро учатся.
Интересно мнение бывшего яндексоида. Почему Я проводит так много алго-раундов? 10 задач выглядит как перебор, почему не разбавить system design раундом?
Большие компании спрашивают меньше: не считая первого скрининга, на Senior Амазон тратит 3 алго раунда, из них половина времени на leadership principles, в итоге 3 задачи всего. Гугл 3 раунда, 3-6 задач, Фейсбук 2 раунда, 2-4 задачи. При этом всегда есть system design раунд.
1) у автора хорошее резюме, им заинтересовались разные команды
2) он не особо хорошо решал задачи, одна команда теряла интерес и отваливалась, другая подключалась и начинала снова «с нуля», затем история повторялась
3) в системе найма никто не сказал «эй, не надо спрашивать пять раз одно и то же, доверяйте результатам других команд», в результате получилась какая-то ерунда.
По пункту 2 и 3 — почему не почитать фидбек с предыдущих раундов, которые твои коллеги проводили, код посмотреть? Нужно чтобы кто-то обязательно подсказал со стороны? Выглядит странно.
Вопрос не только по конкретной ситуации, знаю людей которые тоже по 10 задач решали с 8+ лет опыта и без раундов по систем-дизайну (или их нет в Яндексе?).
да, я согласен
Раунды по систем-дизайну делают для старших грейдов.
Для "старших грейдов" — это надо подаваться на вакансии с уровня Старший специалист чтобы у тебя провели System Design?
Dan_Te написал верно, его, скорее всего, рассматривали разные команды, а т.к. уровень и код был так себе, то разные руководители искали, подходит ли им этот кандидат.
Насчет system design — он есть на старшие грейды. Если бы из собеса было понятно, что кандидат претендует на старший грейд, ему бы провели архитектурную секцию. Даже по его решениям я могу сказать, что явно не претендовал.
Дальше, чтобы там не говорили про собесы в Яндекс, коллеги там реально крутые, то есть система отбора все-таки работает.а можно неудобный вопрос — раз там такие крутые «коллеги», то почему 90% их творений такие
N лет назад тоже проходил несколько кругов
Всех мини-боссов мне в итоге одолеть не удалось, однако боюсь, что такой упор, который делает Яндекс на алгоритмические задачи, очень слабо коррелирует с тем, чем придётся заниматься на ежедневной основе. Исключением пожалуй может стать должность заведующего алгоритмами поиска или управления беспилотными автомобилями, но тогда вероятно «Искусство программирования» Дональда Кнута придётся зачитать до дыр.
Это кстати я не шуткую, реально: если вы ответственный человек, ты вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах.
Нет. Суть в том, что это работает как proof-of-work. Теория такая: если ты способен выучить алгоритмы, то ты, вероятно, толковый специалист. У этого есть две стороны:
- Хорошее знание алгоритмов в целом позитивно коррелирует с профессиональными навыками, но не более. И до определенного уровня. Т.е. статистически это о чем-то говорит, что в отдельном случае может быть полное поражение. Поэтому мне этот подход тоже не нравится, хотя я понимаю, почему к нему прибегают.
- В целом алгоритмы, конечно же, не нужны, если заниматься только django-формошлепанием. Однако, если есть какой-никакой load, хотелось бы иметь человека, который union-find сразу задетектит. Т.е. прошел хотя бы один (один) университетский курс по алгоритмам. И при этом не нужно быть способным все эти задачи решить в блокноте без тестов и компилятора, нужно лишь быть способным вспомнить: "ха, да это же классическая задача на объединение множеств, для неё не нужна сортировка, она вообще линейная".
Не угадал, конечно — "а можно быстрее?". Но тут, к счастью, время вышло, и мой мозг не успел придумать ничего лучше.
"А можно быстрее?" — это всегда хороший вопрос. Потому что даже если решение "правильное", сделать его быстрее почти всегда можно. И даже если нельзя быстрее, можно показать, что ты в целом знаешь, как подходить к этому вопросу. Или показать, что не знаешь.
lst = [0, 0, 1, 1, 0, 1, 1, 0]
#lst = [0, 0, 1, 1, 0, 1, 1, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1, 0]
#lst = [1, 1] # частный случай, когда все единицы
length = 0
max_length = 0
if 0 in lst:
for i in map(len, ''.join(map(str, lst)).split('0')):
if length + i > max_length:
max_length = length + i
length = i
else:
max_length = max(0, len(lst) - 1)
print(max_length)
По специальности минимум вопросов было…
На втором этапе нужно было сделать реализацию LRU кеша, в итоге я не решил за отведенное время и всё, отказ прям в этот-же день...:(
По началу расстроился, т.к. на эту позицию сделал им ещё тестовое задание, преобразователь Erhernet ->CAN, зачем нужно тестовое задание, если оно ничего не решает непонятно…
Рассчитывал на беседу по специальности, а получилась беседа в области к сожалению где я мало чего знаю, хотя сейчас решил подтянуть алгоритмы.)))
Понятное дело, компании виднее, но утомительные беседы отталкивают всякое желание пробовать ещё раз.
Хотя согласен, что всё-же алгоритмы не плохо-бы подучить, хотя на практике редко приходится их вот так самому с нуля писать.)
Даже в моей области, когда используешь вообще голый Си, где ничего нет, быстрее будет взять уже готовый алгоритм, например алгоритм быстрый сортировки, чем сидеть и тратить время на его реализацию.)
Зачем всё-же знать алгоритмы?
Бывают ситуации, что-бы понять какой выбрать, ну и если есть какие-то ошибки в реализации, для отладки нужно понимать суть.
А-так, да все эти вопросы — это теория, по факту мало чего показывают, но повторюсь компаниям виднее, примерно так спрашивают не только Яндекс, а и тот-же Касперский например, правда там меньше секций, но суть примерно такая-же.)
lst = [0, 0, 1, 1, 0, 1, 1, 0]
length = 0
last_length = 0
max_length = 0
if 0 in lst:
for el in lst + [0]:
if el == 0:
if length + last_length > max_length:
max_length = length + last_length
last_length = length
length = 0
else:
length += 1
else:
max_length = max(0, len(lst) - 1)
print(max_length)Не минусовал. Ваше решение похоже работает. Но минусуют, наверно, потому что у кого-то возникла мысль "хвастается, зачем-то. Никто же не спрашивал, как решать задачу, зачем это писать?"
Или кому-то не понравилось, что вы обрабатываете отдельно случай всех единиц в массиве. Плюс код работает очень неявно. Непонятно, чем именно является last_length, почему они суммируются именно при 0. Еще, возможно из-за двух подряд идущих комментариев от вас с решением.
Есть, например, вот такое решение. Оно мне кажется проще и понятнее:
def FindOnesSequence (lst):
print(lst)
# Max sequence of 1s at the end of processed list.
current_ones = 0
# Max sequence of 1s at the end of processed list,
# if exactly one element is removed.
current_result = -1
result = 0
for e in lst:
if e == 1:
current_result = max(current_result + 1, current_ones)
current_ones += 1
else:
current_result = current_ones
current_ones = 0
if current_result > result:
result = current_result
return result Это, фактически, динамическое программирование. Но можно о нем рассуждать и не зная ДП. F(i,k) — максимальная длина из '1' в конце списка из первых i элементов, если оттуда удалить k элементов. Для k=0, оно считается в current_ones. При k=1, оно считается в current_result и там выбираются 2 варианта — или элемент удален раньше или удаляется последний элемент.
— Middle?
— Курьер.
Где-то в 2012 проходил собеседования на сисадмина, было 1 телефонное, 1 скайп и 1 очное техническое, после чего сделали оффер. Толи время идет и все меняется, толи просто из-за различий в позициях и админам и щас после 3х собесов дают оффер.
Писал статью про найм людей на питоне прошлым летом (в ML-стартап) но подход диаметрально противоположный, зацените, тогда вроде всем зашло.
Причем что важно — выбрали в итоге людей, которые бы наверное не прошли бы 4 раунда таких "испытаний", но у них все в порядке с головой и они всегда решают именно "реальную" задачу и стремятся найти креативные и творческие решения нетривиальных задач.
И да, если вы ищете работу на питоне — залетайте к нам. У нас не Яндекс.
Не стал ее постить напрямую на Хабр, т.к. побоялся, что за такую нативную "рекламу" словлю пермабан на Хабре. Но автор молодец, вроде не боится =)
Ну забанят — буду ещё где-нибудь писать. Тем более это так себе реклама, никто не пишет почти.
я прочитал, заценил, интересная статья, но:
1) подход через соревнования или ДЗ, действительно, позволяет гораздо больше понять про кандидата. Надо заставить человека реально поработать, и все становится ясно. Но с таким подходом можно нанимать либо студентов, либо очень мотивированных работать именно у вас людей, другие не станут тратить время. Да даже неприлично как-то работающего человека заставлять. Я тоже применяю иногда ДЗ, но только в самых крайних случаях (и когда уверен, что кандидат сам это позитивно воспримет, ведь ДЗ позволит и ему тоже понять, интересны ли ему наши задачи), так вообще это запрещенный инструмент.
2) сама за себя говорит цитата: «Это стоило больших усилия для меня лично и для нашей команды.»
Так что подход у вас, конечно, прикольный, но на вооружение его вряд ли стоит брать. Более того, вряд ли вы сами захотите подобным образом развлекаться в следующий раз. Процесс найма в компанию должен быть масштабируемым и повторяемым, описанный процесс этому не соответствует.
Еще меня местами зацепили подколки, троллинг, и в целом не видно по тексту, чтобы вы с уважением относились к кандидатам, но возможно, что это такая манера изложения, а в жизни было все плюшево.
Без шуток, это хорошее собеседование для студента без опыта работы, т.е. если работодатель уверен в том что соискатель ничего не умеет и "пороха не нюхал", то вариант отличный, но у готового специалиста спрашивать такое — бесполезная трата времени, причем для абсолютно всех.
Собеседовался 3 раза в общей сложности. Все три завалил, лучший результат — 4ый собес, 5/6 решённых задач. Последний раз собеседовался в сервис, который использую как минимум раз в неделю. И который был практически неюзабельным несколько недель из-за глупой ошибки бизнес-логики: цена фиксировалась на интервал меньший, чем нужно человеку на подтверждение действия. Очень хотелось уже устроиться и делать человеческий сервис, с человеческим качеством пользовательского опыта. (Да, я наивен до степени уверенности, что могу что-то изменить в корпорации). Но не получится.
У меня были коллеги, которые уходили в эту компанию. Несмотря на разносторонние знания, в Яндексе их сажали на простую работу, вроде однообразных скриптов на Perl.
Четыре часа таких собеседований проверят, устойчивы ли вы к подобной работе (причём каждое следующее проводит рекрутер более высокого уровня, а вы к нему приходите всё более и более вымотанным).
В конечном итоге, такая цепочка даст ответ на главный вопрос: действительно ли у вас математический склад ума? Потому что только человек с таким складом способен находить удовольствие в подобных задачах. А это — внезапно — психологическая основа системного программирования.
Вывод: Яндекс успешно применяет «сито» задач, через которое могут просочиться только люди с математическим складом ума, способные стать хорошими системными программистами. При этом какие именно у вас знания, им неважно. Думаете, там своих креативных технических начальников не хватает?
«скрипты на perl»
«зп ниже рынка»
Зачем?
Ну может кто-то считает, что Яндекс — полезная строчка в резюме.
Возможно про ниже рынка это миф. По крайней мере у меня противоречивая информация насчет доходов. Если считать не оклад, а вообще все доходные статьи
2) В компании система грейдов, что заставляет тебя сидеть на одном уровне и просаживаться с течением времени по зп посравнению с ранком (если ты не какой-то супер-звезда).
3) Выдача RSU идет весьма по сложной схеме, где от тебя мало что зависит. Как итог, тебе их могут дать — а могут и не дать. И потом еще сиди работай 4 года, чтобы их забрать в полной мере.
4) RSU штука нестабильная — если акции идут вверх, ты хорошо получаешь. Если акции идут вниз, то ты меньше получаешь. Тут в общем лоттеря.
Как итог: зачем дрочиться, учить велосипеды, надеяться на RSU и левую пятку какого-то менеджера, если можно тупо с рынка получить эту же зп в кеше, что перекрывает любые риски RSU.
Думаю, у Яндекса и подобных компаний сильная специфика, которая приводит к такому процессу.
- У Яндекса много кандидатов.
- Яндекс большой и поражён корпоративной шизофренией.
- Яндекс большой и им нужно много разработчиков.
- У Яндекса много денег, что бы тратить их на субоптимально масштабированные процессы.
- Главное: Яндекс ищет себе не рабочего партнёра, как маленькие фирмы, а чистый workforce.
В сухом остатке: особого пиетета к компании нет, но желание на нее поработать есть. Прагматично, чо.
К слову, я с вами не соглашусь по поводу оценки сложности: это единственный навык полученный в универе, которым я пользуюсь регулярно при написании кода.
Задачки были годные (всего 3 штуки).
В процессе решения узнал новые для себя структуры данных — суффиксное дерево и суффиксный массив.
Когда дошло до собеседования с будущими коллегами начали спрашивать про размер инта, сортировки. Очень удивился таким вопросам после решения достаточно сложных тестовых задач.
В итоге предложили вместо джависта должность автоматчика XD
Впечатления остались смешанные, но в общем получил позитивный опыт.
2 часа веселья с iptables, contrack и, барабанная дробь, алгоритмами на python.
Из 2 часов про сеть было задано ровно 2 вопроса. Остальное прям глубокое-глубокое погружение в недры iptables.
После интервью чувствовал себя как лимон после соковыжималки.
Оффер получил очень странный вида «ЗП столько то, НО ЗАТО МЫ КОМПИНСИРУЕМ ПИТАНИЕ»
Лично знаю людей, не прошедших отбор в Яндекс, которые на порядок круче тех, кто прошел.
Вот список задач на leetcode или полностью совпадающих с приведенными в статье или близких к ним (некоторые залочены):
1) Intersection of two arrays
2) String compression
3) Summary ranges
4) Longest subarray of 1s after deleting one element
5) Number of students doing homework at a given time
6) Group anagrams
7) Merge intervals
8) Line reflection
9) One edit distance
10) Subarray sum equals k
del
count += 1 нужно добавить last_sym = sym. Иначе основное условие никогда не выполнится.
Теперь понятно почему такого качества их решения)
Зачем тратить время на компанию, которая не может в течении 45 минут решить стоит брать спеца на испытательный срок или нет?
Более 1-го собеседования прводят на руководящие должности, а 3+ собеседования-на техдира или около того.
Зачем тратить свое время? Они тратят по часу каждый, а Вы — сумму от каждого такого собеседования. И если бы оно что-то давало, так кроме основ ничего ценного.
Плюс процессы далеко не самые нормальные и оптимальные, о чем и говорит сам процесс найма, да и условия работы в лучшем случае средние или чуть выше средних по рынку.
Ищите нормальные, а лучше хорошие компании с человеческим лицом.
Тем более если Вам хорошо на текущем месте, то зачем тратить энергию в пустоту? Сделайте что-нибудь полезное для своей работы сверхположенного и получите за это премию и/или повышение. Не ведитесь на распиаренные компании. Отличным компаниям пиар не нужен. А лучший вариант, когда к Вам сами придут, поговорят по-человечески и предложат. Остальных отсеивайте. Первые лет 5-6 стоит искать, а потом наоборот-делайте по душе и отлично, и за Вами потянутся. К тому же у Вас замечательная компания)
Статья класс! Спасибо)
Зачем тратить время на компанию, которая не может в течении 45 минут решить стоит брать спеца на испытательный срок или нет?
Ну, мало ли. Может, кто-то себя на помойке нашел чтобы так задрачиваться...
Не малая часть работы заключается в перекладывании джейсонов. То есть те самые однообразные действия при нечеткой постановке задачи. Менеджры в тикетах редко все полностью расписывают.
И квадратичную сложность нельзя случайно нигде сделать. А если кто-то другой сделал, то ее надо на код ревью увидеть и попросить поправить.
Замечу что специально квадратичную сложность делать можно. Задачи разные бывают. Надо это понимать, обкладываться кешами в три слоя, рейт лимитерами и готовить план контролируемой деградации если всего этого не хватит.
Вроде всего этого от вас и хотят на собеседовании. Много однообразных задач. Умение не сделать квадратичную сложность. Потратить даже пару дней, если едете из другого города, чтобы найти себе место работы на несколько лет не выглядит страшным. 0.2% рабочего времени из рассчета трех лет работы.
Суть в том, что вакансий и компаний много и на всех тратить много времени-слишком затратно, равно как и компании тратить много времени на каждого кандидата.
Нужно уметь ценить свое и чужое время и оптимально выстраивать процессы.
45 минут вполне достаточно при диалоге, чтобы решить допускать кандидата на испытательный срок или нет. Далее все определяется в течении 2-6 недель на испытательном сроке. Не стоит пытаться определить все сразу-это просто невозможно, для этого и есть исп срок.
Уже работающие люди будут тратить много больше своего времени чтобы помочь новичку разобраться в том как все устроено. Дешевле потратить 4-5 часов на то чтобы сразу отсеять большую часть. И повысить вероятность прохождения испытательного срока.
Уже давно пушечным мясом не являюсь.
Если ищут кого-то-то пусть они и проходят все этапы.
Если кого-то конкретного, и я им подхожу, то пообщаемся, а там обоюдно определим стоит начать сотрудничество или нет.
И никаких трат времени ни моего, ни компании на многоэтапные и длинные собесы. Просто предложение и диалог. Все.
На все остальное немало желающих, лично в этом я не участвую.
Мое время дорого.
Схема отлично работает именно для вас. Фильтр срабатывает даже до начала процесса собеседований, никто не тратит свое время просто так.
Время HR на масс рассылку предложений поработать не стоит почти ничего. Ваш игнор таких писем тоже. Их игнорируем.
def solve1(A, B):
A = Counter(A)
B = Counter(B)
return [a for a in A if a in B for _ in range(min(A[a], B[a]))]
def solve2(S):
ans = []
start = 0
for end in range(1, len(S) + 1):
if end == len(S) or S[end] != S[start]:
ans.append(S[start])
if end - start > 1:
ans.append(str(end - start))
start = end
return ''.join(ans)
def solve3(A):
S = set(A)
ans = []
while S:
x = next(iter(S))
while x - 1 in S:
x -= 1
y = x
while y in S:
S.remove(y)
y += 1
if y - x == 1:
ans.append(str(x))
else:
ans.append(f"{x}-{y-1}")
return ','.join(ans)
def solve4(A):
ans, curr, prev = 0, 0, 0
for a in A:
if a == 1:
curr += 1
else:
curr, prev = 0, curr
ans = max(ans, curr + prev)
return ans
def solve5(A):
B = []
for a, b in A:
B.append((a, 1))
B.append((b, -1))
ans, c = 0, 0
for x, d in sorted(B):
c += d
ans = max(ans, c)
return ans
def solve6(A):
B = defaultdict(list)
for a in A:
B[''.join(sorted(a))].append(a)
return list(B.values())
def solve7(A):
A.sort()
B = []
for a, b in A:
if B and B[-1][1] >= a:
B[-1][1] = max(B[-1][1], b)
else:
B.append([a, b])
return B
def solve8(A):
I = defaultdict(list)
for x,y in A:
I[x].append(y)
X = list(sorted(I))
cx = (X[-1] + X[0]) / 2
ai, bi = 0, len(X) - 1
while ai < bi:
if cx - X[ai] != X[bi] - cx:
return False
A, B = I[X[ai]], I[X[bi]]
if Counter(A) != Counter(B):
return False
ai += 1
bi -= 1
return True
def solve9(A, B):
if len(A) == len(B):
return sum(a != b for a, b in zip(A, B)) <= 1
if len(A) > len(B):
A, B = B, A
if len(A) + 1 != len(B):
return False
d = 0
for i, a in enumerate(A):
if a != B[i + d]:
if d == 1:
return False
d += 1
return True
def solve10(A, target):
S = {0: -1}
c = 0
for i, a in enumerate(A):
c += a
if c - target in S:
return (S[c - target] + 1, i + 1)
S[c] = i
* Запрещать Counter глупо, если его нет ну можно потратить минуту и написать свой MyCounter с аналогичными возможностями.
* Переменные так называются потому что на интервью стоит экономить время и не думать про названия переменных, ну и после 700+ задач на литкоде мне уже лень думать.
481 комментарий выше моего, на момент написания сего комментария.
Я Солидарен с автором, ибо в у меня был подобный опыт. Рекрутер Яндекса 2 недели ежедневно зомбировала меня пройти их Интервью (с большой буквы), и я сдался, решил попробовать, хотя все друзья убеждали не делать этого. Ска, ШЕСТЬ, ДА ШЕСТЬ разных интервьюеров, почти 10 часов потраченного времени…
И сам подход один а один как у автороа. А его интервью 4… Мне кажется у нас был один и тот же интервьювер.
Как итог, 4 из шести пройдены (исходя из фидбека рекрутера). Но мне всё же рекомендовано пройти половину задачь из letcode ))) И попробовать к ним снова — ХАХАХАХА (Яндекс, напишите алгоритм, какая буква тут лишня)
Да закикайте меня шпалами! Но я солидарен с автором.
Представители Яндекса, скажите, что реально вы получаете от такого процесса? Это просто попытка повторить Гугл? Фейсбук? Так там ещё и про отношение к меньшинствам спрашивают ), а вы нет!
Ни Гугл, ни FB не задал мне на собеседовании ни одного вопроса про меньшинства, так что если такое и есть, то это выброс.
А вы пробовали… Сказать, что уже решали эти задачу? Я тоже сталкивалась с тем, что первый собеседователь спросил то, что должен был второй. Я сказала второму, что это уже спрашивали, и меня просто начали спрашивать обо мне (оффер мне в итоге сделали, но там была другая странная/туппя история, но это же яндекс)
Позиция Senior Consultant — техническая, помогать клиентам с дизайном \ улучшением их AWS Environments.
Телефонный скрининг — нормально, не сложные технические вопросы.
Потом онлайн анкета на 2.5 часа — снова легкие технические вопросы и очень много опросников, связанных скорее с психологией.
Потом домашнее задание на 2 часа — дана архитектураная диаграмма в вакууме — что можно улучшить. Ну хоть что-то интересное, да и одно из «on-site» интервью будет по ней.
Ну и пришло время 5x45 минут собеседований за день:
1) behavioural and leadership — вопросы только такого плана
2) ^^^
3) ^^^
4) 15 минут по архитектуре, потом ^^^
5) смотри #1
Итого из 5ти собеседований на техническую позицию, только 15 минут технического интервью.
Единственный способ пройти такое — это на каждый из 15ти leadership principles написать по ~5 примеров из своего опыта (а учитывая общее кол-во — скорее придумать большую часть).
Ну и как тренд — никакого фидбека, а то вдруг удумаешь их засудить
Хочу заметить по поводу "каждый следующий интервью не знал моего контекста". Немного не так. По результатам каждого этапа интервью пишет отчёт, в котором указывает, что спрашивал, что по его мнению сильно, что слабо. Следующий интервьюер это видит. Ну или должен видеть, по крайней мере. Возможно ваши решения не удовлетворил первого, второй решил перепроверить. Ответ на вопрос, на который на предыдущем этапе ответа не было, это однозначно плюс, значит человек заморочился и узнал для себя что-то новое.
P.S. Был в, привлекался, не разраб, уже нет :)
Тем не менее, хочу сказать несколько слов в защиту Яндекса, уточнив при этом, что не являюсь их сотрудником, и не горю желанием им быть, хотя тоже уже много раз звали на аналогичные должности и зарплаты.
Первое, что хочу сказать, что то, каким будет интервью, решает целиком и полностью работодатель. И если ему важно найти специалиста с конкретными навыками (в данном случае — умением решать сложные алгоритмические задачи), их право устраивать такие испытания, какие они посчитают нужными. Если, конечно, они осознанно это делают, а не потому, что так выдал поисковик по запросу «что спросить на собеседовании».
Многочисленные «одинаковые» собеседования могут действительно показаться избыточными, но если исходить из того, что они действительно хотят подобрать хорошего специалиста, это можно рассматривать как некоторую «диверсификацию» и распределение во времени. Не каждый смог бы выдержать 4х-часовое интервью с такими задачами. В плане разных людей — как раз может быть элементом диверсификации, чтобы получить оценку тебя как кандидата от разных людей в компании.
Ну а насколько им действительно нужны сильные алгоритмисты, им, конечно, виднее. Но предлагаю также взглянуть на ситуацию вообще со стороны как пользователю подобных сервисов. Вот, в Деливери, возможно, гораздо более «правильные» собеседования, но и не стоит удивляться при этом таким случаям, когда ты заказываешь еду за 40 минут до закрытия ресторана, а только через 20 минут уже после закрытия получаешь уведомление «М, извините, мы не успели :( Ресторан уже закрылся.» Все же логистика — не самая простая область.
Насчёт «изобретения велосипедов» тут правда, частично, на стороне Яндекса: насколько я знаю у них свой самописный STL, а также много собственных проектов для внутренней инфраструктуры(к примеру: система контроля версий). Так что им, действительно, нужно много вещей городить для себя
Я бы лучше предложил интервьюеру партейку в шахматы
Вы действительно считаете ценным умение выучить наизусть 10500 типовых комбинаций?
Все шаматы чуть выше любителя и ниже мс (может и они тоже не буду настаивать) сводятся именно к этому.
Все что вы узнаете после партии это уровень вашего противника. Сколько он выучил и какой разрад у него. Ну примерно.
И что вы собираетесь делать с этими знаниями? Как их использовать для найма?
Здесь, безусловно, есть вина собеседующих. Но вряд ли исключительно лишь их вина.
Возьмем учебник по математике советского периода. Давайте даже откатимся подальше назад, к 1930-м или к 1950-м годам. Открываем учебники и видим задачки вида: сколько нужно гвоздей, чтобы построить дом, или, сколько нужно комбайнов, чтобы убрать урожай и т.д. В общем, задачки вполне себе предметные и любой ребенок научившись их решать уже сможет применить знания в работе.
Открываем современные учебники по математике и видим задачки вида: посчитайте количество нулей в сумме натуральных чисел от 1 до 10000, или, посчитайте, сколько круглых числе на диапазоне от 1 до 1000 и т.п.
Я не сомневаюсь, что современные задачи развивают мышление ребёнка, особенно абстрактное, вот только где он применит такие знания? На собеседованиях в Яндексе разве что?!
Я, как бывший Embedded-разработчик подтверждаю — алгоритмы нужны далеко не всем.
Но ругать Яндекс за то, что им — нужны, это правда очень странно.
ТС интересно описал свой путь, респект ему, но, его решения далеки от идеала, ему есть над чем поработать.
Как верно и то, что Яндексу очень сложно набирать сформировавшихся разработчиков, большинство из них знают фреймворки, но не то, как они работают, поэтому основной канал — стажеры.
Я как бы и не писал, что умею в алгоритмы. Субъективно оцениваю себя как алгоритмэна на 3 из 5, вон все решения привёл как есть, с ошибками, чтобы не думали, будто я гений какой. Но мне кажется, 1-2 интервью достаточно, чтобы это понять, да и вообще я немного другие скиллы планировал демонстрировать.
Это как устраиваться шеф-поваром: если попросят нарезать хлеб пару раз, я в принципе не против (хотя хлеб всегда уже нарезанный приезжает), но когда меня просят это сделать раз 10, я открываю хабр.
Много интервью делаются для объективности. У нас в гугле проходят 3-4 алгоритмических интервью, отчеты интервьюверы посылают комитету, который все взвешивает и принимает, по задумке, наиболее объективное решение. Комитет не видел кандидата и не знает ни имени, ни пола, ни возраста. Если какой-то отчет содержит намеки на пристрастность интервьювера, то он выбрасывается из рассмотрения.
Вот и получается, что проводят так много интервью.
Задача — почитать количество единиц в битовом представлении числа. Ну, какбы, пишу я, bin и count. Никакой стандартной библиотеки, никаких импортов, в питоне это считай О(1). Но интервьвера это понятное дело не устроило. Я уточнил, что я конечно могу написать обычный вариант с битовым смещением, но он будет заведомо хуже ибо будет линейным, интервьювер сказал — пишите, именно он мне и нужен. Написал.
На других задачах я так не блистал, потому на тимлида меня не взяли. Но сказали готовы рассмтореть на сеньора. Я ради интереса согласился, и что вы думаете? Снова пачка таких же задач. Не взяли. Предложили мидла или другую команду. Что было бы дальше я проверять, конечно, не стал :)
У меня немного бомбило с задач, с того, что нельзя использовать встроенные классы и методы, вот первая задача с пересечением множеств, мой код с интервью без изменений (и сразу же «определите сложность алгоритма»):
[1, 2, 3]
[4, 2, 1]
[1, 2]
res = list(set(n).intersection(set(m)))
# set(n) + set(m) +
O(n) + O(m) + O(m) = O(n) + 2 * O(m)
[1, 2, 3, 2, 0]
[5, 1, 2, 7, 3, 2]
[1, 2, 2, 3]
from collections import defaultdict
d1 = defaultdict(int)
d2 = defaultdict(int)
for elem in a1:
d1[elem] += 1
for elem in a2:
d2[elem] += 1
result = []
for v2, count2 in d2.items():
count1 = d1.get(v2)
if count1 is None:
continue
for _ in range(min(count1, count2)):
result.append(v2)
Дальше наши интервью уже отличаются. Мне было задано построить бинарное дерево поиска. Но перед этим назвать сложность поиска, если дерево уже отсортировано. Я выдал что-то типа «ну в лучшем случае это O(1) потому что элемент попадётся первым, в худшем мы пройдёмся по всем элементам, поэтому это O(n), а в среднем там какой-то логарифм, сам не помню, как правильно считается». На что последовал ответ «ну вообще-то нет». Я немного опешил и начал визуализировать (тоже код с интервью):
####
n = 15
"""
1 0 1 0 1 0 1 0 # 3 || 8 = 2 ^ 3
1 0 1 0 # 2 || 4 = 2 ^ 2
1 0 # 1 || 2 = 2 ^ 1
1 # 0
"""
elements_in_top_row = (n + 1) // 2
2 ** 3 = elements_in_top_row
2 ** y == elements_in_top_row
y == log2(elements_in_top_row)
#################
На что уже не получил какого-то фидбека, мне сказали строить дерево. Пока я пытался без интернета построить бинарное дерево (в начале интервью было сказано, что гуглить не надо, выполнять код нигде не надо, пишем сразу в этом редакторе), вышло время интервью. Интервьюер быстро попрощался и закончил собеседование.
Так я остался с послевкусием недосказанности, у меня были вопросы, которые я просто задал в пустоту, примерно продублирую их тут:
- Какая сложность алгоритма поиска в отсортированном бинарном дереве? Википедия подсказывает, что
O(log n) - Я не имею ничего против бинарного дерева. Но слёту без гугления я его построить не могу, в работе это пригодилось мне примерно никогда. Почему на вакансию веб бекенд спрашивают такое? Это основная задача? И да, я могу построить бинарное дерево поиска. Но с гуглом. Построю и забуду сразу. Но в работе это реально надо? Как часто обращаясь к апишке вы думаете “хм а они фильтрацию/поиск через бинарное дерево сделали? Или линейно ищут”
P.S. В тексте статьи возникал вопрос, а на того ли направлены задачи, ведь и методичка про C++ говорит (мне такую тоже высылали) и гоняют только по алгоритмам. Если судить по этому посту, всё так и задумано, и это требуется именно от бекенда (ну, либо в Лавке и Маркете совсем разный отбор).
А какой смысл был бы в специальной структуре для поиска, если бы поиск в ней занимал столько же времени, что и поиск в массиве. Ну и построить дерево поиска, даже сбалансированное, довольно просто без всякого интернета. Вот оставлять его сбалансированным при вставке/удалении — это да, уже надо знать.
я человек ответственный, поэтому к интервью не готовлюсь. Это кстати я не шуткую, реально: если вы ответственный человек, ты вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах.
И ещё раз себя:
слёту без гугления я его построить не могу, в работе это пригодилось мне примерно никогда
Я не успел построить, так как у нас оставалось 5-10 минут. Я начал описывать класс Node, но не успел сделать методы добавления (вставка не нужна была, только построить дерево на основе отсортированного массива).
если бы поиск в ней занимал столько же времени, что и поиск в массиве
Я задаюсь вопросом, какая сложность поиска по отсортированному бинарному дереву, если не
O(log(n)) — тот ответ, который я в итоге дал интервьюеру, и который он не принял.Вы выше в комментарии написали, что интервьюеру сказали, что O(n) в худшем случае, т.к. придётся пройтись по всем элементам, а для сбалансированного дерева это неправильно. Про O(log n) вы написали, что посмотрели в Википедии, и это уже правильно.
Я выдал что-то типа «ну в лучшем случае это O(1) потому что элемент попадётся первым, в худшем мы пройдёмся по всем элементам, поэтому это O(n), а в среднем там какой-то логарифм, сам не помню, как правильно считается». На что последовал ответ «ну вообще-то нет»
В худшем случае при поиске в бинарном дереве поиска надо проверить всего O(log n) элементов. Логарифм двоичный.
Собственно, в этом и смысл двоичного дерева поиска — худший случай поиска O(log n). А основная проблема — поддержание инварианта при вставках и удалениях.
Кстати, как вы наверно догадываетесь, есть большая разница между решением, написанным в обычной рабочей атмосфере, и решением, написанным на собеседовании в яндекс.блокнотике с интервьюером на связи и ограничением по времени.
Найс оправдания)
Самое забавное что сам месяц назад проходил в Яндекс собеседование на позицию middle c++. Ни одного вопроса по c++, все алгоритмы и задачи с которыми я справился. На самом последнем собеседовании джавист из Яндекса вообще учил меня shared_ptr писать) в общем я прошел все кейсы, а после общения с тим лидом получил через пару минут отказ. Оказалось что со мной общается внешний рекрутер, которая по цепочке из n людей общается с Яндекс рекрутером и перепутала результаты. В итоге Яндекс звонил мне и извинялся, однако потом сказали что кейсы я все равно провалил из за пары мелких багов в задачах, а мой вопрос "как я дошел до беседы с лидом" так и остался без ответа)
Это какие-то алгодрочеры ))
У меня знакомый работал в яндексе на позиции js разработчика… на собеседование он решал кучу алгоритмических задач… а на работе… рисовал кнопочки…
Спрашивается… яндекс, ну нафига ?)
В моём случае… эта длинная цепочка HR… калапснула… и в результате почти месяц не могли назначить собеседование… Когда наконец-то назначили… собеседующмй меня человек опоздал на 20 минут !
Ну, какбы, пишу я, bin и count. Никакой стандартной библиотеки, никаких импортов, в питоне это считай О(1).Первая ссылка в гугле утверждает, что bin — это конвертация числа в строку с его двоичным представлением. Итого Ваше решение переводит число в строку (под которую надо еще память выделить), и в ней считает количество символов '0'. Надеюсь, не нужно объяснять почему это решение не является ни лучшим, ни эталонным, ни вообще адекватным.
С другой стороны, давать такой вопрос на собеседовании тоже странно, так как это не обычная задачка, к которой можно придумать хорошее решение за пару минут, тут его нужно знать (обычно подразумевается то которое (n & (n-1)), гуглится по «count bits in a number»). Хотя если кандидат напишет перебор бит, то можно проверить понимание битовой арифметики.
P. S. должно было быть ответом на коммент, промахнулся.
Это все что бы ты ценил что тебе дали работу в яндэксе и потом не ныл что тебе мало платят и много переработок, а думал что попал в святое место где решаешь уникальные задачи и вообще теперь ты особенный и это самое главное. :)
p.s.
"после того как компания решила нанять сеньор питон разраба за 200к" — это что сейчас такие рейты в РФ, расскажите кто в курсе?
Процесс ради процесса, наверное, тоже интересно…
Но почему после статьи захотелось уменьшить свой портфель с акциями Yndx
Я в прошлом месяце на js в маркет до финала дошел, но в конце туннеля вдруг выяснилось, что я реактом не владею в бою. Все, две недели "коту под хвост". Но кодинга/алгоритмов было всего 2 "собеседования", плюс одно на софт-скиллы (как я понял), плюс одно с командами (было похоже на ярмарку вакансий, где я больше слушал).
Именно… но вот после написала рекрутер, что "бизнес развивается настолько быстро, что меня без практического реакта никто не готов взять". Я, в принципе, не против, что не подошёл или не понравился, но за две недели мог бы уже лобать что-то, при том, что одна команда вообще внутреннюю срм пишет, в которой "ближайшая важная задача" сделать удобный календарик для выбора дат)
Я очень хотел попасть, чтобы бустануть карьеру. Это при том, что я не js-ник, но много читаю, практического опыта не так много. Я был немного удивлён, что вообще дошёл до финала, но конец все же расстроил.
"Испарился" типа совсем не ответили или что сказали?
Я, кстати, аж прошлым летом (или даже весной в кинопоиск сначала) прошёл самый первый этап, но тогда отказался продолжать, потому что удаленки ещё не было.
Что-то Яндекс отстаёт. Сейчас модно как Амазон — 70 процентов про leadership вопросов задавать. Бомбить от этого можно сколько угодно, но если хочешь работать то приходится учить как проходить собесы
Мне казалось, что зашквар с тестами, задачами, кодингом уже динозавры юзают. Ан, нет. Был повергнут в шок про 5 часов собеседований. Конечно, понимаю, что лучше потратить 5 часов рекрутёра, чем 3 месяца испытательного срока и искать заново. Но камон-хамон! 5 часов Карл! Час, ну край два! Испыталка покажет! Гоу ко мне, ребята! Пишите в личку. Ищу.
Согласен с тем, что много собеседований на алгоритмы — это неправильно.
Не согласен с тем, что сложность в реальной жизни не пригождается. Мне не раз приходилось переделывать места, где кто-то написал квадратичный алгоритм, а потом в специфических условиях всё тормозило и пользователи жаловались. Если бы человек сразу думал, какие максимальные реальные входные данные бывают и какая сложность у того, что он написал, пользователь бы не страдал. Встречается и такое, что n log(n) — медленно, и надо n, но редко.
И отсутствие знания сложности сортировки для меня означает, что подпускать человека к написанию кода, который будет работать на больших данных, рановато.
Я удивлён тому, что для приведённых решений вас не спросили, можно ли быстрее, т.к. есть куда улучшать.
Ну наверно таки да, знать полезно, особенно если в планах большими данными ворочать (хотя для этого я использовал бы какой-нибудь numpy или что-нибудь ещё, написанное на сях, раз уж на то пошло, а меня тут просят оптимизировать на голом питоне). Но в реале я никогда не ловил себя за подсчитываением O(n) после написания функции :) Там скорее чуйка какая-то: я примерно представляю, какие вызовы функций дорогие, я напрягаюсь, если вижу вложенные циклы, ну и прикидываю, как сильно будет грустить БД после моих запросов.
Согласен с тем, что много собеседований на алгоритмы — это неправильно.
Много интервью — это не потому что FAANG так важны алгоритмы, а для объективности.
Несколько разных интервьюверов пишут отчеты, потом (по крайней мере в гугле точно так) целый отдельный комитет по найму рассматривает отчеты и решает. Если кандидат затупил на одном интервью, волновался, а все остальные прошел на отлично — с большой вероятностью его наймут. Если один интервьювер явно офигел от внешнего вида кандидата и предвзято писал отчет, это еще не приговор.
В яндексе явно читали кривой перевод про собесы какогонить фейсбука. Половину не поняли, половину выкинули от лени, а образовавшиеся пустоты заполнили чем умеет их персонал — абстрактными задачами из местного репозитория. И правда, абсурд. В общем, и правда не зря игнорирую рекрутеров якитории ))
вы забыли галочку снять "установить дополнительные вопросы"
Полный провал разведки. Каждый раз сюрприз от несовпадение ожидания с реальностью. Зачем же так? Это же не рога и копыта, о том что ожидать можно узнать заранее из многих источников.
Про то зачем нужны алгоритмические задачки и почему у некоторых компания это работает Гэйл Лакманн Макдауэлл написала целую главу в книге. Посмотрите на досуге.
В это плане Яндекс играет в открытую, по своим правилам. Тут либо соглашаться, либо жаловаться.
Позволю себе добавить и свой вывод из вашей истории.
- У большинства кандидатов на рынке очень слабая база. И тратить столько сил на первоначальную фильтрацию выходит Яндексу дешевле, чем потом разгребать последствия.
c = [elem for elem in a if elem in b]Хуже на данный момент только Озон особенно для Golang разработчиков.А можно подробнее?
А UDP это просто «дыра» в которую может орать любой желающий без предварительного установления соединения.
На задачке про строки немного обосрался(граничные условия, долго их ловил)
Что удивительно — мне дали даже задачку на join табличек, но пока я сидел и размышлял секунд 30 над тем какой join впилить(сначала написал запрос с обычным join, а потом смотрел, что они там хотят вообще), интервьюер сказал что я плохо знаком со скулем:(
Вопрос к Яндексоидам: на вскидку, как много людей устраивается в Яндекс как трамплин на запад?
По LinkedIn тысячи бывших сотрудников Яндекса переехало заграницу. С учетом что большинство людей не может переехать — не могут бросить родителей/друзья тут/патриоты в хорошем смысле слова/не знают английский (самый популярный вариант) — для относительно небольшой компании цифры огромные.
Возможно, компания что-то делает для удержания, есть ли какая-то статегия?
Как потенциальному кандидату такая огромная текучка сотрудников (в том числе ключевых — серьезный red flag.
Возьмем медианный срок работы 5 лет. Скорее всего даже меньше на самом деле, но ладно.
Это нам даст 1.000 уволившихся каждый год.
Определенный процент будет уезжать всегда. Для не самых глупых разработчиков процент уезжающих будет выше чем в среднем по рынку. От тысячи человек в год абсолютные цифры тоже будут заметными.
Рекрутеры FAAGN не зря свой хлеб едят. И людей активно рекрутят.
У Mail.ru Group разработчиков поменьше, но зарубеж укатило в разы меньше % (по linkedin). Про "не самых глупых" — пройти собес на западе это 90% про подготовку: английский, софт-скилы, дизайн, алгоритмы. Если рекрутер фаанга напишет условному senior staff software engineer в Я, то 99% последний откажется по причинам выше (не может бросить родителей/друзья тут/патриот в хорошем смысле слова/не знает английский/...). А скорей всего и не напишет, потому что наш разработчик еще аккаунт не завел на LinkedIn. А зачем? Дачу в подмосковье построил, ипотеку выплатил, дети в школе устроены.
Вопрос именно что Яндекс многие специально используют как трамплин. Кроме опытных ребят, на LinkedIn сотни людей с 1-2 года работы в Яндексе и потом, внезапно, Facebook/Google/etc
У Mail.ru Group разработчиков поменьше, но зарубеж укатило в разы меньше % (по linkedin). Про "не самых глупых" — пройти собес на западе это 90% про подготовку: английский, софт-скилы, дизайн, алгоритмы
Как нас учили на курсе АОД в универе — корреляция не всегда означает казуацию. Например, может быть объясненеи что разрабочтики мейлру на западе просто неинтересны, а вот яндексоидов хантят с удовольствием. Или что мейлрушники все в москве живут (оттуда уезжать меньше причин), а яндекс больше рассеян по стране, и из условной воркуты они с куда большим удовольствием уезжают… Или ещё десятки возможных объяснений, это первые что в голову пришли
Согласен, но я немного про другое. Вы видимо не в курсе как это работает сейчас.
"На западе просто неинтересны" — заведите аккаунт в linkedin, заполните профиль и если у вас есть несколько лет опыта и ключевые слова — вам напишут из всех крупных компаний. При этом вы можете работать в неизвестном стратапе из 10 человек. Яндекс, как и Меил, отстуствуют на западе, о них никто не знает (почти).
Устроиться в крупную компанию — это не про опыт (опыт нужен только чтобы попасть на собеседование), это про подготовку к интервью. Яндекс выглядит как идеальное место для подготовки. Прошаренные рекрутеры по идее знают про это и работа в Я теоретически может упростить попадание на собеседование.
- Amazon (писал человек, даже пообщались, но этот человек был явно хуже ИИ)
- Golden Sacks
Ну, то есть не то, чтобы дофига…
Ну я вот заполнил на линкедине резюме, опыт 8 лет, только автоматический спам на 99% из российских компаний. И нвидия которые кажде 3 дня предлагает мне пойти к ним го или питон разработчиком, при том что у меня раст/C# описаны.
Ну такое.
Устроиться в крупную компанию — это не про опыт (опыт нужен только чтобы попасть на собеседование), это про подготовку к интервью. Яндекс выглядит как идеальное место для подготовки. Прошаренные рекрутеры по идее знают про это и работа в Я теоретически может упростить попадание на собеседование.
Для этого необязательно устраиваться в яндекс — можно порешать задачки на литкоде и пойти внезапно не в яндекс, а в какой-нибудь амазон
На задание даю 10-15 минут (т.к. это — только часть интервью), и из многих десятков кандидатов только пара человек уложились в таймаут и смогли выдать условно рабочее решение. Несправившиеся условно делятся на две группы — первые тонут в трясине хаотичных правок уже написанного кода, вторые начинают писать монстра на десяток (я не шучу) дополнительных вложенных методов и просто не успевают написать ничего вразумительного.
Через 10 минут напоминаю о том, что на задание выделено ограниченное время, иначе не успеем закончить собеседование, ещё через 5 минут останавливаю и прошу устно рассказать чего здесь ещё не хватает для того, чтобы решение заработало. Потом код-ревью с обсуждением плюсов/минусов выбранного подхода.
Этого времени уже достаточно для того, чтобы понять способность человека писать код.
А тут такие простыни кода, что меня прямо в дрожь бросает. Прекрасный способ дать кандидату почувствовать себя ничтожеством.
А как это тормознет умников? В лямбде пишется просто после прочтения FileInfo Progress.Report(p => p+1) и все
А тут такие простыни кода, что меня прямо в дрожь бросает. Прекрасный способ дать кандидату почувствовать себя ничтожеством.
Уже хочу у вас работать
Перед заданием я предупреждаю, что нежелателен уход метода в нирвану на неопределённое время без репорта. А рекурсивное получение всего списка файлов одной командой — верный способ надолго заблокировать поток выполнения. Конечно, после выполнения Directory.GetFiles() вы начнёте репортить о прогрессе, но на реальных системах с миллионами файлов пока вы дойдёте от получения суммарного списка файлов до построчного выяснения их размеров — могут пройти минуты, если не больше.
Кроме того, если я чему и научился на текущем проекте (мы бэкапами занимаемся), так это правилу «ищешь перерасход памяти — ищи подвисший список путей». 9 из 10 OutOfMemoryException — это неудачно сохранённая в памяти коллекция абсолютных путей.
А вы её хотите одним куском получить.
В общем, как я сказал — с виду это простая задачка, но в неё только копни…
А это мы ещё не трогали потенциально возможное зацикливание папок через хардлинки (реальный кейс из продакшена) и другие прелести.
Если говорить о реальных собеседованиях — лишь один кандидат после моего вступления с пожеланиями тут же их проигнорировал и начал писать в одну строку.
Обычно люди намёк понимают.
Ну если умника не тормознёт настолько тонкий намёк, то баллов за тестовое задание он не получит.
Перед заданием я предупреждаю, что нежелателен уход метода в нирвану на неопределённое время без репорта.
Ну окей, если файлов много можно заменить на Directory.EnumerateFiles — оно работает лениво, на 100к файлах отработало без каких-либо проблем, первый файл был зарепорчен через 8мс после выполнения кода.
А это мы ещё не трогали потенциально возможное зацикливание папок через хардлинки (реальный кейс из продакшена) и другие прелести.
Ну это уже будет сложнее, да, но там в принципе сложности с тем "что есть файл". Ну и тут наверное стандартный обходник не подойдет. Но на изначальных условиях да даже с миллионами файлов — проблем нет.
Кроме того, если я чему и научился на текущем проекте (мы бэкапами занимаемся), так это правилу «ищешь перерасход памяти — ищи подвисший список путей». 9 из 10 OutOfMemoryException — это неудачно сохранённая в памяти коллекция абсолютных путей.
Какая-то ваша специфика. У меня например оомов не так много, но почти все из них были вызваны "накапливали логи быстрее чем успевали их записывать". В другой раз в экспрешн случайно попала ссылка на репозиторий хранящий DataContext — в итоге кэши ормки пухли и никогда не очищались. Ну и всякие такие приколы.
Если много файлов то просто не надо получать их все — рецепт в общем-то простой. Если же там хардлинки и все остальное — то тут просто видимо пишется своя библиотечная функция для того же самого, которая работает так как нам нужно, ну и код остается тем же, просто вместо Directory вызываем MySuperDuperHelper.
Я в конце-концов не требую знания библиотечных функций, а просто проверяю способность справляться с хитрыми ситуациями.
Что касается рекурсии — последние лет 20 избегаю рекурсивного алгоритма при обходе дерева файловой системы. Предпочитаю нерекурсивный вариант со стеком.
Так и максимальную глубину вложенности можно ограничить, и сигнатура метода становится гораздо проще — не требуется постоянно передавать накапливаемые параметры на каждом уровне вложенности. И легко превратить такой метод в IEnumerable, навернув внутрь фильтрацию, пакетирование и прочее.
Но такого варианта, увы, пока ни один кандидат не предложил.
Что касается ООМ — несколько кейсов за последние 7 лет было. Почти все связаны именно со списками путей, но тут вы правы — это именно наша специфика.
Человеческих собеседований тут нет.
У меня были задачи на палиндром, что то там про матрицы и т.п.
Я дошел в Яндексе до третьего этапа и решил что это скучный и унылый квест, который никакого отношения к реальности не имеет.
Все же хороший разработчик, это не тот кто умеет складывать в уме матрицы,
а обладает более глубокими прикладными знаниями (к примеру как работает сеть, как устроен unix и т.п.) и имеет большой практический опыт в «нестандартных» задачах в том числе и по масштабированию.
Фреймворки приходят и уходят (даже языки), а алгоритмы- это навсегда. Почти. В общем, нацеленность на алгоритмы вполне понятна, хотя конечно, наверное глупо и невежливо со стороны Яндекса вот так все растягивать. Очевидно, они делают это поскольку у них нет недостатка в желающих там поработать.
Еще добавлю, что в промышленной разработке, в подавляющем случае, кодинг математически и алгоритмически достаточно прост. Это вызывает эффект «забывания», просто хорошие навыки и приемы уходят из фокуса. Это очень плохо, на самом деле, для разработчика, и хорошо если он где-то тренируется/занимается/учится в таком случае, чтобы не терять навыков использования сложных приемов.
Вероятно Яндекс, тем самым, проверяет именно этот параметр, потому что он универсален и нарабатывается длительнее чем освоение языка/фреймворка.
И ты пробегаешься по этим решениям и думаешь, что ты бы точно не хотел работать с людьми которые пишут такой код.
Какой-бы быстрый/оптимизированный он не был — его невозможно читать. Я уверен покажи этот код автору через день он сам уже не разберется.
Когда-то давным-давно, в далёкой-далёкой галактике я и сам проходил такие же собеседования. Один раз даже по каким-то недокументированным возможностям языка меня спрашивали! Но сейчас если первая же задача оторвана от жизни, плюю им в зум и отключаюсь. Жизнь коротка, работы много, пусть сами свои постапокалиптические безбиблиотечные алгоритмы решают.
И ещё просьба к автору — сделайте, пожалуйста, апдейты в статье по итогам комментов от яндекса (а я уверен, что они были!). Потому что комментов уже стотысичмилионав, невозможно объять, а интересно.
Ящитаю, что статья закончилась именно там, где должна была закончиться. Она ведь не про то, как какой-то чувак прошёл/не прошёл в Яндекс и что с ним стало потом, а про доширак (и прочее). Но если вам так интересно, то вот апдейт:
1) Меня завернули после 4 собеседования. Никаких особых комментов, почему, не было — ну типа решал алгоритмы не очень. Даже если фидбек был, он же проходит через тор, и я не знаю, сколько инфы там теряется. Я не верю в теорию заговора и считаю, что действительно решал алгоритмы так себе (да вы и сами всё видели) — особенно после того, как посмотрел ради любопытства видео Яндекса про собеседования и какие критерии там смотрят. Я со своей логикой там вообще не в кассу.
2) После выхода статьи со мной связался Яндекс и предложил стать СЕО и сообщил вот что:
Да ладно, вы правда поверили, что Яндексу не плевать? Никто мне не писал, рекрутер вообще не в теме.
3) Яндекс.Музыка, Почта и другие сервисы у меня ещё работают
Когда длинна собеседований в сумме перевалила мой рабочий день и мне сказали, что готовы меня рассмотреть в другую комманду, но после еще двух интервью, я отказался
В крупных ИТ компаниях (особенно на западном побережье США) именно так и проходит интервью — много задачек (стоит отметить, что задачи сильно интереснее и сложнее) + дизайн и бехев, 4-5 часов подряд в общей сложности, бывает и дольше. Даже тут я статьи такие встречал не раз про подобный опыт и не видел там столько гнева :) Хочешь работать в крупной компании и получать хорошо — будь добр пройди через эти муки.
Естественно, что даже крепкий мидл туда не пойдет. Не говоря уж про сеньоров.
Ну так и приглашайте джунов тогда. Не надо пытаться завлечь человека с позиции сеньора и пытаться прогнать его через «джуновый» алгоритм отбора.
Возможно сениоры сами виноваты что идут зачем-то на собес, хотя на каждом заборе написано "здесь вам не рады, мы нанимаем джунов-мидлов" :shrug:
Потому что нет, не естественно. И идут и миддлы и сеньоры.
На нормальный собес — да. На это — нет.
Потому что на нормальном собесе стороны равноправны. А здесь тебе милость оказывают. Может быть, если прогнешься. А это значит что и работа вся будет построена по этому же принципу. Тебе будут рассказывать как тут круто зарабатывают, но при этом говорить что до этого круто тебе еще расти и расти. А пока изволь рвать попу за то что дают в надежде что когда-нибудь…
В больших ИТ-компаниях нет столько задач: у Амазона всего 3-4 за весь день, у других больше, но не 10+ точно. Так же если есть хотя бы пара лет опыта всегда будет раунд на дизайн систем.
А вообще, код-секции обязательны даже, если сотрудник Яндекса ротируется из одного подразделения компании в другое.
То есть ротация внутри компании будет заблокирована, даже если нанимающая сторона тебя хочет, но ты вдруг «забыл» как решать задачки типа тех, что были у ТС.
Но — им пофиг, это ни на что не влияет, т.к. монопольное положение. Я думаю, завтра половина программистов вообще на работу не выйдет — Яндекс особо не заметит. «Куда ж ты денешься, чык-чырык»
Ну то есть людей, которые при разработке всегда думают об эффективности того, что они разрабатывают, а не о том, чтобы скорее сляпать что-то как-то работающее и спихнуть на прод.
Эластик и любые другие похожие системы нужны для больших данных. Добавьте в любую задачку условие что данных пара терабайт и они не влазят в память. И сразу мапредьюсы с разнообразными базами полезут везде.
И там, где 500 строк кода удовлетворяют всех (и бизнес и сопровождение), никакой эластик нафиг не уперся.
Речь, собственно, об этом — прежде чем искать решение на стороне, стоит оценить его сложность своими силами. И соотнести с затратами все варианты.
А в современных условиях в значительной степени «разработка» сводится к поиску подходящего фреймворка где все уже кто-то сделал. Но это приводит к деградации разработчика и превращение его в «интегратора».
Ребят, если решить несложную задачку на 10 строчек кода для вас — ад, вам просто не надо в Яндекс. Не надо себя мучить.
Я ходил на собесы в эту компанию несколько раз, не потому что прямо очень хотел оффер, а просто было прикольно порешать задачки и понять, где я еще могу подрасти.
Какое же было мое удивление, когда в очередной раз мне его предложили.
a = [1,2,3,2,0]
b = [5,1,2,7,3,2]
res = [r[0] for r in [[y for y in b if y == x] for x in a] if len(r) > 0]
print(res)
O(n^2). Слишком медленно.
У автора там тоже
И автор не прошел интервью
Просто хотел более выразительный
Более выразительный? Это больше похоже на попытку в code golf — где надо решить задачу наименьшим количеством символов. Как этот однострочник более выразителен, чем 2 вложенных цикла — я не понимаю.
Этот код менее читаем, да еще и работает медленнее даже тупого решения с 2 циклами. Потому что выделяет память под копии и не останавливается при нахождении вхождения.
За алгоритмами будущее. Тот кто быстрее будет предоставлять информацию пользователю, тот будет выигрывать всегда
Конечно алгоритмы нужно знать, хотя-бы базовые вещи, как минимум потому-что любой код — Это есть алгоритм.)
Другое дело на сколько что-то показывают институтские задачки, которые используются по факту мало где и без подготовки те специалисты, которые не работают с такими задачами регулярно, просто не справятся.
Такие задачи будут щелкать, студенты которые хорошо учились в вузе и помнят это всё, либо олимпиадники.
Ну можно конечно подготовится на таких задачках, но смысл какой в этом?
Только для того что-бы попасть в Яндекс?
Да, можно, но для этого нужна как минимум очень хорошая мотивация.)
Возможно я хреновый спец., вот за десять лет кодинга, не разу не приходилось считать нотификацию О.
Также напрочь забыл, как например обойти граф и т.д.
Ну хрен его знает, вроде работу выполняю по своей специальности, что-то даже и работает.
Если интересно, работа связанна в отрасле ответственного применения.
Ещё немного добавлю:
Почему-то я всегда теряюсь на интервью, и мне реально сложнее вдвойне что-то писать при интервьювере.
Поэтому идеальное для меня интервью, это тестовое задание перед беседой, можно даже какой-то боевой проект, ну и беседа по тестовому заданию, опыту работы и т.д., думаю этого вполне достаточно, что-бы я показал свой уровень.
Другое дело такое поведения на беседах, как у меня говорит о каких-то качествах, которые скорей-всего не подходят компаниям типо FAANG…
Это просто привел себя как соискателя как пример, в общем решил сейчас искать компании, которые дают тестовые задания + нормальное общение на интервью (Опыт работы, какие проекты и т.д.), остальные даже рассматривать не буду, сразу буду говорить это перед интервью, что-бы не тратить время...)
Ask forgiveness not permission
В рамках кода, что в статье, на больших входных данных эксепшнов ожидается гораздо меньше, чем было бы проверок на наличие предыдущих элеменов. Так что выгоднее с ними, но, вообще говоря, решение само по себе не очень :)
Крутая статья, увидел себя со стороны. У меня последняя, 5-я встреча, тоже состояла из решения алогритмических задач. Дело было до пандемии, этапы с 2 по 5 шли оффлайн. Но все время было ощущение, что собеседование != реальные задачи на работе и такой упор на алогритмы сделан, чтобы как-то можно было отсеять нескольких из большого количества соискателей.
Если честно, после этого думал натренировать алогритмы и ехать, но после прочтения статьи как у них происходит повышение (не помню ссылку) подумал, что мы с Яндексом можем хорошо сосуществовать раздельно.
Но у меня было всего 3 собеседование, из них первое — чисто алгоритмическое, причем часть задач была прямо как в посте.
На втором алгоритмов уже почти не было, кроме одной достаточно сложной(для меня) задачи. В основном, чел полтора часа гонял по джава кору(причем без конченных вопросов), и в конце примерно полчасика поговорили о технологиях на моем текущем проекте, что-то типа архитектурной секции.
На третьем просто общался с руководителями проектов: говорил о своей работе в целом, они рассказали, как устроена работа у них, и что они конкретно делают
Получил оффер, уволился с работы)
чувак! то есть я не один такой? два года назад я прошёл через вот это же вот, потом мне сказали что я плохой, негодный сеньор-программист. и я впал в такую депрессию из которой не могу выйти до сих пор. мне почти 40 лет и это первый раз, после экзамена по термодинамике на втором семестре физкультурного техникума, когда я ощутил себя тупым ничтожеством.
Я вам больше скажу. Не редки ситуации, когда уже сотрудники Яндекса уходят из надоевшего проекта наружу, а не ротируются в другую команду внутри, из-за того, что при ротации (по крайней мере при смене бизнес-юнита) тоже надо пройти почти такой же набор собесов, а они не хотят тратить на это столько сил и/или не уверены, что смогут их успешно пройти.
Так вот, как выяснилось позже — хотя задачи и вполне олипиадные, а некоторые вообще классика преподавания программирования (например, найти правильно ли расставленны скобки в строке) — они каким-то образом являются интеллектуальной собственностью Яндекса и вполне себе чистятся из интернета.
А что именно является интеллектуальной собственностью? Если формулировка задания, то не достаточно ли переформулировать задачу своими словами? И можно ли эту собственность оспорить, если найти соответствующую задачу в каком-нибудь задачнике, откуда её скорее всего взяли?
Ужас, яндекс боиться, что их суппер ситема найма сломается если кто-то прочитает ГДЗ и узнает ответы.
Было 2 процесса найма в лавку на позицию лида. Оба через одну HR — она огонь и в работе и жизни, только замужем: Р Знает своё дело, тактичная и вообще было приятно с ней общаться, не заметил некомпетентности вообще.
1ый процесс — прошёл, оставалось поговорить с руководством (то-ли продукт овнером, то-ли техдиром), завернул сам — контр-оффер.
Было очень простое техническое собеседование, через 15 минут интервьювер сдался. Я сразу обозначил что алгоритмы не люблю и не умею. Потом поговорили о нашем опыте, какие решали проблемы, какие были челленджи (тут я увёл разговор, т.к. сам собеседовал и в курсе как сделать процесс полезным и приятным). 5-10 мин перерыва, заходит сеньёр или техлид и мы на час пропали в разговорах про CQRS/ES/микросервисы/инфраструктуры под это всё. Пожали руки — разошлись.
2ой — Через год или чуть меньше. Вот тут был лютый ад. Я попал на чувака который всё интервью просидел в своём ноуте работая. Посыпались алго задачки, половину решил половину скипнул, и тут ура, практика. Нужно парсить API для обновления товаров, с разбивкой потом на категории и тд (отдельная функция по факту, ближе к бизнес логике приложения-консьюмера, чем к «техническому» сервису-импортёру данных). Есть ручка с курсором, есть ручка GetAll с гигабайтным xml. Я канеш понимаю, бизнес там, партнёры не могут сделать нормально сопряжение или выгрузку, но йопта, 2019 год. Накидал примерно 2 варианта, для 2ух ручек. Вообще предлагал сделать сервис-импортёр который делает слепки этого вражеского API и отдаёт нашим сервисам инфу в удобном для нас виде — не зашло. В итоге понял что нужно юзать GetAll, ибо консистентность (если юзать курсор и пройдёт изменение данных на стороне API — можно пропустить позиции). Интервьюверу не зашло, т.к. производительность хромает и мы будем жечь CPU и место на дисках(у яндекса мало cpu и дисков), хочу курсоры. Я не нашёл чё ответить, т.к. вроде чувак был тим-лид и меня всё это начало утомлять.)В начале он спросил что это за паттерн. Я не ответил. Он сказал скажет позже. В итоге он назвал это MapReduce. Ну натянуть можно, но время закончилось, объяснять что тут есть процессы за рамками MapReduce и по его логике любой ETL можно под MapReduce загонять — не стал, я улыбнулся и пожелал всего наилучшего )
Вроде и практическая задача(УРА), в принципе ничего дурного, но с интервьювером законтачиться я не смог, из-за этого был осадочек. Не знаю почему такое отношение было. Ну и естественно я не ожидал положительного фидбека от него.
HR после интервью не отписала не позвонила, фидбека 0, но и мне уже не интересно было.
Чем закончилась в итоге история с Яндексом? Сделали офер, отказали, отказался?
Да... Есть у HR яндекса некоторые странности...
У меня сложилось впечатление, если честно, что тестовые задачи не на алгоритмы и языки, а на "знание внутренних корпоративных стандартов яндекса методом телепатии".
В принципе - это частая болезнь. Но видел пару раз забавные результаты.
Сегодня проходил собес. Первую задачу решил с грехом пополам, на вторую не осталось времени. Автор статьи в чём-то прав, конечно, но перегибает. Своими алгоритмическими собесами Яндекс отфильтровывает людей умеющих думать, а не только действовать по шаблону. Другое дело, что в реальной жизни это требуется редко. Но, как бы это сформулировать корректно, решать алгоритмические задачи требуется редко, а вот думать - часто. :) У нас в школе висел плакатик - "Математика - это гимнастика ума". Кажется Лобачевский автор, но могу спутать. Тут что-то типа этого. Сейчас нагуглить можно всё. Но, чтобы это правильно применить надо уметь думать. Так что формат собесов Яндекса вполне оправдан ИМХО. Хоть я и, кажется, не прошёл :)
Собеседование в Яндекс: театр абсурда :/