Комментарии 85
О, я первый
Более того, в фаангах, которые эти алгоритмические интервью и придумали далеко не только формы клепают. Там очень много команд, в которых эти самые алгоритмы как раз приходится применять. И динамическое программирование, и всякие структуры данных где очередь с хеш-таблицей переплетены, и математика иногда нужна. Не каждый день, даже не каждый месяц, но без достаточной базы даже не заметишь, что вот тут, оказывается, алгоритм нужен, и вместо наивного решения за 2^N можно написать N log N какой-нибудь.
Я, вот, на интервью справшиваю как раз ту задачку, которую лично в прод коммитил. Абстрогированную и упрощенную, конечно, но все равно она неотличима от литкодовских mid-hard задач.
а можете поделиться? интересно стало
К сожалению нет. Когда задачи утекают, приходится придумывать новые. Редко какую задачу можно ужать до интервью и абстрагировать.
Из других примеров - встречались вот эти задачи: sliding window max, eating bananas
Уже было тысячу раз сказано, но повторюсь. Полагаю, когда вы решаете какую-то задачу вы это делаете не на время и не с "надзирателем за спиной". В результате яндекс выбирает не тех, кто хорошо программирует, а тех, кто "зубрит" алгосы и максимально быстро может достать их из головы.
Пока желающих в яндекс - толпы, велик шанс что среди тех, кто может сортировать названия алгоритмов в голове попадутся великолепные программисты. Но чаще это те, кто целенаправленно "затачивается".
Added: Когда-то давно посмотрел видео парня, который разыгравал сцену подготовки к собесу в фаанг: Долго и усердно готовился, пошел на собес. Его спрашивают:
- Что вы будете делать, если ваш тим лид будет на вас кричать?
- ... Воспользуюсь хэш таблицей.
Занавес.
Полагаю, когда вы решаете какую-то задачу вы это делаете не на время и не с "надзирателем за спиной"
Когда вы водите машину - вы в машине чаще всего один, без инспектора. И ездите вы из дома до работы, а не по вот тому району, где ГАИ проводит экзамен. Но экзамен на ПДД вы сдаете с "надзирателем за спиной", в стрессовой обстановке, где вам дают противоречивые команды.
Интервью - это экзамен. И у него свойства экзамена. Это не тестовое задание, где вы без ограничения времени и надзора делаете задачу в удобной для вас обстановке. Тестовые - хороший вариант для маленьких контор, но для ФААНГов они не подходят. Их очень долго проверять, их долго готовить, там элементарно читерить. И тут на хабре их ненавидят не особо меньше этих алгособесов.
Отличное сравнение. Вот только на машине я езжу каждый день, а деревья я поварачиваю почти никогда. Разве что на литкоде пыль стрехнуть.
Интервью - это экзамен. И у него свойства экзамена
Было бы забавно, если бы практику найма программистов яндекс распространил на, скажем яндекс такси, как вам идея? Будущий таксист должен сдать "экзамен на права". В принципе, они могут себе это позволить.
Большие конторы проводят такие собесы банально потому что поток желающих огромный и нужен какой-то быстрый фильтр.
Есть ли смысл заниматься подготовкой к подобным собесам? Каждый решает сам. Лично я не вижу смысла, ибо за это время я могу выучить намного более полезные вещи, которые принесут больше профита. Но если цель - попасть к "большим дядям", то почему бы и нет.
Вот только на машине я езжу каждый день,
Нет, вы никогда в жизни после экзамена по этому маршруту ездить не будете. И не будете искать место для остановки вот в этом проблемном месте. Вы будете парковаться, где вам удобнее, в том районе, где вам надо. И не будете объезжать вот эти вот конусы. Да, вы водите машину каждый день, но вы делаете более простые действия.
а деревья я поварачиваю почти никогда
В реальной работе вы тоже пишите код. Ровно как на интервью. Вы тоже составляете алгоритм, выбираете как что-то сделать пооптимальнее, кодируете его. Да, задачи у вас попроще, чем разворот дерева, но тут разница как припарковаться где вам удобно и припарковаться в узкое место, куда указал экзаменатор.
В реальной жизни приходится иногда парковаться с зазорами по полметра между передним/задним бампером и соседней машиной в ряду. С обеих сторон, разумеется.
И приходится иногда ездить даже не среди конусов, а сейчас в Москву завезли и разложили по дворам такие бетонные полусферы - как раз такого размера, что если на него наехать, бампер немного согнётся и полусфера под него с лёгкостью проскользнет, а вот в обратном направлении бампер, как раз, разогнётся и зацепится за полусферу. И их еще и не видно нефига.
И списки сортировать и разворачивать тоже приходится.
Стрессовая обстановка на экзамене по вождению куда ближе к средневзвешенной стрессовости вождения, чем стрессовая обстановка на кодинг-интервью — к таковой в типичной работе (если вы только не устраиваетесь тушить пожары). И штраф за ошибку вождения выше во всех смыслах, чем штраф за косяк в программировании.
Более того, на том же экзамене на вождение у вас не спрашивают, например, как работает blind spot monitor, и как его свойства зависят от погоды и наличия дождя, и что такое коэффициент диэлектрической проницаемости — а зря, потому что люди начинают на BSM полагаться и не учитывают его ограничения (особенно если они без физического образования). А штраф за последующие ошибки, опять же, выше, чем штраф оттого, что вы там граф как-то неоптимально обходите.
Стрессовая обстановка на экзамене по вождению куда ближе к средневзвешенной стрессовости вождения
Да ладно. Большая часть претензий на стресс это: Не могу кодировать, когда смотрят из-за плеча. Ровно это и происходит на экзамене по вождению. Экзаменатор. Плюс тоже нельзя тупить и стресс от возможного провала.
на том же экзамене на вождение у вас не спрашивают, например, как работает blind spot monitor,
Если взять теоретическую часть, то аналогия полная. Сколько раз в жизни вы сталкнетесь с ситуацией, где к перекрестку одновременно подъезжает трамвай, автомобиль, мотоцикл и инвалядная коляска на переходе, там не работает светофор и рядом стоит куча знаков с модификаторами. И вам надо решить, кто едит первым за весьма быстро (на экзамене то время ограничено). А экзамен состоит из таких искусственных и накрученных ситуаций почти полностью.
Сколько раз в жизни вы сталкнетесь с ситуацией, где к перекрестку одновременно подъезжает трамвай, автомобиль, мотоцикл и инвалядная коляска на переходе
То, что вы сейчас описали - нормальная ситуация в Марокко (подозреваю, что и в Индии). Только груженого осла забыли упомянуть :)
Раз тут одни автомобильные аналогии, я зачем-то расскажу, как экзамены выглядят здесь.
Во-первых, теоретической части нет. Вообще. Вместо неё есть где-то шесть часов онлайн-курсов, где этак половину времени рассказывают, почему нельзя бухать и текститься за рулём, сопровождая это парой-тройкой подробных историй людей, получивших инвалидность в результате автоаварий, или людей, убивших других в результате наезда, и ещё час — как менять спущенное колесо и как делать jump start.
Теста знаков нет (и на онлайн-курсах их нет, там лейтмотив «разберётесь по ходу дела»). Теста «к перекрёстку подошли автомобиль, коляска, мотоцикл, стрекоза и муравей» нет. Вообще ничего нет. Просто шесть часов у вас на экране крутится видео с проверочными вопросами уровня «с какой стороны у машины руль» и «какой был спидлимит на улице, по которой ехала Дафна, которая текстилась, из-за чего был сбит шестилетний Малькольм».
После прохождения этих курсов вы сдаёте практику, где надо проехать по маршруту, ровно сдать задом метров 10, и параллельно припарковаться. Есть места, где практика сдаётся так: вы платите, скажем, 100 баксов за «подготовку», и в процессе этой подготовки тот же чувак, что будет принимать у вас экзамен, ездит с вами по экзаменационному маршруту (тихий райончик субурбии, где ничего интересного нет) дважды, и рассказывает, куда смотреть, куда когда поворачивать на данном конкретном перекрёстке, и так далее. Параллельная парковка тоже в специальном месте, с достаточно широкими допусками по тому, как далеко вы можете оказаться от бордюра и конусов, символизирующих машины спереди и сзади (и практиковаться на этом месте вы можете хоть весь день перед сдачей).
Ночного вождения нет вообще. Проверки езды по извилистой холмистой дороге в дождь со спидлимитом в 60 миль в час без разделительной полосы нет вообще (и когда я впервые ехал по такой дороге, у меня стресса было чутка побольше, чем под взглядом экзаменатора). Езды по шоссе, собственно, тоже нет.
Во-первых, теоретической части нет. Вообще....
Спасибо за антирекламу "там"!
Отсутствие теоретической части меня вот вообще не смущает (зачем она нужна? хороший экзамен её проверяет на практике). Меня смущает «подготовка» за эти условные 100 баксов.
А так какой-то существенной зависимости отсутствия теории и количества смертей на дорогах на миллион километров нет. Куда больше зависимость от алкоголя, использования ремней безопасности и урбанизации региона.
Отсутствие теоретической части меня вот вообще не смущает (зачем она нужна? хороший экзамен её проверяет на практике)
Например здесь около 60 вопросов. Было бы хорошо, чтобы устный экзамен проверял их все. На практике же это просто нереально.
Меня смущает «подготовка» за эти условные 100 баксов
Это не подготовка, это совковая показуха.
А так какой-то существенной зависимости отсутствия теории и количества смертей на дорогах на миллион километров нет
Ваше утверждение практически эквивалентно тому, что ПДД не нужны.
Ниже был комментарий по строгость экзаменов в Швеции. Следствие - в ней в 4 раза ниже смертность при авариях, чем в США.
Куда больше зависимость от алкоголя, использования ремней безопасности и урбанизации региона
Это дальние последствия отсутствия подхода "разбитых окон". Жизню не обманеш.
UPD
Например здесь около 60 вопросов. Было бы хорошо, чтобы устный экзамен проверял их все. На практике же это просто нереально.
И сразу же первым вопросом
Что означает термин «Ограниченная видимость»?
с вариантами, среди прочего,
Видимость водителем дороги менее 300 м в условиях тумана, дождя, снегопада, а также в сумерки.
Видимость водителем дороги менее 150 м в ночное время.
Как измеримо отличается водитель, который знает, что там бюрократ имел в виду в данном конкретном случае? На что знание ответа на этот вопрос влияет на практике?
Ваше утверждение практически эквивалентно тому, что ПДД не нужны.
Моё утверждение — мастурбация на формализм не нужна.
Ниже был комментарий по строгость экзаменов в Швеции. Следствие - в ней в 4 раза ниже смертность при авариях, чем в США.
А если делить не на население (что не учитывает паттерны движения и уровень использования авто), а на проезжаемое расстояние (per 1 billion km, что, впрочем, тоже идиотизм, хоть и меньший, потому что в эту метрику с одинаковым весом попадают как шведские пассажиры автобусов, которые подавляющую часть своих биллионов проезжают на этом автобусе, так и полулегальные американские дальнобои, которые нарушают все возможные нормы труда и овертаймят как не в себя), то разница окажется уже в два раза, а не в четыре. При этом в какой-нибудь Франции смертность лишь немного ниже, а в Бельгии — даже выше, хотя гугловский AI overview говорит
In Belgium, obtaining a driving license involves passing both a theory and a practical exam. The theory test is a computer-based multiple-choice exam with 50 questions, requiring a minimum score of 41 to pass.
Это дальние последствия отсутствия подхода "разбитых окон". Жизню не обманеш.
Ну да, если начать требовать теорию на экзамене, который сдают лет в 16-18, то люди в 20-30 сразу перестанут пытаться ехать из даунтауна к себе в субурбию после чекушки-другой.
И сразу же первым вопросом
Что означает термин «Ограниченная видимость»?
Видимость бывает нормальной, ограниченной или недостаточной.
Ограниченная видимость подразумевает, что есть объект (другая машина, дерево, дом и так далее) или особенность рельефа, из-за которых дорога не просматривается полностью. Например, трасса впереди круто поворачивает или машина приближается к верхней точке подъёма, за которым дорога идёт вниз. Водитель физически не может заглянуть за угол или за возвышенность.
Недостаточная видимость связана с погодными условиями и временем суток. Дорогу хуже видно в сумерках, ночью, а также во время дождя, тумана, снега или града. Правила говорят о том, что недостаточной считается видимость, не превышающая 300 метров.
Если перечисленные факторы отсутствуют, видимость считается нормальной.
Как измеримо отличается водитель, который знает, что там бюрократ имел в виду в данном конкретном случае?
Так для этого не надо прогуливать занятия по теории и практике ПДД.
На что знание ответа на этот вопрос влияет на практике?
Вы страшный человек. Вам ни в коем случае нельзя работать капитаном корабля или самолета!
Моё утверждение — мастурбация на формализм не нужна
Нет, вам надо работать учителем в школе - 90% учеников будут просто в восторге (привет финский подход!). Вот только ВПР/ОГЭ/ЕГЭ они провалят. Упс...
При этом в какой-нибудь Франции смертность лишь немного ниже, а в Бельгии — даже выше
Кроме знания ПДД,,на их выполнение большое влияние оказывает степень наказания за их нарушение. Задайте AI Overview два этих отдельных вопроса и увидите результат.
Ну да, если начать требовать теорию на экзамене, который сдают лет в 16-18, то люди в 20-30 сразу перестанут пытаться ехать из даунтауна к себе в субурбию после чекушки-другой
Я не пойму, вы хотите продвигать в обществе подход "чем больше выдадим премий Дарвина, тем лучше"? Так, что там вам нравится, Штаты, Техас? Ни ногой туда!
Видимость бывает нормальной, ограниченной или недостаточной.
Очень здорово. Как это помогает водить машину?
Это как учиться говорить на английском, зазубривая все прошедшие времена, и какая форма first/second/third conditional соответствует какой семантике (я второе десятилетие живу в англоязычных странах, и при этом сам это не вспомню, даже если когда-то знал, что нисколько не мешает), и потом их мучительно вспоминая, что надо использовать в данный момент беседы (а когда вы вспомнили, беседа уже ускакала вперёд — успехов вам так поддерживать разговор). И ещё обязательно ставить язычок на бугорки, когда произносишь th.
Нет, серьёзно, ожидается, что у водителя есть лазерный дальномер в глазах, и он может отличить видимость в 299 метров от видимости в 301 метр? Что это вообще значит — я не могу различить контуры за 300 метров? Или не могу распознать объект быстрее, чем за n секунд? Через 300 метров не видно дальний свет встречной машины? Или что? Хотите бюрократии и формализма — получайте до конца, а то уже тут какие-то фрактальные потёмкинские деревни, когда некоторый вид наукообразия мы сделали, но он не даёт ничего, кроме чувства важности составляющему экзамен.
Так для этого не надо прогуливать занятия по теории и практике ПДД.
Вы на какой вопрос здесь отвечали, и как он связан с тем, что спросил я?
Вы страшный человек. Вам ни в коем случае нельзя работать капитаном корабля или самолета!
А жаль, на каком-нибудь F/A-18 я бы полетал вживую (и на цэшке раньше много летал в DCS).
Но, впрочем, вы на вопрос можете ответить без гибрида апелляции к авторитету и гало-эффекту?
Нет, вам надо работать учителем в школе - 90% учеников будут просто в восторге (привет финский подход!). Вот только ВПР/ОГЭ/ЕГЭ они провалят.
Слышали полубайку про Фейнмана и то ли французский, то ли бразильский подход к обучению физике? Формулы оттараторить могут, а применить их к реальным задачам — нихрена. Зато их версии ЕГЭ сдают на отлично, я уверен.
Кроме знания ПДД,,на их выполнение большое влияние оказывает степень наказания за их нарушение.
То есть, вы хотите сказать, что, выходит, есть какие-то другие факторы, кроме наличия теоретической части экзамена? Или это выходит, только когда другие страны сравнимы с (или хуже) США по смертности на дорогах, а когда другие страны не хуже, то тогда и только тогда всё дело в теории?
Я не пойму, вы хотите продвигать в обществе подход "чем больше выдадим премий Дарвина, тем лучше"?
Я продвигаю подход «не надо делать абы что просто ради создания иллюзии действия» (с тем же успехом можно помолиться, в конце концов), но ваш вариант тоже интересный.
Так, что там вам нравится, Штаты, Техас? Ни ногой туда!
Здесь согласен, ЕВПОЧЯ.
А здесь - это где?
А в Швеции наоборот, еще и заставляют проехать по льду на скорости (или по разлитому маслу летом), уворачиваться от симулируемого лося, выходить из заноса.
Забавно, что экзамен по вождению-то (по крайней мере в РФ) давно превратился в формальность, исход которой определяется с точностью 99.9% фактом оплаты, а не навыками вождения.
Я как-то переизобрёл алгоритм Кнута-Морисса-Пратта. Я был молод, и просто не знал, что такой алгоритм есть и как он называется. Пришлось самому изобрести :)
Но всё-таки, это то, что требует нескольких дней раздумий, а не нескольких минут.
Мне кажется, тут (в заголовке статьи, по крайней мере) в очередной раз недоопределённое утверждение, и разные люди отстаивают разные его уточнения.
Алгоритмы программисту нужны на уровне «ну эээ сортировать вот std::sort, а если нужно сохранять порядок эквивалентных элементов — std::stable_sort», или «могу строго доказать оценку средней сложности квиксорта»?
«Нуу эээ тут надо рандомно переставить элементы, пойду возьму std::random_shuffle», или «знаю и могу доказать корректность алгоритма Фишера-Йейтса, и заодно знаю, как его ускорить папирами Дэниела Лемира от 2019-го года об избегании деления в генерации случайных чисел и его же папира от 2024-го года о batch-генерации случайных чисел»?
«Могу, если попыхтеть, написать с третьей попытки редакторское расстояние через динпрог» или «могу выписать уравнение Беллмана и доказать его свойства»?
Первое, конечно, нужно, но первое осваивается за месяц работы средней интенсивности. Второе не нужно почти никому даже в гугле.
Ну вот допустим, у меня была такая задача.
Есть поток сетевых пакетов (интенсивность которого от меня мало зависит). Некоторую долю этих пакетов (скажем, 20-25%) надо посылать особым образом. И хотелось бы, чтобы они, эти особые пакеты, были более-менее равномерно распределены в общем потоке (а не, "посылаем все особые пакеты, потом все не-особые до 100").
Это первый вариант в вашей классификации или второй?
Это вообще задача на уточнение требований. Как распределена эта доля пакетов? Какие ограничения по памяти, по процу и по латентности? Всякое такое вот.
Какие из требований вам не понятны?
Еще раз. Есть поток пакетов. Я (мой код) нахожусь в позиции, когда пакеты ко мне пост упают, я их отправляю. Задерживать пакеты без нужды крайне нежелательно.
Некоторую долю пакетов надо отправить особым образом (ну, условно, привязать к ним бантик; сама по себе операция привязывания бантика недорогая, копию пакета делать не обязательно). Какая именно доля отправляется таким образом - это медленно и нечасто меняющийся параметр (точность его соблюдения, если он меняется, не важна, но надо его соблюдать, когда он устаканился).
Требуется, чтобы (1) доля пакетов с бантиком в общем потоке соответствовала установленному параметры (2) пакеты с бантиком были равномерно распределены среди всего потока.
Колхозник написал бы функцию у которой на выходе bool, на входе float, внутри магия random. А как делают дачники?
random может сложить всё в кучку.
не знаю, как это делают дачники. Я приладил Алгоритм Брезенхэма
Вообще эта задача напомнила мне QoS в цисках. Так что я бы заглянул в книжку (она у меня есть но я туда лет пятнадцать не заглядывал) и выбрал бы что-нибудь на тему WFQ (там вариантов немало) и загуглил остальное. ЕМНИП, все эти алгоритмы тоже работают на основе подсчета дефицита, как и брезенхамовский,
Какие из требований вам не понятны?
Мне было непонятно следующее, например:
Пакеты маркируются согласно их свойствам, или согласно внешнему относительно них состоянию системы? Иными словами, маркер пакета — это функция от пакета («обнаружили пакет со словом "счастье" в потоке — модифицировали отправку, и анализ показал, что таких пакетов примерно четверть»), или на пакеты можно не смотреть («каждый четвертый пакет заодно имеет флаг heartbeat»)?
Особенно в первом случае (и в некоторых интерпретациях второго) — как конкретно распределены эти пакеты? Бывает ли, что сначала вам на вход идёт N особых пакетов, а потом все неособые, и вам их надо перемешать?
Остаток вашего комментария говорит, что, похоже, от содержимого пакетов это не зависит. Правда, тогда я не понимаю, чем плохо что-то вроде (извините за долгий комментарий, отвлёкся на тестирование):
class Marker {
std::vector<bool> marks_;
size_t counter_ = 0;
public:
void setShare(rational α) {
// заполнить marks_ и обновить counter_ согласно коду, который мне лень переводить на C++
}
auto handlePacket(packet& packet) {
if (marks_[counter++]) {
packet.mark();
}
if (counter_ == marks_.size()) {
counter_ = 0;
}
}
};где код, который мне лень переводить на C++ —
data Mark = I | O deriving (Eq, Show)
marks :: Ratio Int -> [Mark]
marks ratio
| k == n = replicate n I
| otherwise = go 0 0 []
where
(k, n) = (numerator ratio, denominator ratio)
target = fromIntegral k / fromIntegral n
go marked total acc
| total == n = acc
| otherwise = let shouldMark = total > 0 && fromIntegral marked / fromIntegral total < target
in go (marked + fromEnum shouldMark) (total + 1) ((if shouldMark then I else O) : acc)вроде норм работает и выглядит равномерно:
λ> marks (2 % 3)
[I,I,O]
λ> marks (1 % 3)
[O,I,O]
λ> marks (2 % 5)
[O,I,O,I,O]
λ> marks (1 % 5)
[O,O,O,I,O]
λ> marks (3 % 5)
[I,O,I,I,O]
λ> marks (11 % 12)
[I,I,I,I,I,I,I,I,I,I,I,O]
λ> marks (5 % 12)
[O,I,O,I,O,O,I,O,I,O,I,O]
λ> marks (79 % 100)
[I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,I,O,I,I,I,I,O]И тесты проходит
newtype ProperFraction = ProperFraction (Ratio Int) deriving Show
instance Arbitrary ProperFraction where
arbitrary = ProperFraction <$> do
Positive denom <- arbitrary
num <- choose (0, denom - 1)
pure $ num % denom
prop_marksLengthAndCount :: ProperFraction -> Property
prop_marksLengthAndCount (ProperFraction α) =
let result = marks α
in length result === denominator α .&&. length (filter (== I) result) === numerator αλ> quickCheckWith stdArgs { maxSuccess = 10000 } prop_marksLengthAndCount
+++ OK, passed 10000 tests.Можно ещё, наверное, как-то равномерность сформулировать и протестировать (типа, наидлиннейшая серия отличается от наикоротчайшей не более, чем на такое-то число), но мне неохота выводить соответствующие утверждения, потому что я ненавижу числа.
И ещё тут моя профдеформация, когда проще максимально тупо и читаемо предрассчитать всё, что нужно, и на горячий цикл оставить минимальное количество работы. И если вам нужна полупроцентная точность, то это максимум съест где-то 20 кэшлайнов, если достаточно процентной (и вы готовы не отличать 98 и 99%), то в худшем случае она съест 5 кэшлайнов, а если сделать чуть умнее, то уложитесь в три в самом худшем случае. Кстати, разница между std::vector<bool> и std::vector<uint8_t> обсуждаема и тоже вопрос трейдоффов.
Ещё круче было бы, конечно, ограничить спектр возможных параметров в компилтайме и передавать туда std::ratio и вычислять всё в constexpr, чтобы и в рантайме аллокаций не было, и компилятор мог всё по максимуму соптимизировать, но это вопрос со звёздочкой.
Первое, конечно, нужно, но первое осваивается за месяц работы средней интенсивности. Второе не нужно почти никому даже в гугле.
И на интервью спрашивают в основном именно первое. Не просят реализовать AVL деревья, а просят придумать, как применить std::set.
На мой взгляд знание алгоритмов на уровне решения литкодовсих задач переоценено, я работал в команде по разработке движка СУБД, там алгоритмы на алгоритмах были и если человек закончил честно ВУЗ, имеет базовую вузовскую подготовку он разберется в любых алгоритмических задачах, это просто вопрос времени, а вот умение писать качественный код, выбирать правильную архитектуру, делать грамотную обработку ошибок, аккуратность, это свосем другой скилл, который куда важнее знания алгоритмов.
Я, вот, на интервью справшиваю как раз ту задачку, которую лично в прод коммитил. Абстрогированную и упрощенную, конечно, но все равно она неотличима от литкодовских mid-hard задач.
Если кандидат ее не решил за интервью, это же вообще ни о чем не говорит, он вполне может решить ее за день за два, с точки зрения релизного цикла это вообще ни о чем, но с другой стороны безусловно нужно как то оценивать кандидатов, со своей стороны раньше давали тестовое задание небольшое, где можно понять как человек программирует и думает и на собеседование развивать тему тестового задания, тоже не панацея безусловно.
Если кандидат ее не решил за интервью, это же вообще ни о чем не говорит, он вполне может решить ее за день за два
Это было лишь к тому, что задачи даются вполне реалистичные, что умение их решать пригодится в работе. А не к тому, что я по себе меряю.
Потом, не обязательно за время интервью задачу решить и необязательно даже самостоятельно. Если кандидат хоть какие-то здравые рассуждения о задаче высказывает, но не придумывает решение, я подсказываю. И даже получив очень сильные подсказки (описывающие все основные идеи почти полностью), можно интервью пройти на hire. И не обязательно все решение за интервью закодить. Главное его объяснить, чтоб я понял, что кандидат придумал и хотя бы 10-15 строк осмысленного кода, похожего на реализацию этой идеи из себя выдавить.
вот, на интервью справшиваю как раз ту задачку, которую лично в прод коммитил
Осуждаю. Даже если ты решил ее за то время которое ты даёшь на интервью, считая себя неким эталоном, то у тебя есть одно неоспоримое преимущество - контекст. Когда ты долго работаешь над какой-то проблемой, мозг уже прогрет и так или иначе обдумывал какие-то решения. А иногда и само окружение наводит на то как это решать. А взять вот так человека с улицы, который до этого занимался чем-то другим и просить его решать свои проблемы в проде, которые у тебя каждый день перед глазами - ну такое себе.
Во-первых, задача абстрагирована и никакого контекста там нет. Просто есть данные с ними что-то надо сделать. Больше нигде в коде это делать не надо. Даже чего-то похожего нет.
Потом, это было к тому, что задачи даются реалистичные, навык решения которых нужен в реальной работе. По себе не меряю, но сложность задачи откалибрована под интервью: куча деталей убраны.
Плюс, я подсказываю и не требую идеального оптимального решения за интервью. Хоть что-то умнее плоного перебора, даже с подсказками, придумайте за пол часа, да закодте 10-15 сток кода за оставшиеся 10 минут по делу и это будет Hire от меня.
Давайте опять в аналогию с музыкантами. Когда вы приходите играть в оркестр - надо как-то проверить, что вы соответствуете принятому уровню. Первый метод совсем никуда не годится: тесты. Это как если бы мы устроили пришедшему скрипачу допрос: из какого материала выполняется дека скрипки: бук, липа, ясень ? Понятно что это вообще никак не коррелирует со способностью человека играть - зато имитация бурной деятельности...
Второй способ уже лучше - надо бы попросить человека сыграть. А чтобы не заморачиваться и иметь возможность объективно сравнить кандидатов - пусть все играют этюды Черни! Причем, на память: ты братец, сыграй N3 из op. 139, а ты - 7 и 120 из op. 261! Хер же с ним, что оркестр никогда не играет на концертах эти этюды. Это же база - в музыкальной школе их все играли! Не помнишь на память этюды ?! А что ж ты в оркестр пришел устраиваться - поди повтори, подучи... В принципе, такое может сработать, если вы очень-очень известный оркестр, или кандидат почему-то очень хочет у вас работать. Правда может оказаться что ничего кроме этюдов он в жизни не играл (к этому его готовила семья и школа) - и вы будете с ним долго и упорно мучаться...
Наиболее правильным является третий вариант - попросить человека сыграть фрагмент того, что он знает! Или просто пригласить на репетицию и посадить в группу играть. Там сразу станет понятно есть ли слух, есть ли беглость пальцев и чувство ритма...
В общем - алгоритмы знать безусловно полезно. Но играть в летиткод на собеседовании - имхо дурость. Это реально проверяет только достаточно ли дури у кандидата бросить все чтобы готовиться к вашему собеседованию. Да просто дать на ревью кусок кода и попросить предложить исправления - уже в разы лучше!
Программисты не любят, когда им предлагают сыграть на собеседовании.
С другой стороны, для музыканта сыграть - это 15 минут подудеть и пару часов подготовиться, по желанию. А осмысленное тестовое задание для программиста, это, всё же, дни, а не часы.
Всегда можно найти задачу из своей области, чтобы за 30-40 минут посмотреть что человек реально умеет!.. Более того - меня на сегодняшний момент даже больше интересует насколько человек может с листа ЧИТАТЬ и ПОНИМАТЬ написанный код и расширять его. Ну не пишем мы больше систем с нуля. Лет 15 минимум уже не пишем...
Ну не пишем мы больше систем с нуля. Лет 15 минимум уже не пишем...
Кто "мы"?
Всегда можно найти задачу из своей области, чтобы за 30-40 минут посмотреть что человек реально умеет!
Это гораздо сложнее, чем вы думаете. Потому что задачи из своей области - это "есть вот эта кодовая база, там 30 компонентов, которые как-то взаимодействуют, надо запилить вот такую вот фичу". Вы кандидату это будете час только объяснять, а кандидат еще час будет кодовую базу раскуривать. Потом уже будет 30-40 минут, да. Если же вы эту задачу начнете абстрагировать от деталей и упрощать, чтоб ее можно было хотя бы за 5 минут объяснить - у вас получаются задачки с литкода. Чаще всего easy, почти без алгоритмов и структур данных. И, если у вас поток кандидатов 1000 на одно место, то вам придется задачки усложнять. Тупо увеличивать объем broiler plate кода - это не усложнение. Хотя, можно, конечно, и по скорости печати кандидатов отсеивать, но алгоритмы, которые проверяют способность думать, тут подходят гораздо лучше (если не давать одни и те же баянистые задачи, конечно. Тогда действительно можно случайно проверять способность зубрить).
Конечно, если у вас мелкая контора и вы пол года закрыть вакансию не можете, то возможно вам будет достаточно и Fizz Buzz. А тестовое задание или "поговорить по душам" будет лучше алго-собесов.
Вы кандидату это будете час только объяснять, а кандидат еще час будет кодовую базу раскуривать.
Час - это совсем оптимистично, по факту намного дольше
Ну нет же! Всегда есть задача на часок - просто надо посмотреть и повспоминать. У вас в памяти откладываются эпические проблемы - где час только объяснять обстановку, но для собеседования это не нужно.
Одна из задач, которую я давал кандидатам - есть весы с экраном на 16 знако-мест. Есть название из карточки товара которое может быть любой разумной длины. Нужно показать название товара на экране. В отличие от летиткода - тут нет единственно правильного решения. Хочешь написать эвристики и сокращать слова - вперед! Хочешь реализовать бегущую строку - супер! Придумал еще что-то - молодец: вот тебе метод writeScreen(msg) - реализуй свою идею. А дальше - это уже моя работа: смотреть как именно человек пишет, как он это собирается тестировать (и будет ли вообще) - в общем понимать, можем мы с таким играть в окестре или нет... Потом еще можно поговорить - как мы это будем модифицировать если у нас появятся вторые весы с экраном 32 знако-места ? А если третьи, где тоже 32 знако-места но в две строки ?... И в моем случае - это работало. Единственный недостаток - невозможно провести 4-5 таких собеседований в день. Для массового подбора такое не работает.
есть весы с экраном на 16 знако-мест. Есть название из карточки товара которое может быть любой разумной длины
Неиссякаемый источник забавностей ;) Какие правила не придумывай - все равно получится
Вы сейчас подтвердили мои слова в точности. Эта ваша задача это именно " Если же вы эту задачу начнете абстрагировать от деталей и упрощать, чтоб ее можно было хотя бы за 5 минут объяснить - у вас получаются задачки с литкода ".
В отличие от летиткода
Эту задачу чуть формализовать и хоть сейчас на литкод добавляй - она там как родная будет.
Задач такой сложности на литкоде полно: 1 2. Еще нагуглилость парочка почти таких, но они платные. Только тут еще сверху неточность формулировки задачи навешана.
Имхо нет. Понятно что леткод можно растянуть до бесконечности. Однако те задачи которые там наиболее часто встречаются - это чисто знание конкретных алгоритмов: переверните дерево, найдите сумму уникальных подмассивов длинной N, посчитайте кратчайший путь в матрице, и т.д... Оно мне напоминает какую-нибудь районную олимпиаду по программированию в 90-х...
Я даю инженерную задачу: ограничения простые, решение принимается любое. Меня интересует не результат (знает или не знает человек алгоритмы), а процесс - как именно он применяет ИТ к решению этой задачи. Ну и дальше есть общая тема "поговорить"...
Ну я же вам привел задачи в пример. Там нет никаких алгоритмов на графах и деревъях. И даже всякие трюки с массивами не используются. Чисто инжинерные задачи отформатировать текст.
Меня интересует не результат (знает или не знает человек алгоритмы), а процесс
Меня тоже. Если человек рассуждает по делу, имеет хоть какие-то логичные идеи, и хотя бы с подсказками придумывает что-то умнее полного перебора - это Hire от меня.
В моей области вечно слишком много контекста. А если его отфильтровать, то и задачки получаются игрушечные, не напоминающие настоящие.
А мне нравится играть на собеседовании. Особенно когда там собеседуешься в какое-нибудь hft, опять же, а тебя там человек просит написать свой std::any или std::function (классика задач в hft) — можно заодно обсудить, как это писать, оценить уровень собеседующего, что у них принято в команде, и вообще весело провести время.
В случае достаточно опытных программистов часто можно «сходить на концерт с их участием» или на «сольное выступление в сквере для души». А вот просить пианиста: «А давай ты нам тут 'Мурку' на баяне сбацаешь», это очень странно.
То есть посмотрите их прошлые проекты. А может, пет-проекты человек покажет. Пусть объяснит, что там сделано и как именно сделано... Если джун, то да, можно проверить уровень элементарными короткими задачами (типа, если мальчик/девочка/оно не определилось пока перед незнакомыми дядями и тетямию не описался и вспомнил не только сортировку пузырьком, то можно попробовать взять его к себе).
буквально в прошлую пятницу у меня жена - оркестровый музыкант с 30-летним стажем завалила конкурс просто из-за того, что перенервничала. Почему? Потому что средний музыкант оркестра соло не играет, только единичные солисты на должности концертмейстеров, и навык это делать теряется от долгой работы, соответственно, мандраж, стресс, чисто моторика, мозгами ей не прикажешь. Это абсолютно разный уровень и разный навык - сыграть соло и сыграть в оркестре, и далеко не все играющие соло, хорошие оркестровые музыканты. Чтобы играть соло. надо постоянно обыгрываться сольно - а у оркестрового музыканта такой возможности просто нет. Все это понимают, но тут как в тендере - должен быть конкурс, и все. И вот стоит жена после своего провала и слушает, как слабенько, но уверенно, играют конкурентки-новенхонькие выпускницы консерваторий, у которых один только навык лучше, чем у нее - обыгранность - и вспоминает анекдот про "сердцем чувствую, литр, а доказать не могу". Причем все вокруг знают, что она хороший музыкант, но возьмут того, кто на конкурсе сыграет, и будут потом обучать играть в оркестре, и на тот же уровень девочка выйдет через энное количество лет.
Точно так же и тут. Ты можешь нарешать тонны живых бизнес-задач на практике, но котироваться будет насколько легко и быстро ты на память применяешь абстрактные алгоритмы к абстрактным задачам с листа, хотя такой навык почти никогда не требуется, кроме как на олимпиадах по информатике
Зачем программисту алгоритмы?
А что мы вообще? Давайте, конкретно!
Понятно, что независимо от того, знаете ли вы стандартный набор алгоритмов либо не знаете, на работе либо в собственных проектах, могут возникнуть «задачи, которые еще не знала математика», в данном случае программирование. Ну, или знало, но мы не знаем, где это знание найти.
Рассмотрим простейшую задачу. Допустим, нам надо максимально точно распознать речь из оригинального иностранного видео, язык которого мы не знаем. Сделать все надо «за бесплатно», т.е., мы ничего не можем заплатить другим (например, профессионалам) и нам за эту работу никто не заплатит. Используем только доступные инструменты (вроде, бесплатных онлайн-сервисов) и Интернет, который у нас уже есть.
Какой тут можно предложить алгоритм?
Например, мы берем десяток доступных популярных онлайн-сервисов и делаем там распознавание звукового файла видео. Получаем десять вариантов текста, которые, хотя бы на несколько процентов, отличаются между собой. Как из них получить обобщенный и наиболее точный вариант?
В принципе, можно каждый из этих оригинальных текстов гонять через доступные онлайн-переводчики, в обе стороны. И потом, вручную, сидеть и выбирать наиболее осмысленный вариант. Но, во-первых, это долго, а, во-вторых, не надежно. Не зная языка, легко ошибиться с выбором.
Каким тут будет оптимальный (с точки зрения минимизации ручной работы) алгоритм?
Соответственно, на работе может возникнуть ситуация, когда нужно придумать алгоритм, для решения какой-нибудь нетривиальной задачи. Разве таких задач не бывает в практике программиста? И чем здесь может помочь знание пакета стандартных алгоритмов? Кроме как, для общего развития.
А эту демо-задачу можно усложнить. Например, требуется получить точные тайм-коды для смысловых фраз предложений, не длиннее, допустим, сорока символов. Существующие онлайн-сервисы дают неточные тайм коды, что легко проверить, загрузив их в звуковой редактор. Определение «смысловой фразы» можно оставить на усмотрение программиста.
И подобных, не вполне точных задач, в программистской практике, может встретиться сколько угодно. А доступный, т.е., бесплатный, ИИ помогает слабо.
Смысл этой задачи – получить эффективный, но бесплатный, инструмент для создания, например, двуязычных субтитров к произвольным иностранным видео.
В общем, вопрос риторический. Как программисту бороться с неопределенностью в своей практике, при отсутствии явного бюджета на это?
Давно уже как-то писал, когда я учился в ВУЗе у нас был курс по Ассемблеру x86, все девочки-отличницы выучили все опкоды наизусть во всех вариантах, но написать лабы не могли. Я не знал опкодов, но понимал саму суть работы ЦПУ, как именно всё устроено и под рукой держал Norton Guides с описанием команд. В итоге когда нужно было написать код я в голове изобретал что-то, переносил это на команды и получал результат. То есть алгоритм отличниц - вызубрить всё, а потом протарабанить когда спросят - тут не работал.
С алгоритмами примерно всё так же, я про это когда-то читал и даже в общих чертах знаю что, где и зачем, но я вам не напишу кода, для этого мне нужно будет залезть в справочник, напомнить себе какой именно вариант мой, а уже потом с ним работать. Конечно если это происходит почти никогда. А если каждый день - то в чем проблема, вы меня ночью разбудите и вам расскажу что такое KMP.
И точно так же я очень отрицательно отношусь к зубрёжке решений билетов при сдаче экзамена на право вождения. Во-первых, ПДД куда меньше по объёму и там всё написано весьма просто. Во-вторых - в билетах нет вашего города и дорог вашего города, в реальности всё будет не так как в билетах и вот тут и нужны знания ПДД, а не зубрёжка билетов, потому что зубрёжка - это про экзамен, а не про безопасное вождение.
И точно так же я очень отрицательно отношусь к зубрёжке решений билетов при сдаче экзамена на право вождения. Во-первых, ПДД куда меньше по объёму и там всё написано весьма просто. Во-вторых - в билетах нет вашего города и дорог вашего города, в реальности всё будет не так как в билетах и вот тут и нужны знания ПДД, а не зубрёжка билетов, потому что зубрёжка - это про экзамен, а не про безопасное вождение
А почему вы противопоставляете "зубрежку" (слово-то какое гнусное) и понимание? И ПДД надо знать наизусть (и сдавать их полностью), и задания надо уметь решать (типа кто кому уступит), и сто раз прокрутить на площадке автомобиль между конусами, и по городу надо поездить часика два (вертя головой во все стороны и постоянно перестраиваясь), и в горку/с горки с места тронуться, и т.д., и т.п. (да, да - и т.д. и т.п.!)
Почему всегда присутствует эта неопределенность половинчатость? Почему нельзя сделать тест комплексным и полным? Кому от этого хуже?
Когда человек только начинает водить, сознание переполнено. Особенно на машине с механической коробкой передач. Надо помнить про передачи, делать в нужный момент правильное движение двумя ногами и рукой, чтобы их переключать, следить за скоростью, за разметкой, за состоянием дорожного полотна, за дорожными знаками, за светофорами, за другими машинами, за пешеходами, за маршрутом.
Однако ключ к безаварийному вождению - уметь видеть движение вокруг себя в целом и понимать, что от него ждать. Полагаться больше не на реакцию, а на понимание ситуации и прогноз.
У меня очень тяжёлый случай в прямом смысле, я всегда о всём очень много и усиленно думаю. КОгда пошёл учиться на вождение, то сомневался что смогу ездить. К счастью у меня оказался хороший как преподаватель теории - бывший инспектор ДПС, так и практический водитель - бывший дальнобой.
Я так же когда впервые поехал в город чуть с ума не сошёл. Думал обо всём. Но как человек любящий программировать, на основе советов двух преподавателей, я придумал такую систему. Она нужна не только новичку, у меня масса знакомых которые имея стаж в 10 лет так и не научились нормально водить. В общем по вождению делаете так - идёте на площадку ГИБДД если она доступна или ищете в городе нормальное место, берёте кучу бутылок 1.5л, наливаете воду и расставляете их, словно это гараж, парковка и т.п. Хорошо если есть разметка. И просто по 3-4 часа в день паркуетесь, трогаетесь, разворачиваетесь. За неделю вы станете ассом парковки во дворах, у вас не будет глохнуть машина при трогании на механике. Это та самая память, о которой написано в статье. Плюс такого подхода в том, что у ученика просто нет раздражителей в виде пешеходов, других машин и т.д. Он сосредоточен на элементах управления машиной, понимании её габаритов, понимании скорости начала движения и тому, как взаимодействие с рулём влияет на движение.
Далее. В городе самое важное - смотреть постоянно по зеркалам, занимать своё место в потоке (не жаться к краю и не дергаться). Смотреть строго в свой ряд, если в вашем ряду свободно - ехать. Плевать на бабушку которая в 20 метрах от вас стоит на остановке. Плевать на бегущего по парку, плевать на машину в другом ряду - от вас их поведение не зависит, а вы, как новичок, не сумеете предугадать их поведение. Важно только одно - быть горовым нажать на тормоз и не разгоняться, чтобы этот тормоз и оказался полезен. С опытом вы начнёте смотреть шире, понимать ситуацию в соседних рядах, например вы едете в 3 ряду, видите справа что в первом ряду машина пытается объехать автобус на остановке, он нагло лезет в поток, значит вы должны оставить карман для второго ряда, иначе вам в бок прилетит. Или дети лет 12-ти толкаются у края проезжей части, у вас скорость 60, нужно сбавить до 20-30, проехать, а потом опять ускориться. Такие вещи даст только опыт.
По себе еще скажу, мне сильно помогло участие в мероприятиях одного местного автоклуба, там я научился держать руль, быстро переставлять руки и понимать скорость и время остановки.
как правильно держать руки на руле (многие не умеют!)
Если вы про классические 10 и 2 часа, то это плохой вариант. Почему? Потому что у вас амплитуда без перестановки рук будет очень небольшой, примерно 90 градусов всего. Для быстрого поворота с перестановкой рук нужно ставить 11 и 1 или на 12 обе руки. Но я предпочитаю держать руль снизу на 7-8 часов и 3-4 часа. Во-первых не устают руки в висячем положении, левая всегда лежит, правая немного приподнята, если путь долгий то зеркалим их с каким-то интервалом. В случае необходимости нижней рукой просто сжимаем колесо управления и оно фиксируется. Это так же решает проблему ненужного руления когда вас болтает, например идут удары по корпусу при ДТП или вы вылетели с дороги и скачете по ухабам. Если руки были бы сверху то из-за болтанки вы бы рулили непроизвольно то вправо то влево. Если будет необходимо, то вы можете повернуть рулевое колесо на 270 градусов одной рукой, а еще, если правой контролировать это действие, то когда левая повернула, то правая идёт против вращения, перехватывает сверху и доворачивает еще на 180 градусов. Перестановками так же можно, но тут нужна практика. При это про 10 и 2 совсем забывать не нужно, при езде во дворах или парковке 10-2 или 8-3 будут полезны.
Добрый человек, расскажи, пожалуйста, про ноги и педали, это доставляет мне максимальный дискомфорт. У меня не получается держать пятку на полу и жать носком, я полностью поднимаю ногу и давлю. И при этом не могу точно контролировать силу нажатия. Есть техники, чтобы лучше управляться с педалями?
Это шутка такая, да?
У меня не получается держать пятку на полу и жать носком, я полностью поднимаю ногу и давлю
Ищите положение кресла такое, чтобы это стало удобно, есть автомобили где отвратительная посадка, там уже двигать/поднимать кресло не поможет.
Как правило я максимально поднимаю кресло вверх и не понимаю тех водителей, которые сидят на полу и кроме их носа из-за руля ничего не видно. Чем выше вы сидите, тем лучше видите происходящее вокруг. Педаль так устроена, что она скорее ждет нажатия сверху вниз и вперёд нежели только вперед.
И при этом не могу точно контролировать силу нажатия
Если у вас старый автомобиль на карбюраторе через тросик, то регулируется всё только отжатием сцепления, через небольшое время привыкните и не будете сильно перегазовывать. Если это инжекторный автомобиль начала 90-х или современный с электронной педалью то там особых навыков не требуется, там практически невозможно что-то сделать неправильно, так как педаль электронная и она скорее ловит определенные типы нажатия чем грубую силу. Например я на японцах выйти на крейсерскую скорость на многих машинах можно просто отпустив немного педаль, при этом скорость не упадёт, но снизятся обороты, машина будет продолжать нормально ехать, но не будет рычать и тратить бензин, то есть у вас упадёт динамика разгона, для ускорения просто нажимаете немного но резко, обороты опять вырастут но скорость опять не изменится. Это же компьютер, как его зашили на заводе так он и "думает" за водителя.
Есть техники, чтобы лучше управляться с педалями?
У меня не было с педалями проблем, я отъездил на советских машинах, на европейцах и японцах, в этом году покатался на Haval. Везде с педалями было нормально. У меня рост 171. Поиграйтесь с креслом, поищите другой вариант. Нога должна быть расслаблена и просто лежать на пятке и работать только ступнёй. Если икра напряжена и даже есть судороги, то точно сидите неправильно. У меня скорее были всегда проблемы с педалью тормоза, как правило я люблю жесткую педаль и мне очень некомфортно ездить на машине с мягким тормозом. Например в Haval жесткая педаль как у японцев, в Peugeot 206 так же была жесткая, но попадались Тойоты с очень мягкой педалью.
Я когда только начал ездить то мне было некомфортно ездить в зимней обуви, я не чувствовал педали, но за пару зим освоился, сейчас всё равно, разве что босиком не люблю ездить.
У меня была такая же проблема, когда учился - не чувствовал хода стопы на сцеплении и газе. Помогли 2 упражнения - дома резинка, которой тянул носок каждой ступни и медленно в противофазе нажимал и отпускал воображаемые педали. Второе -когда гулял с дочкой в песочнице, делал такую горку и мял её ступнями, имитируя нажатия.
ради интереса посмотрел отзывы на хабр карьере про яндекс, увидел то, что и ожидал.
все недовольные отзывы в основном ссылаются на душную атмосферу и переработки.
то есть эти деятели сначала душат на интервью, выбирая только гениев, а потом убивают этих гениев внутри своей компании)))
я как-то проходил тестовое задание для яндекса, там надо 5 часов решать какие-то задачи, все под таймер и бла бла бла, тогда это было забавно, сейчас я бы ни за что не стал тратить на это время))
а по статье - без реальных проектов, на которых используются те или иные алгоритмы вы никогда не поймете смысла, зачем оно вообще надо, все эти О-большие, логарифмы и вся остальная чепуха только забивает голову. Учите то, с чем работаете в данный момент, придет время, выучите и алгоритмы.
А если вас на собесе начинают душить, спросите, используют ли они это в реальных проектах на вашей позиции и если нет, уточните, зачем они у вас это спрашивают, поблагодарите за украденное ваше время и идите на следующее))
Беда всех статьей такого рода в том, что они задают вопрос "зачем алгоритмы", а отвечают на самом деле на вопрос "почему бигтех дрочит вас алгоритмами". А это 2 большие разницы.
Знание алгоритмов становится полезным, если у вас в коде есть циклы или коллекции. Есть они везде. Работать с ними можно по-тупому или по-умному. Хочешь по-умному - будь добр ознакомься с темой алгоритмов и структур данных. Вот и всё.
А про бигтех пережевывать в сотый раз уже не интересно.
Вообще мимо аналогия.
Вы про мануальные навыки? Тут согласен - программисту мануальные навыки не нужны (разве что - навык печати): программирование идет в голове, там всё устроено по-другому, координация работы мышц для программирования не нужна
Хоть в прямую про мануальный навыки, хоть несколько метафорично.
Главная проблема в реальных проектах - не написать код, а вписать его в существующий проект. Вписать так, чтобы затронуть меньше файлов. Вписать так, чтобы потребовал минимум тестов. Воти эти навыки можно сравнить с мануальными. Они помогают успешно писать код.
Пиши ты хоть с закрытыми глазами всякие вращения деревьев, если ты не можешь вписать свой код удачно - его не существует.
Мануальный навык вождения машины можно приобрести или за годы опыта, или пройдя соответствующие курсы. На курсах, кстати, начнут с того, что привьют водителю элементарную грамотность: как правильно держать руки на руле (многие не умеют!), как правильно рулить и пользоваться педалями. Только освоив эту базу, можно учиться чему-то более полезному.
Интересная аналогия. Действительно, есть сильные гипотезы о том, что мозг способен экстраполировать и заимствовать способы думания об алгоритмах (так называемые в нейрофизиологии "динамики внимания") на нашу ежедневную работу по написанию кода.
Тем не менее, хороших подтверждений такой гипотезы я не встречал. Возвращаясь к аналогии про мануальный навык воздения машины. Говорить о том, что инвестиция нескольких месяцев в решение литкода и формулирование алгоритмов по памяти помогает в работе программистов — это примерно как говорить о том, что умение бегать марафоны сильно помогает водить машину. Координация, физическая подготовка, фокус внимания на дороге и вот это всё.
Причем, если собрать статистику, то, возможно, среди тех, кто бегает марафоны действительно аварий меньше. Но вопрос будет в том, переиспользует ли мозг навыки бега марафонов для вождения машины как "базу", или же и то и другое коррелирует с чем-то другим. Например, собранностью, целеустремленностью, хорошей физической формой или какими-то чертами характера.
Если ты Гугл, то можно при сдаче на права требовать пробежать марафон, 100 раз отжаться, 50 раз подтянуться, поразить мишеть из лука, перевести текст с Японского и ответить устно на вопрос по-английски. Возможно, в таком случае аварий будет меньше. Но это — если ты Гугл. Во всех остальных случаях your mileage may vary 😥.
Алгоритмы знать полезно, но отличие алгоритмов на собеседовании и применении в жизни - доступ к информации. Знать что тот или иной алгоритм существует и иметь о нем представление в общем, полезно. Но тот же Яндекс требует идеального вызубривания алгоритмов. Нафига мне каждый раз помнить алгоритм обхода бинарного дерева, если я не пользуюсь бинарными деревьями? И так же можно сказать о большинстве алгоритмов, они либо уже реализованы кем то другим и давно есть библиотека под твои задачи, либо они тебе нафиг и не нужны.
Если же есть выбор между реализацией алгоритма, использованию библиотеки или решением без алгоритма - выбираем то что будет быстрее реализовать, даже если алгоритм в этом случае будет "правильней". Не потому что оптимизация не важна, время обработки не важно и проч., а потому что лучше пусть будет на 100мс дольше запрос, или использовать будет больше памяти / процесорного времени, чем программист будет сидеть и наяривать этот алгоритм. Время программистов стоит дороже чем подобная оптимизация
Но тот же Яндекс требует идеального вызубривания алгоритмов.
Ну, в Яндексе можно и не работать. Это не обязательно, работать в Яндексе.
Нафига мне каждый раз помнить алгоритм обхода бинарного дерева, если я не пользуюсь бинарными деревьями?
Может, потому и не пользуетесь? Я вот пользуюсь :-)
Время программистов стоит дороже чем подобная оптимизация
Обратная сторона такого подхода: программисты быстро чего-то там пишут, но плохо ориентируются в написанном. Потом, когда возникают проблемы, всё сэкономненное время быстро улетает в попытках с ними разобраться.
Оооо..Я помню как не любила приходить на пары по алгоритмам, еще когда графы рисовали на бумаге..пустая трата времени) Но кстати потом, когда пришли к более сложным задачам, то поняла, что без них сложно понять логику программирования) Но когда устраивалась на работу, никто ничего про алгоритмы не спрашивал)))
И как вам поможет опыт сортировки и обхода бинарных деревьев сделать фикс API в лохматом легаси коде? Алгогритмические нетривиальные задачи в работе - это самая малая её часть. Чтение написанного кода/API и понимание как оно устроено и как его использовать мало соотносится к обходам отсортированных массивов и развороту односвязных списков.
Алгоритмы полезны для достаточно быстрого понимания как сделать некоторые уникальные штуки, но какой-нибудь ранжирующий алгоритм в алгозадачах всё равно не встречается, чтобы его можно было как-то сходу его написать, основываясь на них - без чтения специализированной литературы никакая тренировка алгоритмов с подобным не поможет.
Мне вот кажется, что знать и понимать алгоритмы полезно, но зазубривать все варианты это уже перебор.
Но я не настоящий программист.
Некоторые даже устраивают отдельное собеседование по алгоритмам, зачастую весьма нешуточное.
Большие компании при найме должны отфильтровать кандидатов, которые не умеют программировать. Их много. Прям, реально много. Для примера, у меня был кандидат, который в тестовом написал три вложенных цикла for от одного до тысячи. Спрашиваю: "сколько раз выполнится выражение внутри самого вложенного цикла". Отвечает: "тысячу". Переспрашивал несколько раз: всё-равно "тысячу."
Во-вторых, бигтех предлагает зарплату заметно выше рынка, а потому, может позволить себе нанимать только тех, кто мотивирован работать именно у них.
Ни то, ни другое, не имеет никакого отношения к ценности понимания алгоритмической сложности самим разработчиком. Последнюю даже обосновывать странно: если разработчик не может прикинуть сложность решения по вычислениям и памяти, то он просто профнепригоден.
Зачем программисту алгоритмы?