Comments 119
Еще лет 10 назад, когда работали русскоязычные сайты Intel'а (конкретно — Intel MKL), я предлагал 10000$ за разработку алгоритма трехдиагонализации вещественных симметричных упакованных матриц, который в разы (сейчас в 2 раза, а тогда почти в 3 раза) был бы быстрей соответствующего алгоритма из пакета Intel MKL. Но никто за эту задачу не взялся, хотя мне удалось ее решить, но его я не публиковал (по причине, указанной ниже). Хотя Intel MKL воспользовался моей статьей (Ю. Ф. Сиголаев, Б. И. Ионин, О модификации алгоритмов диагонализации, связанных с квантовохимическими расчетами. Журнал общей химии. – 2010. – 80, № 11. – С. 1928-1929.) для улучшения другого алгоритма, связанного с диагонализацией, при этом на меня не сославшись. После этого отпало всякое желание что-либо публиковать. А теперь вопрос: а кто умеет? Ведь Intel MKL рекламирует свой продукт как лучший в мире в части, касающейся алгоритмов линейной алгебры.
У Интел есть разработчики а есть "продавцы" разработчики разрабатывают как могут (и на самом деле нет уверенности что ваш алгоритм в общем случае даёт лучший с т.з. целей библиотеки результат), но их задача разработать "комплексное решение" и вполне возможно что если один из их крупных клиентов укажет на проблему производительности именно в этом месте они для их частного случая (а может, если повезёт и для всех) доработают алгоритм, но сумма с риска должна быть такой, чтобы выдернуть специалистов из других задач и это не 10000 и вероятно даже не 100000$.
Есть пример к примеру Oracle, который отдаёт индивидуальные патчи крупным клиентам, но не всем а только тем кто пожаловался на конкретную проблему и дело тут в том что патчи могут создать больше проблем у основной массы потребителей.
На мой взгляд, шикарный троллинг!
PS могу предложить ещё одну альтернативу: набросать валидатор ФИО.
Задача в контексте JS, так что максимальное целое — 2147483647
Тут как бы вопрос к тому, что вы тестируете. Если алгоритмы — вы должны сказать явно, что число меньше миллиона, например. А если постановку задач — должны ожидать уточняющего вопроса, да. Но все равно к вам больше вопросов возникает с такой задачей.
Когда я ставлю задачу, уточняю что аргумент приходит валидный, показываю даже кейс использования:
for (let n = 0; n < 10; n++) {
const number = Math.round(Math.random() * 1000000)
console.log(`Number ${number} is ${isPrimeNumber(number) ? '' : 'not '}prime`)
}Ну не стенограмму же мне собеседования к заметке прикреплять, право слово!
ps хотя не, проверил, быстро считает современный JS.
100000 раз / мин — уже кешируем список простых чисел в память и развлекаемся с деревьями/списками для большей скорости ( предварительно проверив, что входящее число — это число, больше 1 и меньшеравно maxint)
Отвечу цитатой:
Вычислительная сложность решения не особо важна, главное — задачу нужно решить.
Разумеется, после решения можно про мемоизацию поговорить и прочая. Но, дабы не разводить обсуждение: всё, что идёт после самого примитивного и банального решения «в лоб», находится вне темы этой заметки. Я написал про совсем другие случаи, когда разговор про входящие данные и кейсы использования даже не заходит, по причинам, которые я тоже описал.
Зануда mode on
В контексте JS максимальное целое — Number.MAX_SAFE_INTEGER, а это 9007199254740991.
Зануда mode off
главное — это умение писать код, решающий задачу
За некоторыми исключениями, в виде задач действительно требующих какого-то математического бэкграунда, это умеет даже джун.
И нет — ваши задачи такового бэкграунда не требуют, я уверен.
function isPrimeNumber(number)
Задачка определить простое число на js для меня стоит где-то рядом с fizzbuzz, и отсеить позволяет лишь совсем залётных ребят которые вообще код писать не умеют, ну или код со stackoverflow по шаблону в контроллеры вставляют.
Такие, кмк, отсеются что с «алгоритмами», что без.
Вообщем, к тому что сейчас обычно подразумевают под знанием алгоритмов, описанное в этои топике не относится +- никак.
и отсеить позволяет лишь совсем залётных ребят которые вообще код писать не умеют
Я бы тоже самое сказал, но смотрю же на резюме перед собеседованием: там, например, опыт работы в известной компании на позиции мида в течение года-двух. Не похож человек на залётного, да и говорит складно. Но на технической части собеседования происходит вышеописанное. Сюр какой-то.
С синьёр позициями тоже самое. Даже задачка написать функцию которая:
type chunk = (source: number[], limit: number) => number[][];
// chunk([1,2,3,4,5], 2) => [[1,2], [3,4], [5]]В подавляющем большинстве люди с лычками tech-lead, team-lead, senior developer и громкими фреймворками, паттернами в резюме, обильным списком responsibilities — НЕ МОГУТ РЕШИТЬ эту задачу. Чаще всего даже с подсказками. В дружественной обстановке.
И дело не только в алгоритмах. Чаще всего люди не знают основ языка. 8 из 10 кандидатов на синьёр-помидор позицию не знают, что [...arr] копирует массив не целиком, а делает shallow копию.
Или классический пример:
for (var i = 0; i < 10; ++ i)
setTimeout(() => console.log(i), 100);- что выведется в консоли?
- ок, а как сделать чтобы правильно выводились числа?
- а когда они выведутся? все сразу или с паузами в 100мс?
- а как починить?
Люди массово (5 из 10) валят даже это.
Я могу составить алгоритм, включая задачи очень высокого класса. И оценку сложности для него дать.
Но все равно я использую куски из SO и гуглю задачи перед попыткой их решения.
Ну реально, я могу решить задачу, но на это уйдет 30-40 минут, а на валидацию решения с SO 10-15 причем с меньшей нагрузкой. Да, есть шанс не найти на SO решения. Но и в своем есть вариант попасть на баг, который будешь часами ловить.
А задачка на простое число у меня вызовет сразу вопрос «до какого значения возможны числа?». Да блин, даже банальное решето Эратосфена на больших значениях требует нетривиальной логики.
Я могу составить алгоритм, включая задачи очень высокого класса.<...>Но все равно я использую куски из SO и гуглю задачи перед попыткой их решения.Одно другое не исключает. Ключевой момент в том, что вы СНАЧАЛА алгоритмизируете, а ПОТОМ кодите (пусть даже с помощью SO). На мой взгляд, хуже, когда делают наоборот или просто ограничиваются вторым пунктом.
Может за время моего выпуска кто-то придумал для алгоритма n^2 решение в log(n). C Чего бы его не использовать? Или библиотека есть, над которой год работали и она явно лучше меня решит. У меня же нет возможности отследить все подвижки по всем фронтам.
Еще раз. Погуглить — до 15 минут. Если это потенциально снижает сложность в 2-100 раз, из каких соображений вы этого не делаете? Ну кроме случая «нет интернета».
Один из практических случаев кстати — modified goertzel algorithm для ответа на вопрос «является ли тон в дорожке тоном нужной частоты». Я про него даже не слышал, решал бы задачу по старинке преобразованием Фурье(которое, кстати, пихают везде в SO). По факту разница в скорости работы — на порядки в нужной задаче. В результате задача из НЕОСУЩЕСТВИМОЙ (в связи с нужной мощностью) перешла в разряд успешно решенных.
Раньше инженеров учили — даже если знаешь решение, открой справочник и уточни. Почему сейчас некоторые против гугла — непонятно. Это гордыня в конце концов. Займитесь в освободившееся время чемнибудь полезным.
Проблема в том, что все задачи решаемые middle и даже middle++ разработчиком уже давно решены и просто думалка атрофируется, т.к. перед тобой просто не возникает задач, чтобы поразвиваться. Не то, чтобы я там какой-то сеньор, куда уж мне, но даже я заметил, что 99% всех задач на работе я могу загуглить и слегка подкорректировать перед использованием. По сути, просто играю в лего, с учётом специфики задачи.
Поэтому мне не нужно играть в алгоритмы и придумывать их. Я не настолько умный, как люди, жизнь посвятившие алгоритмам и точно не придумаю ничего умнее. Всё, что от меня действительно требуется на работе — увидеть какие алгоритмы подойдут к моим данным и можно ли мне как-то векторизовать вычисления. А придумывать алгоритм не нужно в 99,99% моих задач.
По теме:
Не вижу особой беды в том, чтобы не быть способным написать свой костыльный алгоритм для генерации простых чисел. Вот когда задачу прочитал, я подумал:
1) Помнится в универе делал как-то алгоритм, что-то там про Эратосфена было
2) Помню, что не самый эффективный был алгоритм
3) Хз как его воспроизвести без Гугла
4) Наверное также бы на собесе тупил, попроси меня реализовать эту задачу. Ничего умнее чем "в лоб" не придумал бы.
Но при этом у меня никогда не возникало проблем с реализацией алгоритмов из книжек, всегда понимал как для тех или иных данных, можно чего-нибудь соптимизировать, как бы их в памяти положить, какие проблемы будут с кешами при использовании тех или иных алгоритмов. Но вот сам придумать не особо могу что-то умное и вообще не уверен, что напишу с ходу без гугла какой-нибудь red black tree.
В целом, для меня фраза "знать алгоритмы и структуры данных" означает не "уметь реализовать", а "уметь вспомнить название и сложность алгоритма, который мог бы подойти к текущим условиям".
Возвращаясь к задаче генерации простых чисел: я бы ответил что-то очень тупое, вроде: "я знаю очень тупое решение в лоб, других у меня нет без гугла". И по моему опыту собеседований в Яндекс такой ответ не является удовлетворительным :)
На самом деле, самое ценное уметь правильно задавать вопросы, как людям так и Гуглу, потому что поиск в лоб часто результата не даёт, кто-то может помнить тысячу особенностей одного языка и порядок параметров в функциями, но не может найти ответ на простой вопрос по ошибке, ктото не помнит с нуля или еденички начинается отсчёт элементов и у него на это шпаргалка, ну вот плохая память а результаты работы всех устраивают.
p.s. про 0 и 1, в оракле нумерация дней в году американская с единицы :) в java есть классы даты в которых связанные с датами в которых есть последовательности от 0 и от 1, нут так вот "исторически" сложилось, кто-то один раз прочтёт и будучи разбуженный ответит без запинки, а кому-то проверять нужно, конечно лучше иметь хорошую память, но это часто расслабляет и иногда приводит к логическим ошибкам и излишней самоуверенности.
Вы можете себе позволить выбор: пользоваться SO или нет. Я же «жалуюсь» на специалистов, которые этого выбора себя лишили.
Максимальное число ограничено возможностями самого JavaScript: 2147483647.
Не вполне понятно, о каких возможностях идёт речь. Непрерывный ряд целых чисел в JavaScript заканчивается числом 9007199254740992. До этого значения включительно — можно использовать все обычные приёмы работы с целыми числами, с поправкой на необходимость вызовов всяких Math.floor. По вашему сообщению создаётся впечатление, что вы об этом не в курсе…
Для работы с бо́льшими числами нужна «длинная арифметика», но на 32-битных платформах естественный максимум для процессора (соответственно, эффективный размер для длинной арифметики) ещё меньше — 4294967295 (ваше 2147483647 неуместно, потому что в эффективных реализациях длинной арифметики знак отделён), так что сложности появляются заметно раньше.
Или с чем вы сравниваете?
По вашему сообщению создаётся впечатление, что вы об этом не в курсе…
Не знал, да ещё и забыл ) 2 в 31 степени в голове крутилось.
Но поймите, кандидату даётся задача «решить хоть как-то» и, учитывая ограниченность времени на собеседование, тем более не предполагается сложного решения. Разговор о максимальных значениях аргумента при такой постановке вопроса вообще не уместен.
2147483647 это только для битовых операций, после чего получим переполнение. Ну и про BigInt уже сказали.
Да блин, даже банальное решето Эратосфена на больших значениях требует нетривиальной логики.
По написанной постановке задачи решето вообще не особо к месту. Оно потребуется только если нужно как минимум сотни тысяч чисел регулярно проверять, и можно долго хранить таблицу в памяти.
Как вы считаете, нужно ли современному программисту уметь разрабатывать алгоритмы?
В текущих реалиях этот вопрос напоминает такой: "Нужно ли переводчику знать английский?"
Сразу хочется выкрикнуть "конечно!". С другой стороны, зачем английский, например, переводчику с китайского на русский?
Есть области, где это умение необходимо. Есть области, где это не требуется от слова совсем.
Первое время я терялся и не знал что ответить, потому что я не вижу тут математики ...
За ту математику, что здесь вижу я, можно миллион отхватить. Гипотеза Риммана называется.
function isPrimeNumber(number)
Я вижу, вы с момента прошлой статьи так и не поняли, чем хорош FizzBuzz и чем плох ваш тест.
FizzBuzz жестко ограничен сверху, ваш тест — нет. Подумайте над этим.
Как вы считаете, нужно ли современному программисту уметь разрабатывать алгоритмы?Голосовалку прикрутите, чтобы камменты не плодить.
Мой ответ — да. Писать код без хотя бы приблизительной «блок-схемы» (о, еще один термин из прошлого!) считаю неприличным.
Я ответил на голосовалку «Нет, программисту не надо в алгоритмы», из-за постановки в посте.
Всё очень просто — функция нахождения простых чисел и их проверки не простая, имеет много ограничений и простора для оптимизации. Для хорошего решения реально нужен подкованный в математике человек. Для так себе — и впрямь достаточно любого программиста.
Алгори́тм (лат. algorithmi — от арабского имени математика Аль-Хорезми[1]) — конечная совокупность точно заданных правил решения произвольного класса задач или набор инструкций, описывающих порядок действий исполнителя для решения некоторой задачи.
Под это определение подходит всё что делает программист. Даже гуглинг на СО подходит.
А вот решение математических задач хорошей сложности — это совсем другие алгоритмы и они и впрямь нужны очень небольшому числу людей.
Да даже определение сложности «алгоритма» в общем то, не имеет большого смысла чаще всего.
Поэтому — нет, умение самому написать сходу оптимальное решение хорошего уровня математической задачи программистам в подавляющем большинстве не нужно.
А вот строить алгоритмы, которые решают задачи которыми они собираются заниматься они должны и, чаще всего, умеют.
ЗЫ: За 10 лет ни разу не пришлось определять простое число или нет.
Да даже определение сложности «алгоритма» в общем то, не имеет большого смысла чаще всего.
Можете чуть подробнее: почему считаете, что не часто не имеет смысла и когда имеет?
Вложенные циклы — плохо.
Поиск по столбцам без индексов — плохо.
И многое-многое другое (ну, учитывая что есть хорошая альтернатива, конечно).
Смысл в том, что знать как использовать важнее чем понимать как работает почти всегда. =)
Ну значит кто то не умеет пользоваться индексами, запросами и планами запросов. )
Только я бы приписал, в зависимости от ситуации у нас к примеру есть следующее деление на хорошо/плохо :)
Для так себе — и впрямь достаточно любого программиста
Было бы хорошо, но получается, что любой не может, на что я и посетовал. И вопрос можно было бы задать так: «Как вы считаете, нужно ли современному программисту уметь хотя бы как-нибудь простенько реализовывать алгоритм проверки простого числа?»
Но это же собеседование, а значит от человека ждут что он покажет какой то крутой алгоритм с хорошей скоростью работы и основанный на красивой математической модели. А это и впрямь скорее задача «алгоритмиста» или СО.
ЗЫ: в подавляющем большинстве случаев.
ЗЫЫ: как мне надоедает, иногда, писать оговорки)
а значит от человека ждут что он покажет какой то крутой алгоритм с хорошей скоростью работы
Знаете, если вы такое придумываете для себя, когда вам прямо говорят «сделай хоть как-то», то вы либо лукавите и не можете решить эту элементарную задачку, или у вас серьёзные проблемы с коммуникацией, и опять же непонятно, как с вами работать дальше.
Сделать хоть как то — явная провокация. Хороший специалист должен сделать хорошо, а не хоть как то. А если хорошо должен делать другой человек — логично передать ему эту задачу.
На собесах в Яндекс, внезапно, "сделай хоть как-то" означает "впечатли меня" :) Потому что если сделаешь хоть как-то, а это хоть как-то будет O(n^3), то всё, ты провалился)
В Яндексе может и так, но у себя мы только радовались, когда кандидаты начинали предлагать и обсуждать варианты, указывать ограничения и уточнять типичные кейсы
И.е. если вам предложат в цикле разделить округлить умножить и сравнить с искомым то этап пройден?
Мне вот интересно, иногда появляется желание сменить направление в какой нибудь backend или системное… не в js правда, но проблема в том что есть особенности памяти, приводившие к тому что в институте было проще вывести теоремы и доказать чем выучить… И вот в вашем примере, конкретном я бы конечно не вспомнил ни одного оптимизированного варианта решения (не учитывая отброса чётных чисел больше 2х), но удовлетворил бы вас такой кандидат?
Реально как-то давно был на собеседовании и там задали задачку которая в лоб решается рекурсией но в реальности работает до весьма скромных значений(точно не помню что за задача)...
Если человек скажет что-то в стиле «Ну, навскидку, нужно поделить на все числа от 2 до (n-1)/2… Но это неоптимальное решение, наверняка можно оптимизировать, проверив… А вообще Я бы пошел в гугл искать существующие алгоритмы...»
И при этом покажет хорошие знания в других областях — конечно было бы здорово его взять.
Несмотря на то, что формально кандидат написал только вот такое неоптимальное решение.
Так то Я считаю, что программист должен уметь производить исследование и заниматься инженерией — целенаправленным дизайном алгоритма решения конкретной задачи в классическом смысле слова «алгоритм».
Другое дело что даже сходить за хлебушком — тоже алгоритм, дело в сложности.
Алгоритм — это, кодифицированное интуиционитское доказательстово существования (решения). При том, что некоторые алгоритмы вроде бы делают то, что нужно, понять, что это реально решение — очень трудно. В этом основная сложность, и часто бывает так, что пишущий проверяет N кейсов и считает, что алгоритм готов. А он на N кейсах правильный, а потом расходится.
Умение вовремя остановиться — это навык, который я начал у себя качать, и который даёт самый офигенный результат в long term. Каждый раз, когда я нахожу старый код, в котором я вовремя не остановился, мне больно.
В сравнении с этим код, в котором я вовремя остановился, его просто не заметно. Он простой, легко читается и легко дописывается.
Любое правильное решение :-) Впрочем, через пару лет впору будет и неправильные тоже засчитывать )
Вот это, кстати, пример, который без полбутылки непонять.
Не, может его поймет кто-то из конкретной школы программирования, мимо меня — прошло.
Тоесть это тест на ту же школу? А смысл.
В этом коде i2 — просто i^2, i увеличивается с шагом 2 (идет по нечетным числам), квадрат i тоже считается реккурентно.
И да, код некорректный: 14 или 16, например, простые с его точки зрения.
Непонятно про рекурентное вычисление и границы.
Если ik+1 = ik+2, то i2k+1 = i2k + 4ik + 4.
Вводится отдельная переменная i2i = 4i+4, для которой i2ik+1 = i2ik+8
Если вы постоянно этим не пользуетесь, то это магия. Я вот формулу квадрата суммы не использовал… ну лет 18-19 наверно.
f(4) == true. Серьёзно?
Интересный вопрос :-) Конечно, false приятно бы удивил, но в данном случае интересует процесс построения алгоритма, а не оседомлённость в математике. К слову, комментарий с определением простого числа появился не сразу, а после того, как я обнаружил, что не все знают/помнят его.
Думаю, нет ничего страшного в том, чтобы забыть такую вещь. Я знаю одну программистку, которая помогала профессору запилить какой-то алгоритм для анализа чего-то в ДНК и она в соавторы научной статьи попала, хотя в генетике абсолютный дуб )
Я знаю одну программистку, которая помогала профессору запилить какой-то алгоритм для анализа чего-то в ДНК и она в соавторы научной статьи попала, хотя в генетике абсолютный дуб )Это нормально и правильно. Если человек делал экспериментальную установку или методику анализа данных, то это весомый вклад в статью, который должен быть отражен в списке авторов
Мне нравится задача описанная в примере, хотя если на такое не ответит серьер, то я даже не знаю…
Думаю с ней ребенок с мозгами в 6м классе должен вполне справиться
Позвольте подкинуть масло в огонь задачу по js из вида "больных", которую мне однажды задали (значения отличаются, но смысл один).
*
Что выведут эти четыре выражения в консоли браузера и почему?
1)
var t = (1+2,3) * 4 2)
(2,1 + 3) * 43)
var t = 1,3 * 44)
1,3 * 4Предлагаю прочитавшим, без использования консоли проверить свои знания в комментариях
Когда я ее встретил, я смог ответить правильно на первые 3, по 4й дал свои размышления и мне по итогу засчитали, но для себя я решил, что если мне еще раз подобное предложат, я просто развернусь и уйду. Как по мне это задачи из раздела "я вот тут вчера узнал одну любопытную вещь, ну вы то точно должны это знать" не вызывают у разработчика ничего кроме батхерда. Ну я бы еще понял вопрос по работе с числами с плавающей запятой, это должен знать каждый, но это…
Это упоротость :-) Я завалился на 3 — не ожидал такого поведения. Вообще, про JS всё знать, наверное, невозможно, как ни старайся )
Несмотря на то, что я легко ответил на все 4 вопроса (они все 4 одинаковые, хватило бы и 1), я решительно не вижу никакого смысла такое спрашивать, ибо оператор "запятая" в адекватном коде не используется. Это скорее удел минимизаторов.
В заголовке — про алгоритмы. А задача — на реализацию библиотечных функций. Нет, это, конечно, тоже алгоритмы, да....
Тут, видите ли, есть разница. Малюсенькая, но есть.
:)
Простой перебор всех чисел от 2 до number/2 и проверка остатка от деления, считается алгоритмом?
Если да, то я понимаю почему многие теряются, чересчур уж простая задача для собеседования. А если нет, то каков алгоритм?
В целом задача определения простоты числа считается одной из сложных задач математики, поэтому я его считаю плохим примером того, что алгоритм и математика — разные вещи. Можно, конечно, решить задачу простым перебором, но не факт, что такой подход к решению задач вообще полезен.
При этом я считаю, что, несмотря на наличие множества готовых библиотек, нужно уметь писать алгоритмы, потому что не умея их писать, невозможно сориентироваться в их множестве, свойствах и применимости для конкретной задачи, и составить правильный подход к решению задачи на основе готовых алгоритмов.
ShibaOn может проблема не в претендентах, а в ваших заданиях? Может вы неправильно проводите собеседование?
Сегодня я пожаловался коллегам на эту проблему и они тоже удивились. Удивились и сказали как бы они решили эту задачу, причём разговор сразу пошёл про оптимизацию вычислений.
Меня такое ваше рассуждение еще больше убеждает в том, что проблема не в претендентах.
Как можно сравнивать рассуждения коллег, которым нечего вам доказывать и человека, который находится в состоянии стресса?
Возможно, таким вашим собеседованием, вы отшили много умных, но психологически не очень устойчивых и не очень уверенных в себе программистов.
— Такую проблему обнаружил, ребята на собеседованиях не могут на JS простейший алгоритм написать для проверки на простое число.
— Тут всё не так однозначно, какие входные данные, как используется алгоритм?
— Да неважно, любое решение «в лоб» подойдёт, предлагаю перебором решить, всё-равно не могут.
— Ты их как-то не так спрашиваешь.
"Можно, конечно, решить задачу простым перебором, но не факт, что такой подход к решению задач вообще полезен."
Вы просто не представляете как радует глаз простой, как валенок, метод в легаси, когда пришел тикет что-то в нем починить (вот прям сейчас) или расширить функционал.
Изобретать/исследовать новые алгоритмы, инженерить применение известных и просто "кодить" — сильно разные роды занятий, но все попадают под определение "программизма".
Мне представляется что индустрии в 80-90% случаев нужны кодеры, а им совсем не обязательно знать о "2,7,61" (в продолжение isPrimeNumber) и ещё о куче всяких подобных вещей. В том смысле, что в жизни есть ещё масса интересного, на что можно потратить время (в том числе избавиться от "клипового" мышления). Люди довольно быстро понимают, что умение быстро слепить что-то из пары-другой js-библиотечек с бОлшим шансами и быстрее приведёт их к целевой зарплате, их нельзя в этом упрекать.
Те же кого интересует создание новых алгоритмов и/или высокая инженерия (как мне кажется) сами найдут дорогу. Им следует давать возможность учиться и шанс проявить способности (рабочие места с нормальными задачами). Но что-то мне подсказывает, что в резюме у них не будет слов "fullstack" и "developer" ;)
Нужен ли индустрии говнокод за немаленькие деньги?
Да там все вместе отличились, по хорошему нужно понимать что ты пишешь и для чего, одно дело писать кусок алгоритма для автомата лампочки в салоне другое о к системе которая выкручивает рули в положение до упора…
Да можно сказать они просто работали по ТЗ, но ИМХО это будет слишком цинично.
P.S. Оставлю за скобками вопрос полезности умения создавать алгоритмы — это предмет отдельного обсуждения.
Ну ок, в сети есть ряд хороших ресурсов с задачками которые можно использовать (и используют много кто) на собеседовании, типа таких: leetcode.com/problemset/all
Задачи хорошо описаны со всеми граничными условиями, их слишком много, чтобы кто-то прорешал их все, а если вдруг прорешал — уже жирный плюс такому кандидату.
Было-бы интересно узнать, изменится ли количество отказов браться за решение если автор попробует какие-нибудь задачки из списка вместо проверки числа на простоту.
Как вы считаете, нужно ли современному программисту уметь разрабатывать алгоритмы?
Я бы ответил "Нет", да не совсем.
Нужно уметь. Нужно знать, что они есть, что можно решать некоторые задачи эффективнее.
То есть да, программисту нужно потратить пару дней времени на алгоритмы.
Но загвоздка в том, что через пару лет работы над обычными задачами и переборами массивов, условно, до 10 элементов, навык работы с алгоритмами неизбежно теряется (тот навык позволяющий сходу решать все эти алгоритмически задачи). И когда программист проходит очередной собес на новую работу — ему приходится готовиться по задачам снова — и это вот тот самый момент, который неправильный.
TL;DR: программисту нужны алгоритмы, но это не должно быть критерием подбора на работу. Блин, нужны на вашей работе алгоритмы — выделите неделю рабочего времени на введение программиста в курс. На поиск "того самого", что подготовился "на отлично" потратите больше. Если он умеет думать, это не будет проблемой.
P.S. Разумеется, если вы пишете компилятор или ещё чего подобного — сюда неприменимо. Но мы же не об этом, верно?
А как проверить, что кандидат умеет думать?
В голову приходят только несложные задачки к которым нужно придумать решение, но именно их и спрашивают в том же Яндексе на технических секциях (это олимпиадные задачки 6-7 классов в основном).
А как проверить, что кандидат умеет думать?
Дебаг, например? Синтезированный пример из реальной проблемы, который нужно продебажить и исправить — это одна из основных причин, зачем вам может понадобиться программист, и это обычно редко решается гуглением SO.
Касательно алгоритмов и умения думать, есть тоже более приближённое к реальным задачам — это оптимизация решений в лоб, динамическое программирование, i.e. мемоизация, кеширование только нужных переменных, вот это вот всё.
Для этого нужно понимать сложность кода (big-O), с этим пониманием обычно приходят решения "как можно код улучшить".
Меня однажды спросили на собесе про динамическое программирование, это был гроб :)
Дана языковая модель, нужно предложить оптимальную расстановку пробелов во входящей строке.
До меня только спустя пару дней дошло, что это задача о разрезании стержня. С тех пор я штук 20 задач на динамику решил, но так и не научился быстро придумывать решение.
В общем мне кажется, что динамика — не лучший способ отбора кандидатов :)
[3,2,5,1,6].sort((a,b)=>a-b)
В 99.99% это и не не нужно.
необходимо реализовать функцию, возвращающую true в случае, если number является простым числом и false в противном случае
Мне на ум приходит только одно решение этой задачи (и оно не совсем верное):
p^2 = n * 24 +- 1;
Квадрат любого простого числа (кроме 2 и 3) равен 24 помноженному на некоторое n плюс/минус 1. Например, для 7 — это 49 (2*24 + 1), для 11 — это 121 (5 * 24 + 1), и т.д.
Но это будет выполнять не только для простых чисел, потому решение не до конца верное.
Но на собеседовании, в любом случае, попробовал бы это:
if (p < 2) return false;
if (p == 2) return true;
if (p == 3) return true;
if (p == 4) return false;
return ( p*p + 1 ) % 24 == 0 || ( p*p - 1 ) % 24 == 0;
Где p — простое число.
p-1 — число стоящее левее от простого на числовой оси, а p + 1 — число стоящее справа.
Оба этих числа делятся на 2, потому что p не может быть четным, одно из этих числе делится на 3, потому что эти три числа идут подряд, и это не может быть 3, а оставшееся обязательно делится на 4, из-за того что числа идут подряд.
Отсюда получаем: 2 * 4 * 3 = 24.
Работает не только с простыми числами, например, можно привести такое: 6 * 24 +- 1 = 143 и 145. Оба варианта не являются квадратами.
Впервые увидел я это в видео на канале Veritasium, но сейчас оригинал видео не могу быстро найти.
Нужно ли современному программисту уметь создавать алгоритмы?