И не очень люблю людей, которые к нему "готовы". По моему мнению, главное на интервью - это понять как человек думает и как решает проблемы.
Если соискатель написал задачу за 5 минут правильно и оптимально, не переписывая в процессе несколько раз код, то... Никакой информации интервьюер не получит. Точнее придётся выбирать между версией, что на интервью бриллиант от программирования. И версией, что человек просто неплохо подготовился, а, возможно, вызубрил задачу наизусть.
Давайте проиллюстрирую на простенькой задаче.
В JS есть функции Math.round() - округление числа к ближайшему целому и Math.floor() - округление числа к меньшему целому. Нужно написать функцию (f) округления положительных чисел к ближайшему целому, используя только Math.floor. Чтобы чуть сократить путь — сразу ставим условие, что нам нужна функция стрелка в одну строку (без создания промежуточных переменных)
Есть очень просто и красивое решение, если соискатель его знает, то всё "плохо". Придётся доставать из загашника что-то ещё. А вдруг там пусто?
Но, пусть нам повезёт, и соискатель "не подготовился". Тогда, скажем, получим:
const f = (x) => x - Math.floor(x) >= 0.5 ? Math.floor(x) + 1 : Math.floor(x)
Огонь! Соискатель знает что такое округление, понимает как получить дробную часть. Если не знает, я не против рассказать. Даже интереснее будет. Кстати, если нет скобок приоритета, как в данном выражении, и соискатель может объяснить почему, это огромный плюс. А если скобки есть, например, так:
const f = (x) => (x - Math.floor(x) < 0.5) ? Math.floor(x) : (Math.floor(x) + 1)
То тут... нет криминала. Я сам, хоть не плаваю в вопросе приоритета операторов, но часто предпочитаю написать лишнюю скобку. И быть уверенным что все сработает так, как я задумал. Всё равно prettier лишние скобки корректно уберёт. А вот если чуть накосячить, то нужные он не поставит.
Но не отвлекаемся. В черновую задачка решена - значит у нас на собесе, как минимум, готовый годный джун. Не точно, но вероятно.
Пробуем повысить до миддла. Задаём вопрос: «А как сократить количество вызовов функции округления?»
const f = (x) => Math.floor(x) + (x - Math.floor(x) >= 0.5) ? 1 : 0
Ок. Тут можно порассуждать: будет ли функция работать с отрицательными числами и почему нет. Ответил? Считаем, что миддл детектед. Опять же не точно, и нам бы, в идеале, нужен сеньор, хотя бы потенциальный. Поэтому усложняем : «А как сделать тоже самое, но с одним вызовом Math.floor?» И можно зависнуть в телефончик минуты на три (ибо вроде никак — нужна промежуточная переменная).
Выждав ровно 180 секунд, как и запланировано, выдаём подсказку: «И без тернарного оператора». Да-да, это подсказка. Даём ещё пару минут, но надеемся, что соискатель ещё не догадался. И предлагаем отложить задачу, а пока решить вот такую:
Написать функцию-стрелку (f), которая принимает на вход либо 2, либо 5 (гарантированно, что ничего другого прийти не может). И возвращает: если на входе 5, то 2, если 2, то 5. Использовать оператор нельзя. Время пошло.
По прежнему нет идей? Хорошо, подсказка: "а что будет, если сложить 5 и 2?"
Не помогает, ладно, упрощаем задачу:
На вход приходит строго 0 или 1, нужно получить соответственно 1 и 0
const f = (x) => +!x
Огонь. Кандидат умеет в идиомы и понимает в конверсии типов (в js префиксный плюс, это устоявшаяся идиома для конвертации в number, кстати, можно и про неё поговорить). Но нам нужно решить эту задачу со знаком минус, то есть с операцией вычитания, на что и намекаем. Если не помогает, что уже скорее грустно, подсказывает, что х надо именно отнять. Вопрос: от чего?
И, внезапно, сверкает лампочка:
const f = (x) => 1 - x
Возвращаемся к задаче 5/2, уже проще? 5 + 2 = 7 значит:
const f = (x) => 7 - x
И теперь у нас есть всё, чтобы решить исходную задачку. Но если и тут туго, можно подсказать, что нужна манипуляция именно в параметрах.Тадам:
Скрыл решение для тех, кто пока не догадался, но хочет таки сам
const f = (x) => Math.floor(x + 0.5)
Красиво же? Теперь снова поговорим о том, будет ли оно работать с отрицательными числами и как это проверить, в той же консоли.
Понятно, что кандидат может догадаться на любом из шагов, а может, в итоге, не догадаться, например, перенервничать. Я в любом случае дам вторую задачу, чтобы проверить уже "неалгоритмические" навыки программирования, а более приземлённые: подготовка маппинга для обогащения, фильтрация, сортировка, обогащение. То, чем я, и миллионы других парней, реально занимаемся на работе: превращаем одни скучные данные в другие, чуть менее скучные.
Но об этом чуть позже, а пока к задаче. Пока мы её успешно решали, я получил много информации. Насколько человеку интересны все эти танцы, как он думает, как он борется с задачей: накидывает идеи, варианты или тупо сидит. Насколько у него загораются глаза. Для меня (и многих "работодателей") более интересен кандидат, который не (сразу) решил задачу, но, при получении решения, искренне восхитился (а что так можно было?), чем тот, кто скучно скажет: "ну это слишком элементарно, и в реальной жизни вряд ли понадобится".
Если честно, в реальной жизни умение решать "алгоритмические задачи" не то чтобы не понадобится, но за 30-летнюю "карьеру", у меня было только одно место работы, где чаще, чем раз в месяц приходилось решать задачи близкие к алгоритмическим. Т.е. задачи, где надо было использовать не рутинные инструменты, чтобы сделать вот такое-эдакое, что раньше не делал (и скопипастить неоткуда). И чтоб оно работало шустро. В среднем, "блистать" в алгоритмике удавалось раз в квартал, а то и реже. Притом, что я большей частью работал "на переднем крае", практически в RnD. Поэтому алгоритмическое мышление важно, но не требуется, чтобы оно было спортивно-алгоритмическим. Т.е. в реальной жизни задача, на которую на собесе выделяется полчаса, может решатся и сутки-двое и бизнес это вполне устроит. Более важно её корректно решить, предусмотрев все кейсы, где что-то может пойти не так (и написав тесты), чем решить быстро, но небрежно, перегрузив тестирование и опять же потратить ещё и своё "сэкономленное" время на правки ошибок.
Поэтому на собеседовании не надо бояться, что задача идёт туго, нужно просто планомерно искать решение: умный интервьюер этого и добивается, а глупый... Ну что-то мне говорит, что не очень хорошая идея работать в коллективе, где все прошли через фильтр глупых интервьюеров. Если мне на собеседовании попадается задача, которую я знаю, я сразу говорю: "О! А я её на собесе яндекса решал: тут надо не постесняться сразу отсортировать массив, а дальше сложность только в ...". Интервьюер может сразу перейти к запасному аэродрому, а может поговорить о задаче, попробовать усложнить условия, спросить ошибался ли я при решении и где.
И это тоже важно: ваши ошибки, то как вы их исправляете, как дооптимизируете код. Да, в реальной жизни, бывает что пишешь сразу из головы красоту - прям в учебник. Но бывает, что вообще не ничего не придумывается, пишешь какую-то хрень "в лоб", просто чтобы куда-то продвинутся. В итоге вымучиваешь лютую страхозябру, которая, возможно, и работает, но в продакшн её запускать страшно (она же там всех покусает). Но смотришь на неё и видишь, что тут можно и оптимизнуть. Пару десятков раз переписываешь код и всё: всё понятно и всё работает. И вообще кажется, что по другому как-то и не получится. Да, дорогой джун, если ты читаешь этот текст, то знай, что сеньоры тоже жёстко говнокодят. Просто потом прибираются, но не обязательно.
И в реальном энтерпрайзе редко заморачиваешься, например, производительностью. Местами обосновано. Если у тебе n редко больше 10, а в среднем вообще n=1, то выбор между алгоритмами O(n log n) и в O(n3), только в том, какой легче написать, протестировать и поддерживать. Вот Microsoft со своей пузырьковой сортировкой иконок не даст соврать. Да плохой пример, но начальство любит больше того, кто за 15 минут выдаст код O(n2), чем того, кто неделю потратит на O(n log n), для списка выпадашек дропдауна. Есть области, в которых оптимизация чуть менее чем всего, необходима чуть реже чем всегда (например, игры), но 90% общего по миру кода, можно (и выгоднее) не оптимизировать. И да, это тоже часть работы, умение понимать, где надо, а где совсем нет.
И последнее (и закругляемся). Умение в алгоритмические задачи на пятерочку с плюсом, хорошо для джунов, и где-то миддлов. Видно, что человек заморачивается, прокачивает себя. И для сеньоров на позиции чистых RnD алгоритмистов - это их хлеб. А обычный сеньор, который оказывается звездой на letitcode вызывает вопросы. Когда он нашёл время на все эти задачки? И почему он хорошо помнит их решения (я вот несколько раз на собесах писал что-то по красно-черным деревьям, но дай мне задачу снова - снова буду тупить, решу, но буду тупить по ходу). У него много свободного было времени на прошлой работе? А работа? Дома? А не проще было что-то полезное пописать, не придумал свое - вон можно можно было в Линуксе до мантейнера дорасти.
Вывод: не надо бояться "сессии кодирования", там больше оценивают, что как вы думаете, а не что вы знаете. Плюс, предлагают вам интересные задачки, практически развлекают вас за их же деньги. Да "на встречу со звездой надо приходить подготовленными", но больше важно иметь представление о принципах и инструментах, чем об конкретных решениях.
Удачи на собесах. Обоим сторонам.
Комментарии (148)
panzerfaust
11.11.2024 05:42И в реальном энтерпрайзе редко заморачиваешься, например, производительностью
Смотря что энетпрайзить. Трейдинг и телеком - там постоянно речь о массивах или потоках данных. Но литкод там помогает примерно никак. Реально полезный навык - это уметь оценить О-большое не одной функции, а цепочки функций или целого модуля. Ну и улучшить, само собой. Литкод этому не учит. Только практика, только чтение и рефакторинг тысяч строк всратого кода.
mclander Автор
11.11.2024 05:42Согласен. Я больше про интерфейсные вещи (со стороны фронта) и данные для тех же интерфейсов со стороны бэка. В 90% там очень небольшие объёмы.
Типичная задача фронта оценить два источника, один из которых надо обогатить вторым. И есть две стратегии, подготовить маппинг по второму источнику, либо тупо в цикле по первому делать поиск по второму. Я правда не парюсь и в 90% пишу маппинг, благо это одна строчка на "современном" js, но и вторая стратегия не криминал, особенно если значений 2-3 и там даже непонятно что быстрее поиск по ключу или тупой перебор)
sshmakov
11.11.2024 05:42const f = (x) => Math.floor(x) + (x - Math.floor(x) >= 0.5) ? 1 : 0Хорошо подумали?
mclander Автор
11.11.2024 05:42Думал дольше провисит. Вопрос, что именно тут не так? )
sshmakov
11.11.2024 05:42К кому вопрос? Мне это очевидно, вам тоже.
mclander Автор
11.11.2024 05:42Да это же база(с)
Приоритет ? самый низкий, я не случайно рассуждаю в абзаце выше про скобки
Но если честно, сперва написал неправильно. Перед публикацией, на всякий случай, прогнал по всем выражениям тесты. И сильно удивился, что не так. Выражение глаза резало, но почему догадался не сразу. Решил, что не буду править )
gudvinr
11.11.2024 05:42Если соискатель написал задачу за 5 минут правильно и оптимально, не переписывая в процессе несколько раз код, то... Никакой информации интервьюер не получит.
Это уже проблемы интервьюера, который зачем-то даёт задачи, которые ни о чем не говорят.
Но на самом деле их дают не для того, чтобы увидеть людей, которые круто решают задачи, а для того, чтобы отсеивать людей, которые такие задачи не решают.
И такую цель они решают, наверное, неплохо. Если вы стартап, и поток кандидатов не очень большой - это конечно довольно глупо. А если у вас на каждую вакансию очередь, то в принципе и ок.
mclander Автор
11.11.2024 05:42Если человек выучил решение задачи - это не значит, что он её решил. И тем более, не факт, что её решил бы.
saboteur_kiev
11.11.2024 05:42Для меня (и многих "работодателей") более интересен кандидат, который не (сразу) решил задачу, но, при получении решения, искренне восхитился (а что так можно было?
Это да.
Причем при наличии современного гугла и даже бесплатного чатгпт, можно сидеть и ковырять решение. Человек у которого логика работает, даже без образования докопает в нужную сторону и выдаст надежное решение, если не идеальное. Потому что не просто взял первое рабочее решение с инета, а доколупался до того, как оно работает и уже аргументированно выбрал вариант.
А для этого да, нужно чтобы человеку было интересно копнуть и соображалка работала.
gudvinr
11.11.2024 05:42Ревьюверы в таких случаях смотрят не на то, что человек решил. Решил - ок, молодец красавчик, но это вообще не важно.
Ревьюверы смотрят на то, что человек не решил. Если не решил - пока прощай.
Это просто инструмент по сужению воронки найма.
Koyanisqatsi
11.11.2024 05:42Всегда думал, что нельзя проверять на равенство числа с плавающей точкой. В C/C++ это UB, а в JS как?
qweururu
11.11.2024 05:42Нет, не уб. И в жс тоже. Это какое-то помешательство массовое, что угодно называть уб?
Koyanisqatsi
11.11.2024 05:42Ниже правильно прокомментировали: ">=" нормально, но "==" в С/С++ точно UB, даже компилятор предупредит об этом.
qweururu
11.11.2024 05:42Нет, точно не уб. Нужно хотя бы минимально изучить тему, перед тем как рассуждать.
Причём в этом случае даже изучать ничего не нужно. Логика элементарная: если fp == fp всегда уб, то в чём смысл существования op==? Это уже должно наводить на мысли.
Koyanisqatsi
11.11.2024 05:42А какой смысл существования флага
-Wfloat-equalв компиляторах С/С++? Чтобы подсветить в предупреждениях все случаи проверок на равенство в коде.qweururu
11.11.2024 05:42Так это вы должны пояснять, каким образом из наличия предупреждения вы сделали вывод про уб.
Я так понимаю, несовместимость пердыдущими ревизиями C++ это тоже ub? Ведь есть -Wc++11-compat. А зачем тогда нужны -Wno-...? Чтобы отключить уб? Уровень поражает.
Koyanisqatsi
11.11.2024 05:42Не очень понимаю, какой и чего уровень вас поражает, но это факт - проверка чисел с плавающей точкой на равенство это как минимум небезопасно.
Советую ознакомится с интересной статьей, правда про пайтон.
vadimr
11.11.2024 05:42Проверка чисел с плавающей точкой на равенство часто работает не так, как ожидается программистом с недостаточными знаниями, поэтому маркируется предупреждением. Но всякое число с плавающей точкой, кроме семейства nan, гарантированно равно самому себе.
NickDoom
11.11.2024 05:42Это явно проблема недостаточности знаний программиста… хотя избыток выпендрёжа тоже вредит, я вот активно использовал NaN, чтобы преднамеренно маркировать результаты, которые мы при имеющихся входных данных рассчитать не можем. Предельно логично, но каааак оно тормозиииит :(
Работать с этими результатами дальше оно не мешало, в любом случае надо держать в голове возможность прилёта на вход NaN (дело было на плюсах). Максимум — немного дисциплинировало в этом плане. А вот в плане быстродействия это был просто злодейский поступок :) Не такой, конечно, как M$-овские курсоры, сжирающие половину проца на мигание, но уверенный шаг в эту сторону :-/
Хотя я и с памятью в том проекте так же обращался. Шёл на любые мерзости, лишь бы потом не упереться в границы расширяемости и не рефакторить :-D Всё равно получилось на порядок быстрее и стабильнее практически точного клона, переписанного на модных «безопасных и стабильных» языках. А для самых ходовых случаев прикостылил сжатие :-D
qweururu
11.11.2024 05:42Ну как чего уровень. Уровень экспертизы вида "есть предупреждение значит уб". Какой уровень - нулевой.
Впрочем, само по себе это даже не является чем-то плохим. Многие ошибаются, многое не известно. Но если человек декларирует какое-либо мнение - он его защищает/аргументирует. Как минимум показывает каким образом он к озвученному выводу пришёл. А далее оппоненты уже могут указать на ошибки/привести контрпримеры, которые опровергнут вывод. В таком случае ищется новая теория/объяснение, лишённая ошибок/противоречий.
Что имеем в данном случае? Просто отказ от первоначальной позиции и переключение на другую тему. Тепер это уже просто небезопасно, а не уб(хотя ранее было заявлено "точно уб"). Это меня более всего удивляет.
Koyanisqatsi
11.11.2024 05:42Я согласился с другим комментатором, что ">=" не является проблемой, но продолжаю настаивать, что именно проверка на равенство плохая идея. При работе с double или float вы теряете точность, поэтому результат вычислений может быть близок к чему-либо, но не всегда равен. Возможно вы имеете в виду работу метода
Math.floor(x), про который я не знаю, но который точно возвращает число без дробной части. Но я беру общий случай, что после каких-либо вычислений сравнивать числа с плавающей запятой через == нельзя.
Если вы не знали про такую особенность флоатов, то именно ваш уровень экспертизы нулевой, может тут и вся статья неправильная...qweururu
11.11.2024 05:42Я согласился с другим комментатором, что ">=" не является проблемой, но продолжаю настаивать, что именно проверка на равенство плохая идея.
Про "не является ub" согласились? Нет. Ошибку признали? Нет. Остальное к теме не относится, я спрашивал про ub.
Koyanisqatsi
11.11.2024 05:42Видимо вас задел термин UB. Если что-то не UB, но если я воспользуюсь этим, то результат ХЗ, то это UB.
Раз уж вы решили написать статью, а у вас что-то спрашивают, то, думаю, не стоит быть настолько грубым. Если вы думаете, что я трачу ваше время, то не отвечайте совсем, чем так.
Uprt
11.11.2024 05:42Если что-то не UB, но если я воспользуюсь этим, то результат ХЗ, то это UB.
Вообще нет. UB - это очень специфический класс ошибок, описанный в стандарте языка. Целочисленное сравнение к UB, согласно стандарту, не относится, оно, как уже сказали, очень даже defined:
If both of the operands have arithmetic type, the usual arithmetic conversions are performed. Values of complex types are equal if and only if both their real parts are equal and also their imaginary parts are equal. Any two values of arithmetic types from different type domains are equal if and only if the results of their conversions to the (complex) result type determined by the usual arithmetic conversions are equal
То есть язык дает определенные гарантии и предсказуемость результата.
Давайте все-таки использовать общепринятую терминологию, а не выдумывать свои значения для существующих терминов.
playermet
11.11.2024 05:42Эмм, нет. Undefined Behavior это конкретный термин из конкретных языков программирования, который специальным образом обрабатывается компиляторами, для чего он собственно и введен. Компилятор C/C++ исходит из того, что в программе не может быть Undefined Behavior, что позволяет ему для оптимизации игнорировать все инварианты в которых он возникает. Если бы == для FP был Undefined Behavior, компилятор мог бы просто удалить весь код который зависит от вычислений в которых он встречается под предлогом "так быстрее". При этом последствия для программ полагающихся на код с UB могут быть какими угодно, в шутку говоря хоть динозавр из монитора вылезет.
qweururu
11.11.2024 05:42Меня задел изначальный тезис(точнее явление, в рамках которого подобные тезисы существуют). Если бы это была своя трактовка - пояснения были бы сразу же, а не далее на манер "я не это имел ввиду". К тому же, даже эти пояснения также не являются верными.
Кстати, признания ошибки до сих пор не последовало, хотя выше были попытки изображать объективность(там, про >= - "я признал, я рассуждаю объективно") - очередные свитетельства.
Далее пошли обычные отмазки вида "мне грубят" и прочее - мне лень на это отвечать.
NickDoom
11.11.2024 05:42Для начала надо ответить себе на вопрос, чего вообще пытается добиться наш горе-программист, сравнивая (на сях, раз о них заговорили) какой-то результат вычислений с чем-то ещё. Калякать код, не представляя, что за этим стои́т с точки зрения здравого смысла — это даже не смешно.
А ответив на вопрос, «что и зачем я сравниваю», можно получить выводы от « == или fabs(Diff)<.000001 » до «да чёрт же ж, тут весь алгоритм надо на фиксированную точку переделывать и следить, чтобы разрядности хватало без перескоков работать».
Хотя у меня был ещё похабный случай «дабла тут хватит, у нас никогда хвосты не добегут до младшего разряда». Не делайте так :) это я охамел :)
vadimr
11.11.2024 05:42О! А расскажите, пожалуйста, подробнее про последний случай. Хотя теоретически это можно себе представить, но на практике ведь результаты любых физических измерений менее точны, чем дабл. Как так получилось?
NickDoom
11.11.2024 05:42На входе было что-то типа fixed point 16 bit, а проверить надо было что-то типа «попадает ли точка на отрезок» (ну или что-то похожее). Не помню, что именно, но там было что-то вроде пары умножений того на это, а этого на то, после которых не могла длина числа достичь длины дабла, то есть по факту вся эта геометрия была не плавающей, а пиксельной (даром что в дабле лежала) и понятие «попадает/не попадает» там имело смысл, в отличие от бесконечно точных измерений :)
Я пальцем потыкал в вычисления, прикинул, насколько может удлиниться хвост и могут ли возникнуть ошибки округления, заменил флот на дабл (флота не хватало) и забил на эту проблему, так оно и работает лет эдак полтора десятка :)
Вообще такое, конечно, надо обильно обкладывать камментами, ибо вдруг кто-то прочитает и решит, что это нормально :) а потом будет какой-нибудь Бидон крестовым походом на сишников идти, мол, код у них небезопасный %)
vadimr
11.11.2024 05:42Спасибо! Неправильно понял смысл Вашего предыдущего комментария и подумал, что вам не хватило дабла. Удивился. С другой стороны, зачем-то ведь придумали четырёхкратную точность. Пытаюсь понять.
NickDoom
11.11.2024 05:42Поэтому и надо обкладывать камментами насчёт очень узких границ применимости. А то кто-то «улучшит точность» на входе — и всё посыплется.
vadimr
11.11.2024 05:42Даже если это среднее значение, то у него устраняется только случайная погрешность, но не систематическая. Поэтому по идее оно никак не может превосходить точность самых точных физических измерений, которые ограничиваются 14 цифрами.
qweururu
11.11.2024 05:42Лень гуглить про упомянутые виды погрешностей, поэтому просто пример - это должно помочь понять ситуацию.
x / 2 - уже нужен дополнительный разряд для сохранения точности. Ну если там не нули на конце - но это типа предсказать в большинстве случаев нельзя, поэтому мы не можем на подобное опираться. И это только одна операция.
То есть, с точностью начальных значений оно связано, но эта начальная точность - не единственный фактор. Как минимум, нужно учитывать ещё и количество операций наподобие деления.
vadimr
11.11.2024 05:42x/2 в формате числа с плавающей точкой IEEE-754 имеет ровно такую же точность, как x (если вообще представимо нормализованным числом). Это происходит благодаря нормализации.
Ни одна арифметическая операция над вещественными числами с плавающей точкой, кроме умножения на константу 0, не может повысить точность.
Ваш аргумент ещё можно понять в том смысле, что, например, значение 1/3 точно не представимо, и чем больше цифр, тем выше точность. Проблема, однако, в том, что 1/3 – это математическая абстракция, не отвечающая ничему в физическом мире.
qweururu
11.11.2024 05:42x/2 в формате числа с плавающей точкой IEEE-754 имеет ровно такую же точность, как x
Да, не верный пример был. Но суть должна быть понятна. Вместо / можете рассмотреть sqrt, log.
Ни одна арифметическая операция над вещественными числами с плавающей точкой, кроме умножения на константу 0, не может повысить точность.
fp не терял бы точность, если бы это было так. Ну и конечно же классическое 1e100 + 1e-100 - даже на сложении точность поплыла.
1/3 точно не представимо
Я не стал про это писать, как про очевидный момент.
Проблема, однако, в том, что 1/3 – это математическая абстракция, не отвечающая ничему в физическом мире.
Любые числа - это абстракция. Но флоат/дабл именно эту абстракцию и представляют, поэтому к чему этот довод?
NickDoom
11.11.2024 05:42Как минимум, нужно учитывать ещё и количество операций наподобие деления.
Там вроде всё удалось привести к общему знаменателю и избавиться от деления. Вообще в таких задачах избавляться от деления — вещь первоочередной значимости, если это возможно (а тут, опять же, надо понять, чего мы считаем; если это, скажем, соотношение отрезков в 3D-рейкасте, то от деления не уйти, и надо ограничить, допустим, рассматривание стенки героем до некоей ненулевой величины).
Но вообще «первое слово дороже второго» — «решение похабное, не делайте так». Там надо было перевести всё в буквальные целочисленные вычисления с буквальными пикселами, где царствует int 64. Дабблы, даже тщательно обложенные камментами — похабень.
Тем более, что оно бы ещё и в скорости прибавило (это был боттлнек, поэтому и сравнения там были максимально быстрые, то есть через « == »). Но в какой-то момент лень победила, работает — всё, забил :-/
qweururu
11.11.2024 05:42Там вроде всё удалось привести к общему знаменателю и избавиться от деления.
Вы про конкретно свой случай? Я в общем отвечал, типа зачем что-то большее дабла.
Вообще в таких задачах избавляться от деления — вещь первоочередной значимости, если это возможно
Думаю, это больше по иным причинам, не из-за точности.
NickDoom
11.11.2024 05:42Пардон :) Я действительно весьма двусмысленно выразился насчёт похабности этого случая :)
Ну что поделаешь — это был пример UB в естественных языках :-D :-D :-D
WASD1
11.11.2024 05:42С другой стороны, зачем-то ведь придумали четырёхкратную точность. Пытаюсь понять.
4-кратная точность увеличивает как размерность мантиссы так и экспоненты.
Есть 2 разных проблемы:
1. Недостаточная точность fp-вычислений (начиная со "сложить массив с минимальной ошибкой" и заканчивая "решение плохо обусловленных дифуров").
2. Переполнение fp-value.Переполнение fp-value довольно специфический случай, который нужен 1.5 человека.
А вот накопление неточности - это довольно сложный случай, с которым бороться софтварными методами можно лишь ограниченно и рано или поздно вам просто захочется иметь больше бит мантиссы.
https://en.wikipedia.org/wiki/Floating-point_error_mitigation
vadimr
11.11.2024 05:42Согласен, не подумал про плохо обусловленные уравнения и другие случаи сдвига мантисс друг относительно друга.
Uprt
11.11.2024 05:42Вы путаете undefined behavior и unspecified behavior.
playermet
11.11.2024 05:42Оператор == для чисел с плавающей точкой и defined, и specified. Загвоздка лишь в точности самого полученного значения с плавающей запятой. У FP неассоциативные операторы, накопление погрешностей, и невозможность точного представления конкретных чисел.
NickDoom
11.11.2024 05:42Вспоминается мне какой-то ассемблерный трюк с «Сахары», где байт со старшими битами мантиссы копировался в остальные байты мантиссы, то есть получалось только 256 возможных значений мантиссы — использовалось именно для того, чтобы «прибить к сетке» значения (обычно такое делается в гуях для комфортного восприятия глазами какого-то вывода данных).
mclander Автор
11.11.2024 05:42На равенство плохая идея, на >= почему нет? Есть ещё приём проверка на чистое равенство с допуском, но тут он не нужен.
killyself
11.11.2024 05:42Это не уб, просто есть шанс неправильно сравнить 3.0 и 3.00000002. Если мы уверены, что не получим на вход "плохое" число (например, они идут из поля ввода с жесткими 2 знаками после запятой), то ничего страшного если сравнивать напрямую. В противном случае, нужно использовать ε равенство
NickDoom
11.11.2024 05:42Как-то так. Как я выше говорил — герою этой воображаемой ситуации надо бы просто задумываться, что, зачем и на предмет чего именно он сравнивает. Тогда он поймёт, нужен ли критерий «попадает в тот же пиксел» (отклонение меньше половины), «является тем же самым числом» (тут надо сравнить напрямую) или что-то «ещё более третье».
И если у кого-то си виноват в том, что человек не задумывается над смыслом своего писева, то у меня для них плохие новости :)
ALapinskas
11.11.2024 05:42Написать функцию-стрелку (f), которая принимает на вход либо 2, либо 5 (гарантированно, что ничего другого прийти не может). И возвращает: если на входе 5, то 2, если 2, то 5. Использовать оператор нельзя. Время пошло.
Алгоритмические задачи превращаются в какие-то задачи-ребусы. На собесе в Яндекс я недавно, типа таких встречал, они, вроде как, на знания языковых конструкций, но на деле просто сбивают с толку, по сути - бессмыслица, на letcoode и coderun такие задачи не встречаются.
mclander Автор
11.11.2024 05:42Оцените минимальное число углов у многоугольного люка, при котором он ведет себя как круглый?
Я недавно собеседовался в яндексе, одна задачка была похожа на реальную, вторая притянута за уши. Зато имела очень красивое решение. Я бы в лоб написал решение раза в три длиннее, но интервьер мне упорно не давал это сделать вытаскивая именно на решение "по красоте"
ALapinskas
11.11.2024 05:42В чем именно ведет себя как круглый?
mclander Автор
11.11.2024 05:42Не-не, так слишком просто )
ALapinskas
11.11.2024 05:42Похоже на задачу триангуляции круга, при отрисовке. Минимальное, я думаю будет, больше 4, т.е. 4 угла - это прямоугольник, 5 - это многоугольник, похожий на круг, и чем больше углов далее - тем он больше будет походить на круг.
В идеале, нужно найти баланс между тем чтобы многоугольник(круг) не был визуально угловатым и количеством операций(углов), чтобы программа не тормозила.
mclander Автор
11.11.2024 05:42Я вообще-то пытался в стёб над задачами (совместить заезженную задачу с математикой), но по ходу провалился ( Либо вы умеете в тонкий троллинг))
Если вспомнить, что у круглого люка два качества - легкость перемещения, его можно легко катить и, более важное непроваливаемость. То углов очевидно должно быть 20+, чтобы катить можно было. А чтобы не проваливался надо знать диаметр канта и диаметр люка, тогда можно будет (как-то) рассчитать минимальную ширину люка при минимальном n, большую чем диаметр канта.
Для особых задротов можно предположить, что кант будет тоже многоугольным, и тут уже математика, к которой вот я лично не готов ) Зато можно же в перебор - вот и алгоритмическое решение подъехало.
sdramare
11.11.2024 05:42Люки круглые потому что производить круглые металические болванки проще чем многоугольные, по этой же причине и остальные предметы из металла, типа монет, тоже изначально круглой формы. Отстальное все это фантазии. Когда техпроцесс позволяет люки делают какой угодно формы и никого не беспокоят проблемы проваливающейся крышки или необходимости зачем-то эту крышку катить.
mclander Автор
11.11.2024 05:42Это в странах с готическим шрифтом они не проваливаются. У нас лучше всё-таки в круглые.
AdrianoVisoccini
11.11.2024 05:42Идея для научной статьи: Корреляция между частотой использования засечек в типовых шрифтах и количеством травм полученных при падении в люк...
Dmitry_604
11.11.2024 05:42подозреваю что там более широкая ступенька сделана чтобы люк по диагонали таки не провалился. Иначе думаю проектировщика быстро проклянут работники предприятия своими готически-католическими проклятиями :)
AdrianoVisoccini
11.11.2024 05:42так и есть, и я никогда не понимал людей которые говорят "а вот круглый не проваливается" ведь и там и там нужно сделать бортик в любом случае. Не так уж и сложно рассчитать размер бортика для квадратного люка так, чтобы диагональ у бортика была меньше чем сторона у люка.. Вроде как соотношение диагонали к стороне вообще константная величина
mclander Автор
11.11.2024 05:42А что там считать: примерно 20.6% от стороны люка минус 69% от его толщины.
sshmakov
11.11.2024 05:42он на шарнире, его невозможно открыть иначе, чем по стрелочке с надписью "Open"
mclander Автор
11.11.2024 05:42И мне казалось, что люки отливают, а не пилят из болванок, а потом ещё и гравируют...
sdramare
11.11.2024 05:42Вам его еще надо шлифовать, да и чтобы отлить надо сделать форму. Какую форму для отливки сделать проще(дешевле) - круглую или прямоугольную?
AdrianoVisoccini
11.11.2024 05:42вы так говорите, как будто это риторический вопрос и ответ всем очевиден.
так какую легче отлить? а почему? а дешевле?sdramare
11.11.2024 05:42Попробуйте сделать в куске гибса круглое отверстие, а потом квадратное. Желательно сверло уаттса не использовать.
AdrianoVisoccini
11.11.2024 05:42при чем тут гипс и сверло? По вашему форму под отливку метала сверлят? Ну я вот собственно к этому и поднял вопрос - вы очевидно не эксперт в литье при этом рассуждаете как будто понимаете что-то
MaFrance351
11.11.2024 05:42Кстати, у нас иногда встречаются и вот такие люки:
Конкретно этот видел вообще у себя в районе. Само собой, такой в принципе сложно заставить провалиться. Но почему-то очень редко их видел.
playermet
11.11.2024 05:42ИМХО дело не в простоте производства, а банально в том что у круглого люка заметно меньше площадь, а значит и объем требуемого материала.
Alexandroppolus
11.11.2024 05:42Крышка не проваливается в люк, видимо. Но тут надо знать диаметр люка и крышки.
Abstraction
11.11.2024 05:42Я всегда понимал эту задачу как упражнение на рефлексию над моделями. Достаточно ли того упрощения реального люка которое у меня в голове? Какие особенности я забыл?
Реально я видел и квадратные
люкикрышки, и я довольно сильно ожидаю что даже такую крышку в закрываемое ей отверстие вы нарочно-то замучаетесь просовывать, с шестиугольной миссия становится практически невыполнима (потому что а) крышка толстая и б) она закрывает люк потому что размер дырки меньше размера крышки, она лежит на "полочке"; численное соотношение между этими параметрами при котором задача для шестиугольника становится нерешаемой даже теоретически читатель может вывести самостоятельно, для люка метрового диаметра это единицы сантиметров).
NickDoom
11.11.2024 05:42…а ещё бывают допуски литья и самая злая ситуация — крышка пролетела метр-полтора и вклинилась наглухо, а автокран подъехать не может. Усилие её выдирания сами можете представить, если хоть раз работали с такими массами.
Поэтому в третий раз вынужден повторить — программист должен понимать смысл того, что, с чем и зачем он сравнивает :-D
Был случай — человек на полном серьёзе боялся остатка от деления 1000000000 микросекунд на три, типа, накопится и мы рассинхронизируемся. При этом данные шли с другого девайса и он это знал.
Когда я покрутил пальцем у виска и спросил, в курсе ли он про достигнутую на современных кварцевых генераторах точность, до него дошло %) Когда он понял, что, с чем и зачем он сравнивает — сразу же добавил все нужные алгоритмы коррекции, поправки и ресинхронизации, и всё у него заработало :) Они у него были под рукой, просто он в нужный момент не задумался о смысле того, что пишет %)
Собственно, вот и вся проблематика отрасли. И никакие Расты тут никаким боком не валялись.
wataru
11.11.2024 05:42Завист от того, в чем именно "как круглый". Чтобы его было легко катить, углы при вершинах должны быть достаточно большие. Но тут нет четкой границы - чем больше вершин, тем больше угол, тем легче катить. Из бытового опыта кажется, что 20 угольник уже будет достаточно круглым. 5 угольник - точно нет. 10 угольник - наверное да.
Чтобы люк внутрь не проваливался, как круглый, надо, чтобы разница между диаметром люка (2 наиудаленнейшие точки) и наименьшим сечением была минимальна, меньше толщины люка. Ну, это примерно, потому что если рассматривать люк сверху у него сечение будет прямоугольник и надо чтобы он в N-угольник не пролазил. Еще надо учесть, что дырка из под люка на самом деле на сколько-то процентов меньше люка, он же на каких-то краях лежит.
Тут надо нарисовать N-угольник и подумать. Кажется, минимальное сечение - это высота из вершины в противоположную сторону (или высота между противоположными сторонами для четного N). Диаметром будет или расстояние между противоположными точками для четного N, или ближайшая хорда (разделяющая (N-1)/2 и (N+1)/2 вершин). Можно вывести формулы там будут какие-нибудь косинусы каких-нибудь Pi/2N и какая-то штука должна быть меньше ширины люка. Тут еще где-то будет фактор уменьшения дырки под люк.
opimandb
11.11.2024 05:42Вы считаете количество вызовов floor в строке кода, а не в рантайме выполнения?
Тогда надо бы это проговорить, а то первое что в голову приходит - избавиться от двух вызовов в рантайме и написать что-то вроде этого:const f = (x) => x % 1 >= 0.5 ? Math.floor(x) + 1 : Math.floor(x)
или вообще так
const f = (x) => Math.floor(x + (x % 1))
Без такого уточнения, не сразу понял как вы так сократили "вызовы" floor в переписанном (не обращая внимание на нехватку скобочек) и почему я один негодую, а комментарии молчат по этому поводу)
mclander Автор
11.11.2024 05:42Огонь! Я и не знал, что так можно. Думал что остаток только для целых чисел (c-шник детектед)
Но статью вы на момент комментирования до конца не дочитали )
А вот так работать не будет, но вы близки)
const f = (x) => Math.floor(x + (x % 1))
playermet
11.11.2024 05:42Первое можно еще чуть упростить. Сначала уберем дублирование floor.
const f1 = (x) => Math.floor(x) + (x % 1 >= 0.5 ? 1 : 0)А теперь воспользуемся неявным приведением булеана к числу.
const f1 = (x) => Math.floor(x) + (x % 1 >= 0.5)Второй пример нужно починить:
const f2 = (x) => Math.floor(x + (x % 1 >= 0.5))Но для отрицательных чисел оба способа работать не будут.
mclander Автор
11.11.2024 05:42Если бы соискатель написал бы % - я бы сказал, что его тоже нельзя ) Мне нужно прийти именно к безтернарному виду. По крайней мере без тернарника вне параметров Math.floor
Для положительных и отрицательных правильно
const f1 = (x) => Math.floor(x + (x >=0 ? 0.5 : 0.50000000000000005551115123125782702118158343))
VYudachev
11.11.2024 05:42Огонь! Соискатель знает что такое округление, понимает как получить дробную часть.
Эм... А в чем тогда проблема начать с того, чтобы взять и спросить, что вы знаете про арифметику с плавающей запятой? Тут же разговаривать, при желании, можно дольше, чем в пресловутом вопросе про что происходит после ввода url. Я не про то, чтобы заучивать наизусть IEEE 754, а про то, какие чудеса начинаются, когда в конечное количество битов нужно попытаться запихнуть множество, которое бесконечно и непрерывно. Неассоциативность (в общем случае) операций, положительный и отрицательный нули и много чего еще.
mclander Автор
11.11.2024 05:42У меня был начальник, который любил задачу для собеса, в которой надо было работать с остатками. И я сам бы удивлен, что задачка такая простая, когда сам проходил собес. И ещё больше тем, что половина кандидатов на сеньорскую (!) позицию не знала как взять остаток нативно или хотя бы с помощью функций округления.
Но и задавать вопрос соискателю про его, возможно, вопиющую некомпетентность в лоб не очень хорошая идея. Да и практические навыки чего бы не проверить?
sshmakov
11.11.2024 05:42Когда на собеседовании постепенно повышаешь сложность задач, что бы увидеть, на каком уровне кандидат "поплывет", есть неплохой шанс самому "поплыть" раньше кандидата. Например, когда кандидат даст решение, о котором ты еще не подумал.
Так что подобное собеседование больше похоже на мальчиковую игру меряться длиной (фокусного расстояния объективов).
vadimr
11.11.2024 05:42Так это ж хорошо, если сам поплыл раньше кандидата. Надо брать.
Dmitry_604
11.11.2024 05:42Не всегда, а может случайно попал в одну из немногих тем где собуседуемый более экспертен. Хотя это уже неплохой показатель о кандидате, факт.
AdrianoVisoccini
11.11.2024 05:42Не первый раз уже пишу эту телегу, но если алгоритмы даже по мнению автора не дают нужной информации - так может и не нужно?
У меня есть готовое решение для этой задачи, вот как придется(если недайбог придется) участвовать в найме, то обязательно применю:
(пишу для своей специальности джава бекенда но уверен все читающие умеют в экстраполяцию)Берем и делаем проект в схожей тематике с рабочим, но очень сильно упрощенный. Докер, База, что вы там ещё юзаете, апи, контроллер, сервисный слой, горстку сущностей и пару базовых функций. Например для условного банка можно сделать абстрактный кошелек который умеет делать deposit, withdraw, createWalled, deleteWallet ну и ещё пару функций придумайте по своей специфике проекта.
На интервью берем значит человека, кидаем ему сслку на гит и говорим сделай git clone. Открывает проект, поясняем ему как его запустить если есть специфика а дальше...
1) просим рассказать что за проект, как он работает, полазить по файликам и покоментировать что он видит. На этом моменте можно будет полнейших нулей сразу выкинуть2)даем рандомную придуманную на ходу задачу - добавить ручку, для ручки сущность, для сущности миграциию в базу, и в сервис метод который будет делать то да сё. Не нужно ничего усложнять, пусть задача будет на 15 минут. Если человек сразу теряется и не понимает что делать - ну это джун, его за ручку можно вести и пояснять что да куда писать и в процессе понять нужен такой или нет. Если мидл, он сразу сориентируется и быстро всё накидает, там можно в процессе всяких корнеркейсов накидать, чтобы проверить знает ли он кто такие эти ваши уровни пропагации транзакций и все ли у него будет ролбекаться
3)Можно прошлые решения других собеседуемых просить зарефачить/задебажить итдИ при этом всем можно прямым текстом сказать - гуглить можно прям при мне, можно в чат гпт запросы закидывать и вообще все что хочешь делать. Именно так человек работать в реальности и будет и именно это и стоит проверить.
в процессе вы будете видеть - а человек вообще понимает как проект строится? Быстро ориентируется в коде, читать то умеет? Знает как функционал внедрять? А гитом как пользоваться, клонировать, ветки создавать, коммиты оформлять.ну и собственно если человек все это понимает и может выполнять задачу идентичную реальной, то его можно смело брать и не тратить время на следующих 10 кандидатов
такой подход решает все проблемы интервью и их хакинга кроме разве что одной - если за кандидата кто-то другой пройдет или наговорит ему в наушник, ну тут уж ничего не поделаешь. Зато, такое интервью избавляет вас от "100 золотых вопросов по %language_name% от ложноотрицательного результата по тому что человек просто в стрессе не смог алгоритм решить. С другой стороны дает понимание - как человек реальные задачи решает, как он код пишет и структурирует, какие инструменты использует, умеет ли гуглить нормально и искать быстро, хоткеи использует? функции ide? как вообще задачу обсуждает, задает ли уточняющие вопросы, видит ли проблемы в ТЗ или сразу прет напролом не включая голову. В процессе можно с ним пообсуждать(не дрочить, а обсуждать) теорию - как он применяет, что он применяет, как его решение будет под нагрузкой работать, нужно ли такое сложное если нагрузки не будет итд итп.mclander Автор
11.11.2024 05:42Я обычно примерно так и делаю, даю кандидату кусок говнокода (с правильным-то каждый сможет) и прошу рассказать, что он делает. У меня был в Сбере был отборный пример. Если его переписать по феншую, то он в 3 раза будет длиннее, а так все умолчания делали именно то, что надо. Жаль не догадался при уходе скопипастить.
Но если играть в задачки, то мои мысли выше)
Abstraction
11.11.2024 05:42И в реальном энтерпрайзе редко заморачиваешься, например, производительностью.
Моё развлечение прошлой недели: попытки отлаживать код, исполнение которого занимает 18 часов. После пары часов медитации с инструментами анализа, без изменения базового алгоритма, время уменьшается до 75 минут. Да, это относительно экзотичный сценарий, но не то чтобы нулевой.
А самое главное, как раз если в норме команда разработки "не заморачивается" производительностью, то оценка асимптотик должна быть на уровне спинного мозга: логика "если окажется медленно, поправим" работает только если кто-то post factum тратит время и силы на оценку не медленно ли оно. А без этого отдел маркетинга поможет клиентам свыкнуться с мыслью что с этой скоростью надо жить, и мир в целом станет немного хуже.
mclander Автор
11.11.2024 05:42Я всегда люблю в оптимизацию, иногда излишне, но часто сталкивался с тем, что мои коллеги не парились. На мой вкус слишком часто. Но в прикладном ПО, по крайней мере на фронте, часто можно реально не заморачиваться. Тупо не те объемы. А если что, то можно и в "помощь зала", отдать что-то внезапно затормозившие старшим товарищам на напильнинг и полировку
Abstraction
11.11.2024 05:42Если есть 1) "старшие товарищи" и 2) способность сказать "возможно тут проблема" вместо двадцати железобетонных аргументов "это так и надо" (к сожалению, она есть не у всех), то хорошо. А если нет ни того ни другого, то приходится рекомендовать клиентам использовать Firefox, потому что приложение кушает гигабайт в десять минут, а ответственный за фронт программист считает что так и надо.
Я могу быть пристрастен, лично мне как раз было неплохим отвлечением поупихивать вчерашний LeetCode в 7 мс времени, но от полного игнора производительности я проблемы в задачах за которые платят деньги вижу достаточно регулярно.
mclander Автор
11.11.2024 05:42Вот и я про что. Сперва отбирают алгоритмистов, а потом в коде все равно "и так сойдёт" занимает подавляющую часть)
Магия наверно или даже колдовство
artemmoscow
11.11.2024 05:42Что я понял, это абсурдно строить какие-то умозаключения про джунов-миддлов-сеньоров. Автор почему то уверен что будут думать по тому же сценарию что и он, а если нет, то обязательно спиасал. Я не знал задачу, подумал секунд 10 и сразу выдал результат про floor(x+0.5)... Но самое главное это вообще никакого отношения к синьорности не имеет вообще. Во первых JS в принципе не про такие оптимизации, если это и нужно, то где-то в лютых оптимизациях C++ для шейдеров или HFT, js программисты к такому не привыкли и вообще не про это. Опыт (синьорность) программиста это не про то, что бы уметь быстро придумывать такие трюки, а про работу с бизнесом и командой
yoz
11.11.2024 05:42Не программист. Но добавить 0.5 к округлению сразу приходит в голову. Это же на уровне школьной математики задача.
NickDoom
11.11.2024 05:42В том-то и проблема, что чем больше «модных, стильных, молодёжных» решений, тем дальше программисты от школьной математики, логики и здравого смысла :( Идёт какое-то закукливание в волшебный мир орехов.
Сишник-приборостроитель — это физик+математик, умеющий кодить. Парадокс в том, что его код часто работает лучше, чем код человека, умеющего виртуозно кодить со всеми современными сверхмощными решениями. Потому что он не оторвался от (здравого) смысла происходящего.
Nipheris
11.11.2024 05:42Т.е. в реальной жизни задача, на которую на собесе выделяется полчаса может решатся и сутки-двое и бизнес это вполне устроит.
Вот только вчера об этом говорили с коллегами. Что куда важнее написать тесты вдоль и поперёк, особенно если это какой-то новый алгоритм (а зачем повторно реализовывать существующие?).
Мне вообще непонятно, каким образом алгоритмические, а точнее спортивно-олимпиадные задачки заехали в большинство собесов. У вас ещё более-менее адекватная задача, а зачем красно-чёрные деревья реализовывать на листке бумаги, я откровенно не понимаю.
А обычный сеньор, который оказывается звездой на letitcode вызывает вопросы. Когда он нашёл время на все эти задачки?
А на этот вопрос вы сами себе отвечаете:
О! А я её на собесе яндекса решал
Захочешь в Яндекс — и не так, простите, задницу рвать начнёшь. Добро пожаловать в чеболизацию по-русски. Я честно пытался найти ДРУГИЕ причины, но мне кажется пора перестать делать вид, будто они есть. Причина одна и стара как мир: если у тебя столько бабла, что люди стоят в очереди чтобы хоть как-то прильнуть к нему, то ты можешь делать что хочешь. Это касается как людей, так и компаний.
Мы вот рады, когда кандидат понимает, как работает flow-sensitive typing в TS, хотя бы просто на конкретных примерах. И то редко такие встречаются.
mclander Автор
11.11.2024 05:42Я не готовился к собесу Яндекса. Я вообще был удивлён, почему они моё резюме рассматривали, у меня з/п стояла выше рынка. Но на собес сходил, получил удовольствие. Выяснил на след собесе (алгоритмическое я прошёл), что им требовались еще и хорошие скилы девопса. Увы, это пока(?) не ко мне.
vadimr
11.11.2024 05:42Когда я учился программированию, в учебниках большими буквами было написано, что тестирование не гарантирует правильность программы и вообще не является инструментом разработки.
Современная увлечённость тестами, честно говоря, производит удручающее впечатление. Притом, что качество кода постоянно падает.
Это как если бы строители строили мост наугад до тех пор, пока он переставал бы разрушаться под проезжающими машинами.
Uprt
11.11.2024 05:42Юнит-тестирование важно для рефакторинга (чтобы при малейших изменениях не утонуть в регрессиях) и неплохо помогает поддерживать хорошую архитектуру (к лапше вы просто не сможете написать тесты нормально). Интеграционное тестирование туда же.
Тестрование важно в целом для отлова ошибок. Оно не гарантирует их отсутствие, но при правильном подходе существенно помогает их отловить. Люди не роботы, и человеческий фактор всегда будет присутствовать. Невозможно всю жизнь писать код сразу правильно, ни разу не проверив, насколько корректно он работает. Ну, если вы только не Чак Норрис.
Альтернатива - формальная верификация, но для сколь-менее сложных вещей это настолько долго и дорого, что скорее утопия.Тут скорее наоборот, современный софт часто скатывается в неработоспособное говно, потому что фирмы экономят на тестировании - мол, некогда тестировать, надо фичи херачить и рынок занимать, если что, юзеры протестируют, а мы обновление выпустим.
vadimr
11.11.2024 05:42Что помешает написать тесты к лапше?
panzerfaust
11.11.2024 05:42Ничто не помешает. Но тест к лапше тоже лапша. Сам факт лишних усилий по написанию сначала кода, а потом тестов, должен орать как сирена о том, что вы что-то делаете не так. Важно говорить об этом джунам в самом начале.
Abstraction
11.11.2024 05:42Как минимум:
1) батарея автоматических тестов по прошлым багам является инструментом защиты от регрессий и, по совместительству, хранилищем странных краевых случаев;
2) писанный протокол ручного тестирования позволяет быть уверенным что по крайней мере функциональность основных, оптимистичных путей выполнения не сломана совсем;
С моей точки зрения это вполне себе практически полезные, достижимые разумными усилиями гарантии.
Nipheris
11.11.2024 05:42что тестирование не гарантирует правильность программы и вообще не является инструментом разработки
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы:
а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста.
б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 99% случаев именно unit-тестирование.
Nipheris
11.11.2024 05:42в js префиксный плюс, это устоявшаяся идиома для конвертации в number, кстати, можно и про неё поговорить
Не нужно про неё говорить. Её нужно оставить для JS-квестов типа "посчитайте среднее по массиву за 8 символов" и в таком духе. В реальном коде абсолютно нечитаемая магия, особенно если JS/TS для вас - очередной-язык-на-котором-приходится-прогать, а не мечта всей жизни.
mclander Автор
11.11.2024 05:42По мне очень часто используемая идиома. Например, чтобы конвертнуть из string, особенно из форм
if (+form.age >= 18) { // ну началосьА поговорить можно про то, что это на самом деле это краткая форма
0 + form.ageи, возможно, в других языках с динамической типизацией оно тоже работает
vadimr
11.11.2024 05:42Динамическая типизация вообще редко бывает слабой. Это чуть ли не уникальная фишка JS.
Nipheris
11.11.2024 05:42на самом деле это краткая форма
Что вы имеете в виду? В одном случае это бинраный оператор, в другом - унарный.
ZhetoN
11.11.2024 05:42если вы точно знаете что это строковое представление числа, то Number(myStringNumber) намного понятнее, а если вы не знаете что вы туда скармливаете то плюсик все равно не поможет )
mclander Автор
11.11.2024 05:42+{}
NaN
+{} >= 18
falseЯ не знаю, как ты в мою форму подложим вместо строки объект, но теперь точно никакой порнухи, бро!
qweururu
11.11.2024 05:42Нет, вариант с + куда лучше Number(). Понятность для человека со стороны не является критерием. Вы же не говорите, что 1 + 2 менее понятно, чем addNumbers(1, 2)? Туда же и остальная арифметика/обозначения в целом.
fishHook
11.11.2024 05:42В который раз убеждаюсь, что все эти интервью - полнейшая лажа. Буквально же автор признается в том, что его способ интервьюирования не работает. Давайте еще раз посмотрим внимательно, что нам говорят.
1. ТС придумал оригинальную, как ему кажется, задачу, которая, цитирую "Огонь! Соискатель знает что такое округление" - здорово отсеивает кандидатов, которые не посещали школу после пятого класса.2. Периодически к нему попадают кандидаты, которые эту детсадовскую задачу решают не задумываясь
Автора это бесит, потому что его огонь-задача никак не помогла ему оценить кандидата. И почему-то это проблема кандидата, ведь он пришел подготовленный, негодяй какой.
Какая прелесть!
Что же делать? Перестать заниматься ерундой. Во-первых, не надо считать себя априори умнее кандидата на вакансию. Ну правда, кто ты такой, чтобы задавать мне детские задачки, проверяя, знаю ли я про округление. Это просто глупость и унижение. Во-вторых, у каждого есть определенный опыт за плечами, и это первое и главное, что определяет меня как специалиста, а не твои глупые вопросы на сообразительность. Если я имею за плечами условно десять лет веб-разработки, то очевидно, что я кое на что способен. Если не веришь, дай нормальное задание и будь готов оплатить мне потраченное время, не должен я тебе доказывать что я не идиот. В-третьих, есть испытательный срок, специально придуманный для отсева некомпетентных сотрудников.
Nipheris
11.11.2024 05:42В-третьих, есть испытательный срок, специально придуманный для отсева некомпетентных сотрудников.
Полагаю, этот механизм сейчас работает плохо из-за высокой доли вкатунов и откровенных самозванцев. Ну т.е. человек проходит фильтр, и сразу приносит компании минус 300-500к. А лишние деньги у всех закончились.
mclander Автор
11.11.2024 05:42Вот не понимаю, зачем
столько ядатак агрессивно?Мне хотелось проиллюстрировать идею и я взял самую простую задачу, в которой можно было показать как можно прийти к результату с помощью наводящих вопросов. Мог бы взять например сортировку вставками - но статья была бы больше, а вопросы "зачем это спрашивать?" всё равно бы были. Задачу на округление я обычно подкидывал людям вне работы. На собесе очень редко и только в качестве доп. вопроса.
По повода проверки округления. Я лучше проверю, что кандидат умеет в округление, чем не проверю. Это пара минут, которые могут сэкономить много времени потом. Да, мне более важно как кандидат проверяет входящие параметры в задачах (с чем люди лажают чаще, чем с округлением), но и бывают люди и не умеющие в округление с вполне приличным резюме. Если бы я с такими не сталкивался, я бы и не проверял, для меня это было откровением.
Джуна я бы точно проверил бы и не стеснялся бы.
Lexicon
11.11.2024 05:42показать как можно прийти к результату с помощью наводящих вопросов.
У меня не меньше агрессии, как отчитайте меня тоже. Программирование не вчера изобрели, уже поколение знающие люди говорят, что наводящие вопросы не работают, раздражают.
Вы вот буквально сделали все в примере, чтобы кандидат не вспомнил, что такое округление, а думал, как решить проблему кодом. А ведь проблема никогда не была в коде.
Не имеет значения, какие из этих дурацких задачек вы будете задавать, сортировку или нет, человек, который потратил время на щелканье задачек будет справляться с ними за милисекунду, потому, что моментально узнает паттерн, возможно даже будет достаточно опытен, чтобы дать вам потешить эго и предложить "улучшить решение".
mclander Автор
11.11.2024 05:42Часто, когда "затыкаешься" в коде, проблема не в том, куда копаешь. А в том куда надо копать. Но я уважаю и ваше мнение. Тут всё очень тонко. А наводящие вопросы просто экономят время интервью
mikhail_roslov
11.11.2024 05:42Почему надо готовиться, исходя из своего опыта. Как правило если говорим о бигтехах кандидат ограничен временем к примеру в час на 2-3 задачи из алгоритмической секции, если до этого не нарешивал скорей всего может уйти больше времени. Для львиной доли задач которые дают на собесах есть паттерны вроде "два указателя", "бинарный поиск", но как правило в работе такого рода задачи реализовать не требуется, а как известно нетренериуемый навык угасает. По себе знаю, что спустя полгода-год реализация корнер кейсов для того же бин поиска вылетает из головы как по щелчку.
Прорешивая тот же литкод решение становится очевидным, как только побьешься об него какое-то время, но попавшись в первый раз не всегда складываются мысли в пользу очевидного простого решения. Тут хочется задать риторический вопрос - если кандидат кандидат подготовился к собеседованию и знает ответы на все вопросы, смог и ответил на все вопрос, делает ли это кандидата подходящим для вакансии?!
Lexicon
11.11.2024 05:42Я не готовлюсь только по одной причине, я 10-лет назад, имея под рукой несколько лет абсолютно уникального и крутого опыта мог проиграть вчерашнему выпускнику МГУ с 0 годами опыта и придуманным опытом в резюме. Так и сейчас могу.
Я не понимаю, в чем ценность решения задачек. Может сейчас Bun любую из этих функций интерпретатором доведет до идеального времени. Может у вас в проекте es5 и полифилл .map медленнее, чем "for" в 24 раза, а вы тут native-C++ вызов Math обсуждаете.Вот сядет какой-то чувак напротив меня и спросит такую задачку. И есть только 2 варианта исхода, - мне сразу придет в голову ответ и не сразу. И если не сразу, умея строить сложнейшие системы в мире, буду слушать "а что если вы немножко подумаете, как улучшить это решение, не волнуйтесь, если вы не сразу пришли к решению, это не обязательно повлияет на оценку"
Можно же просто открыть рот и поговорить, предложить мне рассказать что-то, что вызовет интерес к моей кандидатуре.
Dmitry_604
11.11.2024 05:42Да я тоже за собеседование про опыт и задачи решенные, и в обратную сторону про компанию и задачи, а не за экзамен. Ну максимум кусок кода почитать обсудить что код читаешь как-то а не просто теоретик. Дальше уже на испытательном только может быть понятно. Ведь чел может решить все литкод-задачки но не смочь разобраться в реальном продукте, как и обратное тоже может быть. Для тех кто редко проходит собесы и уже далек от студента стрессовость ситуации может затмить реальный опыт. Также человек может быть вообще не договоропригодным и не командным - как это понять на собесе?
mclander Автор
11.11.2024 05:42Обычно я задаю вопросы по реальному коду. И если кандидат не может разобраться, то пусть он хоть крыло боинга в уме спроектировать может, то чем он мне может помочь? И да, если сразу идет туго, я задаю наводящие вопросы. Или подсказываю внешне кейсы, где код используется. Задача просто иллюстрация.
По поводу реального опыта и прочего. Эта статья - спин-офф другой статьи, где я как раз немного
подстебываюсь надобобщаю опыт "технической составляющей" собеседований. Пока лежит в черновиках, но планирую в среду четверг дописать и опубликоватьLexicon
11.11.2024 05:42Давайте оставаться в теме статьи, которую вы написали, озаглавили и дали по ней тезисы. Вы назвали статью "Почему я не готовлюсь", ваш главный тезис "потому, что задачки нужны, чтобы посмотреть, как вы думаете".
Я, среди прочих комментаторов не согласен, что задачки способны помочь увидеть, как кто-то думает, только то, как много собеседований ему пришлось пройти перед вашим и потеряв надежду заучить не только задачки, но и как "постепенно" на них отвечать, не вызывая подозрений.В процессе изложения статьи вы показываете, что те, кто готовятся к задачкам правильно делают, соответственно, заявление в заголовке выглядит вашим confirmation-bias, а итоговый тезис содержанием статьи не поддерживается.
Будет другая статья, - прокомментируем другую. Написали бы по-другому статью, - я бы и прокомментировал по-другому.
MANAB
11.11.2024 05:42Я согласен с подходом автора. Проблема в том, что цель выбрать "идеального" из множества вариантов, а не быстрее нанять "достаточно подходящего". И в эмоциях.
1. У бизнеса есть идея/надежда, что такой "идеальный" и дальше таким останется на других проектах.
2. Проводящему собесы намного "интереснее" самоутвердиться и рассказать менеджеру, что тот кандидат "даже ... не знает".
faiwer
11.11.2024 05:42Я так и не понял чего вы добились этими бредовыми задачками. С бредовыми требованиями. Задача была найти формальные отмазки почему отсеяли хорошего кандидата? К счастью меня никто такой бред пока не спрашивал. В том числе и на алгоритмических интервью.
Не используя дополнительных переменных. WAT? Зачем? Чтобы сделать код менее очевидным? За переменные нужно платить деньги? Как это вообще соотносится с реальной работой?
Уменьшить количество вызовов Math.floor. Ну просто запомним вычисленное значение в переменной. Упс. Нам почему-то нельзя. Ладно не хочу думать, какой там ответ? Ээээ... В ответе ровно столько же вызовов. Ах, автор имел ввиду повторений Math.floor в коде. Т.е. мы теперь уже символы экономим? Во имя чего? Чем мудрёнее выглядит код, тем выше премия?
Все эти
+!действительно желанны на code-review? Что вы там разрабатываете? И главное почему это признак сеньора.
Дальше уже статью не осилил. Это какое-то издевательство над кандидатом. И даёт около-нулевое представление о его навыках в software development. Когда я собеседую человека, мне нужно знать какое количество головняка этот человек может снять с моей головы, когда он станет моим коллегой. И мне не нужно знать знает ли он все 33 способа инвертировать 17 бит в float variable.
Стало быть мне важно чтобы человек имел хорошие архитекторские задатки. Ведь это самая сложная часть нашей работы - обуздать сложность больших кодовых баз. Когда можно поручить человеку разворотить половину кодовой базы и быть почти уверенным что он всё сделает красиво и правильно.
Мне важно чтобы человек хорошо понимал основы используемых инструментов. Senior должен уметь легко локализовать сложную проблему и потом разрешить её с минимальной энтропией.
Сеньор должен уметь избегать большинства footgun-ов. Ибо они потом сожрут до половину его времени. Скажем не писать
O(n^2)на пустом месте. Понимать когда и где какую структуру данных задействовать (задолбали уже эти.someвнутри.mapили всякие...objвнутри.reduce).Сеньор должен иметь product-чуйку и давать отпор product-manager-у там где его заносит. Уметь понимать что нужно компании и находить оптимальные пути решения. Знать где подстелить соломку.
Сеньор должен уметь хорошо налаживать горизонтальные связи, чтобы не было повисших задач, из-за того что "из того отдела нет ответа". Т.е. нужно уметь "get shit done"
И т.д.
И вот последнее что мне интересно от JS\TS разработчика это может ли он ugglify-ить код лучше, чем это делает либа.
mclander Автор
11.11.2024 05:42Во многом я с вами согласен, но идея статью все таки не
обязательноо найме только сеньора, и градации кандидатов больше для лулзов, чем как руководство к действию.Мне интересно смотреть кандидатов, в ситуации когда они сталкиваются с
лютой дичьютрудностями, а не образцово показательной задачкой.По поводу some вообще не имею ничего против, как и против спредов в resume. Я знаю что some работает
в некоторых случаяхпочти всегда медленнее, чем find/findIndex, а сред медленнее, Object.assign, или прямое присваивание свойства, если оно не одиночное (и то вкусовщина). Но читается и some и спред лучше, поддерживать проще (по моему мнению, так-то можно спорить). И если у меня нет задачи выжать железку до кровавого пота, то я использую и то и другое). И да, я чаще использую подготовленные маппинги внутри циклов, чем поиски с тем же some. Но опять же я не парюсь и в небольшой выборке воткну some и spred просто чтобы написать на несколько строчек кода меньше.Ну и если в команде не принято some я не буду писать some ) Я и не в таких
извращенияхвполне разумных стандартах участвовал.faiwer
11.11.2024 05:42По поводу some вообще не имею ничего против, как и против спредов в resume. Я знаю что some работает
в некоторых случаяхпочти всегда медленнее, чем find/findIndex, а сред медленнее, Object.assign, или прямое присваивание свойства, если оно не одиночное (и то вкусовщина). Но читается и some и спред лучше, поддерживать проще (по моему мнению, так-то можно спорить). И если у меня нет задачи выжать железку до кровавого пота, то я использую и то и другое)Эмм... А вы сейчас о чём? Я о
BigO(N^2). Которые я вижу ПРОСТО В КАЖДОЙ ВТОРОЙ статье про JS\TS. Это имеет масштабы даже не эпидемии, а пандемии. Пример:arr1.map(el1 => arr2.some(el1.id))Или не менее частое:
arr1.reduce((hash, k, v) => ({ ...hash, [k]: someLogic(v), }), {})Моя статья об этом тут.
some работает
в некоторых случаяхпочти всегда медленнее, чем find/findIndexУ них у всех
O(N). Разница же в константе почти никогда не играет значимой роли в тех областях, где популярен JS\TS. И выбор междуsome,find,findIndexоднозначен:some: нас интересует есть ли заданный объект в массивеfind: ещё нам нужен этот самый объект, когда он найденfindIndex: нам нужна его позиция
Тут нет выбора. Каждой задаче свой инструмент.
Мне интересно смотреть кандидатов, в ситуации когда они сталкиваются с
лютой дичьюЕсли лютая дичь очень оторвана от реальных задач то ценность таких тестов крайне низкая. Более того, это нерациональный отсев достойных кандидатов, которые могли бы стать отличным дополнением вашей команды.
больше для лулзов
Мне кажется вся статья скорее для лулзов. Хотя подана довольно серьёзно.
mclander Автор
11.11.2024 05:42Читал статью, согласен )
Врать не буду, сам не проверял, но у меня коллега оптимизировал затычку с производительностью, обнаружил, что find быстрее чем some, чуть менее чем на до хрена. Я был сильно удивлён. Так что константа тоже влияет. если она этак больше 4х. Да, ждать пару секунд, там где можно было ждать полсекунды, более приятно, чем ждать 60 (при достаточно больших n), но это тоже такое.
arr1.map(el1 => arr2.some(el1.id))
a = [1,2,3]
(3) [1, 2, 3]
a.some(1)
VM123:1 Uncaught TypeError: number 1 is not a function
at Array.some () at :1:3 (anonymous) @ VM123:1Имелось ввиду, что some - тут это какое-то линейное действие? Я уж испугался, что не знал чего-то про .some
arr1.reduce((hash, k, v) => ({
...hash,
[k]: someLogic(v),
}), {})Да можно тут в Object.assign или присваивание и возврат. Но если в массиве мало - спред хорошая читаемая форма. А если много можно, присваивание в for или .forEach - для меня это оградка, что там реально экшен. Но опять же всё на вкус (и в данном случае на объём). Конечно, если объем неизвестен, лучше предполагать, что он большой.
Мне кажется вся статья скорее для лулзов. Хотя подана довольно серьёзно.
Чужую статью каждый обидеть норовит )faiwer
11.11.2024 05:42Имелось ввиду, что some - тут это какое-то линейное действие? Я уж испугался, что не знал чего-то про .some
Банальная опечатка. У меня почему-то хабр через раз грузится, в спешке недописал. Должно быть либо `some(el2 => el1.id === el2)` или просто
includes(el1.id). По сути это одно и то же.Но если в массиве мало
А людям плевать. Хоть 1000. По моим недавним тестам разница уже видна на 10 элементах. На 100 она уже неприличная. На 1000 тушите свет. Особые таланты O(n^n) пишут там где O(n) хватит. Потому что "спреды это красиво".
Но опять же всё на вкус
В этом и проблема пандемии. Никаких на вкус тут нет. Тут разница между
NиN^2которая уже на сравнительно небольших масштабах чудовищная. Надеюсь замеры не нужны? А этот паттерн у нас сейчас в каждой первой статье про JS\TS. И я регулярно это вижу на code review.Но вы проверяете возможность сократить код убрав промежуточную переменную. Да что уж там, вы комментарием выше говорите про разницу между
.findи.some. А разница в асимптотике внезапно оказалась вопросом вкуса.Да блин, куда мы катимся.
Чужую статью каждый обидеть норовит )
Приходите ко мне в статьи и обижайте. Я просто люблю называть вещи своими именами.
MRD000
11.11.2024 05:42Я уверен, что я не очень плохой программист, хотя я не программист чисто, а "разнорабочий".
Но я бы не догадался о точном ответе в этих всех задачах, особенно под давлением на собеседовании. Вообще ожидание точного ответа на единственный вопрос (или три) всегда мне казалось самым худшим вариантом. Обычно чем больше вопросов, тем больше понимаешь уровень человека, по крайней мере это мне всегда помогало на большом количестве собеседований, которые я сам проводил.
mclander Автор
11.11.2024 05:42Скорее - это значит, что я плохой интервьер, если не смог дотащить до решения. Я там выше в комментах писал, что задача на округление была придумана как развитие идеи задачи x => 7-х, поэтому мне показалось, что это хороший путь к решению. Но, опять же, пример абстрактный)
dom1n1k
11.11.2024 05:42Общий посыл статьи понятен, но пример не очень удачный -
floor(x + 0.5)это супер-известный паттерн, примерно как!!xили~~x. Я не знаю, что и где нужно проспать, чтобы не знать этого. Хотя, как справедливо заметили выше, возможно это фильтр мимокрокодилов.
Vasjen
11.11.2024 05:42Почему я не готовлюсь к алгоритмическому интервью
Потому что я не хожу на собеседования, где есть алгоритмическая секция.
Если серьезно, на рынке куча вакансий в самых разных направлениях (как бэкендер говорю) – и финтех, магазины и CRMки, и какая-то аутосорс разработка, какие-то датчики, сканеры, интеграции с 1C. При этом разные базы, разные архитектуры, паттерны, целая россыпь вспомогательных технологий по типу кэширования и брокеров сообщений. Чего только не написали разработчики, что необходимо поддерживать, развивать и иногда переписывать. А еще у продуктов есть огромная бизнес сложность, которую надо знать и понимать, поэтому с наскока в новой компании вряд ли получится себя проявить, потому что ближайшие 3-5 месяцев будете изучать домен приложения, используемые подходы, основные процессы внутри приложений и их взаимодействие и т.д.
Я бы оценивал умение мыслить и понимать, как строить связи в БД, как организовать общение между приложениями, как проводить тестирование и сделать автоматический пайплайн выкатки, как выделить переиспользуемые вещи в библиотеки и т.д. Если кандидат может на эти темы рассуждать, а уж тем более может на своем опыте рассказать, то скорее всего он быстрее въедет в текущий проект, быстрее адаптируется и будет приносить пользу, нежели тот, кто сможет из себя выдавить решение какого-то алгоритма. Причем сейчас уже расцвет нейронок, можно целые методы скармливать нейронке, которая предложит декомпозицию, разделит по интерфейсам, и перепишет алгоритм с известным и более удачным решением.
Я среди собеседований не люблю два вида зла. Первое, где тебя проверяют на алгоритмы. Причем вот именно на "понимание", и если ты их не решал и не сталкивался по работе (а скорее всего и не сталкивался), то все эти наводящие вопросы нисколько не помогут. Интервьюер будет считать тебе некомпетентным, потому что ты не знаешь "базу", а у тебя тоже будет осадок, вроде и работаешь, и опыт есть, и успешные проекты за спиной, а тут какую-то "базу" не знаешь.
И второе, что не сильно уступает первому, это когда тебя проверяют насколько из тебя хороший статический анализатор получится. Тебе расшарили экран, перед тобой 20 строчек кода в каком-то онлайн блокноте, скомпилируй в голове. А там все что угодно, от абсолютно идиотских случаев множественного наследования с базовыми конструкторами, до каких-то задачек создания потока внутри нового потока.
Почему нельзя спросить теорию, если очень хочется - можно спросить вглубь, узнать что кандидат знает помимо верхов, где использовал, какие камни и т.д. Попросите спроектировать небольшое приложение, пусть расскажет какие будут компоненты, как буду храниться данные, как выдаваться и т.д. Можно сделать лайвкодинг — типа вот обработай массив ФИО и сделай какую-то итоговую строку, или подцепится к какому-то API и сформировать результат.
mclander Автор
11.11.2024 05:42Про это примерно будет в след статье.
А про статанализатор - зря. Вам же показали, что вы там чинить будете, если что. Так что у вас есть право испугаться и убежать. А вот если код с потолка взят и там ошибка в <T<T1, Partial>(T3).... То тоже можно понять, что им никто на самом деле не нужен
Dadadam999
11.11.2024 05:42Сначала думал, что это очередная статья в стиле "есть куда более лёгкий способ отсеять людей, чем алгоритмы", но к концу прочтения изменил мнение и во многом согласен с автором.
Я бы догодался до решения, на собесе, но к сожалению не сразу. Вот примерно, что набросал, когда прочитал и понял задачу: (x) => Math.foor(x) + (x % 1 => 0.5 ? 1 : 0)
Однако, решение в идеальном примере, мне нравится больше. Моё слишком громоздкое и хоть условие с 1 floor соблюдено, это точно всё и близко не уровень сеньора. Плюс, мой основной ЯП не JS и далеко не всю его специфику знаю.
Согласен со всем, кроме того, что "зубрить алгоритмы нужно в основном джунам". Честно я бы никому их зубрить не рекомендовал, если это напрямую не связано с работой. Знать основы алгоритмов думаю нужно всем, но углубляться в них сильно, пожеланию.
mclander Автор
11.11.2024 05:42Решенная задача в лоб, лучше красивой нерешённой) Это специфичный прием, кому-то знакомый, кому-то нет. Сеньорность и джунство, это шуточки, которые я видимо недостаточно выделил как лулзы.
Когда я даю эту задачу для меня больше интересна реакция человека на решение. Не важно, сам он её решил или я в конце концов рассказал. Обычно её я даю больше для проверки на софтскилл, насколько кандидату кайфово от красивого решения.
К этому моменту мне хардскилы обычно понятны. А для статьи выбрал потому что она простая и красивая и можно, пусть чутка коряво, подвести к решению.
Tyusha
11.11.2024 05:42Считаю полнейшим маразмом, если в формулировке задачи есть: не используя чего-то. Давайте тогда ставить условия: А теперь то же самое, только с мышкой в левой руке... А теперь не сидя, а стоя на одной ноге.
Если есть инструмент, то его надо использовать любым доступным способом, иначе это дебилизм какой-то. Главное — качественный результат. В данном случае — быстрая, надежная программа, использующая минимум ресурсов, написанная с небольшой затратой времени программиста.
mclander Автор
11.11.2024 05:42Анекдот про вводные помните?
Вообще это можно сказать устоявшаяся практика, давать новые вводные по задачам, кто я такой, чтобы её ломать? )
dimaaannn
11.11.2024 05:42Мой бы первый вопрос был "а почему я не могу использовать стандартную функцию?"
После какого либо ответа, я бы полез в исходники этой функции и скопировал много раз проверенное и гарантированно рабочее решение.
В ЖС это невозможно, поэтому третий вариант - вбить в гугл "округление числа JS" и посмотреть способы решения. Даже если решение очевидно - могут быть подводные камни и нюансы, которые надо проверить заранее.
Ну и когда я буду уверен что решение (x + 0.5) оптимально (а оно не оптимально, выполняется куча лишних операций), я буду его использовать.
При этом речь вообще не про логику или математику. На месте этой функции может быть любая другая. Алгоритм бы не поменялся. То есть уровень моей квалификации допускает ошибки даже в простейших (на первый взгляд) действиях, и я бы хотел видеть похожий подход и от джунов.
Keeper11
11.11.2024 05:42const f = (x) => x - Math.floor(x) >= 0.5 ? Math.floor(x) + 1 : Math.floor(x)А как сократить количество вызовов функции округления?
Да легко!
const f2 = (x) => ((x, fx) => x - fx >= 0.5 ? fx + 1 : fx)(x, Math.floor(x))
vadimr
Вроде бы как x+0.5 – это база. Непонятно, как можно пользоваться преобразованием типов, этого не зная.
Тут другие вопросы должны хотя бы возникнуть – что делать с отрицательными числами и с ровно 0.5.
Что касается трюка с 7-x, то начитанный чужого кода человек его знает, а другой вряд ли догадается. Уж очень он специфичен. Подсказка с !x выведет, как мне кажется, скорее, на x xor 7 (что само по себе лучше, так как невозможно переполнение).
mclander Автор
Долго думал прятать ли решение под кат, так как был уверен, что первый же коммент будет про 0.5 )))
На самом деле база базой, но к моему удивлению, что задачу про округление, что про 5-2 (даже в варианте 6-9), решает не так много людей. Задачку мы придумали ещё на первом курсе, когда один мой коллега по лаборатории, где мы
подрабатывалитусовались притащил задачу про 7. Догадались почти все, благо часть лаборантов училась на прикладной математике, а часть на старших курсах на гироскопах, где не сильно легче, чем на примате. В процессе обсуждения родилась и задача с округлением.А вообще я больше про логику на собеседовании и что должен делать интервьюер, чем про конкретную задачу.
NickDoom
Этим и отличается разработчик от «вкатившихся». Я зашёл было оставить тот же каммент — а он уже тут, причём первый.
CitizenOfDreams
Да это уже не "вкатившиеся", а вообще не читавшие учебник математики за четвертый класс средней школы...