Комментарии 310
Вроде бы как x+0.5 – это база. Непонятно, как можно пользоваться преобразованием типов, этого не зная.
Тут другие вопросы должны хотя бы возникнуть – что делать с отрицательными числами и с ровно 0.5.
Что касается трюка с 7-x, то начитанный чужого кода человек его знает, а другой вряд ли догадается. Уж очень он специфичен. Подсказка с !x выведет, как мне кажется, скорее, на x xor 7 (что само по себе лучше, так как невозможно переполнение).
Долго думал прятать ли решение под кат, так как был уверен, что первый же коммент будет про 0.5 )))
На самом деле база базой, но к моему удивлению, что задачу про округление, что про 5-2 (даже в варианте 6-9), решает не так много людей. Задачку мы придумали ещё на первом курсе, когда один мой коллега по лаборатории, где мы подрабатывали тусовались притащил задачу про 7. Догадались почти все, благо часть лаборантов училась на прикладной математике, а часть на старших курсах на гироскопах, где не сильно легче, чем на примате. В процессе обсуждения родилась и задача с округлением.
А вообще я больше про логику на собеседовании и что должен делать интервьюер, чем про конкретную задачу.
Вроде бы как x+0.5 – это база.
Разработчик аппаратно-программных комплексов
Этим и отличается разработчик от «вкатившихся». Я зашёл было оставить тот же каммент — а он уже тут, причём первый.
Этим и отличается разработчик от «вкатившихся».
Да это уже не "вкатившиеся", а вообще не читавшие учебник математики за четвертый класс средней школы...
Я тут интереса ради посмотрел новый курс математики от Дуолинго (внезапно) в разделе "для взрослых, желающих обновить знания". И там таки да, задачи именно такого толка... Так что ни разу не удивлюсь, если многие вкатывающиеся вообще про округление только что-то где-то примерно помнят, что оно зачем-то нужно.
Я без гугла и не вспомню в какую сторону округляются отрицательные числа. А так же не скажу наверняка всегда ли правила округления едины, или есть какие-нибудь прерия по этому поводу.
Спросил вот ChatGPT про это. Она мне 6 вариантов нарисовала:
Спойлер
When it comes to rounding numbers like 2.5 and -2.5, there are several different ways they can be rounded, depending on the rounding rule applied. Here are some common rounding methods and how they would handle these numbers:
Round Half Up (Traditional Rounding):
2.5 rounds to 3.
-2.5 rounds to -2.
This is the most commonly taught rounding method, where you round to the nearest integer and round up if the fractional part is exactly 0.5.
Round Half Down:
2.5 rounds to 2.
-2.5 rounds to -3.
In this method, if the fractional part is exactly 0.5, the number is rounded down.
Round Half Towards Zero (Truncation):
2.5 rounds to 2.
-2.5 rounds to -2.
In this approach, when a number ends with 0.5, it is rounded towards zero.
Round Half Away From Zero:
2.5 rounds to 3.
-2.5 rounds to -3.
This method rounds up for positive numbers and further away from zero for negative numbers when the fractional part is exactly 0.5.
Round Half To Even (Bankers’ Rounding):
2.5 rounds to 2 (since 2 is an even number).
-2.5 rounds to -2 (since -2 is an even number).
This method minimizes rounding bias over many numbers, as it rounds 0.5 values to the nearest even integer.
Round Half To Odd:
2.5 rounds to 3 (since 3 is an odd number).
-2.5 rounds to -3 (since -3 is an odd number).
This method rounds 0.5 values to the nearest odd integer.
Each of these methods is used in different contexts, with "Round Half Up" being the most commonly taught in basic mathematics, while "Round Half To Even" is often preferred in finance, statistics, and computer science to reduce systematic bias.
Цитировать chatgpt стоит только в обсуждениях его самого, вроде примеров где он справляется или наоборот. Оно же галюционирует. Поэтому надо его вывод всегда проверять по сторонним источникам, в этом случае достаточно процитировать их. Вы же только разводите энтропию и засоряете интернет.
Ну в принципе все эти способы уже и на хабре прилетали, даже с языками, в которых так принято.
сравните как работает Math.round в cpp, js, python2, python3. И вы удивитесь.
Ну вот это вот и стоило сделать автору комментария, а не цитировать чатжпт! Даже если в этом конкретном случае оно оказалось 100% правильно. Это сломанные часы, которые 2 раза в день показывают правильное время.
Прекратите грубить, пожалуйста. Вначале я у вас энтропию увеличиваю. Теперь вы меня поучаете что мне делать. Может мне вообще из топика уйти (в монастырь?). Я, небось, ещё неграмотность распространяю (наверняка у меня есть орф. ошибки).
Не превращайте обычную беседу в комментариях в какой-то фарс. Выдержка chat GPT не есть доказательство чему-либо. Скорее набор маркеров к обсуждению.
Условно "Лучше опустить Round Half To Odd, ввиду экзотичности, а Round Half To Even не актуален потому что..." было бы нормальной реакцией. Но вы предпочли нахамить, чего я раньше за вами не наблюдал.
Не вижу, где я нагрубил. Вы просто скопировали текст из чата, поленились его проверить, проанализировать и сделать из него свои выводы. Никак иначе, чем "засорять интернет" я это назвать не могу.
Обращаю ваше внимание, я не давал никакой оценки утверждений нагенеренным в вашем комментарии. Я лишь резко негативно выразился про ваше действие.
поленились
О, теперь я уже лентяй. Поленился. Видимо надо было не лениться. wataru будет недоволен. Не слишком качественный контент. Надо больше стараться.
Я лишь резко негативно выразился про ваше действие.
И это, прямо скажем, не сильно адекватно.
Не забывайте, что это всего лишь комментарии. Где мы просто беседуем. Мы не на заседании суда, и не диссер оцениваем.
wataru будет недоволен. Не слишком качественный контент. Надо больше стараться
Можете не стараться. Вы никому ничего не должны. Вы можете писать все, что захотите. И я могу иметь то мнение, какое захочу. Ну есть у меня резкая неприязнь к распространению по интернету выхлопа генеративных моделей.
Не забывайте, что это всего лишь комментарии
И поэтому их нельзя критиковать, что ли?
Там же прямо написано что round half up это traditional routing. Понятно что можно и транкейтить и делать нестандартно, но вы даже ответ chatgtp не можете прочитать?
Тем не менее, банковское округление и округление от нуля - это тоже традиционные. В том смысле, что используются на практике, а не добавлено "с потолка", лишь бы было.
Поскольку "к ближайшему целому" неоднозначно для полуцелых чисел, то опытный кодер обязательно уточнил бы у собеседующего, чего именно тот хочет. А заодно и рассказал бы и про три самых популярных.
Тут, конечно, для собеседующего может прозвенеть красный звоночек overqualified, "чего это я собеседую на позицию джуна, а ко мне пришёл то ли мидл (а то и сеньор), то ли лютый зануда..."
Строго говоря x+0.5 не всегда работает правильно.
> round = (x) => Math.floor(x + 0.5);
function round(x)
> x = 0.49999999999999994;
0.49999999999999994
> x
0.49999999999999994
> Math.round(x)
0
> round(x)
1
У вас сверху должно быть Math.floor(x + 0.5), а не Math.round(x + 0.5).
Но на ровно 0.5 всё равно возможны нюансы.
Ой, да, спасибо, поправил.
Но в целом оно криво работает только на экстремальных числах.
То есть в условном банке или при расчёте денег такое писать не нужно: обязательно на копеечку когда-нибудь разъедется. А если считаешь пиксели на экране, то идеально.
Да, всё верно.
Денежки плавающей точкой слава богу (я надеюсь) никто не считает. Для этого есть fixed point и прочий decimal. Или просто приведение к целому.
Ой, ещё как считают. У нас есть специальный чатик, куда мы double-дичь с денежками скидываем. Кажется уже пару десятков примеров.
Оказалось считают. Один раз реверсинженерил одну программу расчета зп по кпи и перебирал все варианты округления рассчета в формуле, что бы понять как повторить плаваующую ошибку, (которую нужно было повторить! ибо строгая отчетность) и оказалось что можно вдобавок вставить несколько разных округлений в одной формуле и много что еще оказалось как типы преобразовываются внутри формулы.
Но к слову даже после такого, когда варианты округления и преобразования типов операндов перебирались для разных операторов по нескольку сотен раз (неясно как писал создатель, в какой последовательности имплементировал формулу с какими мат. пакетами, монолит) я с ходу на задачу про округление и не отвечу ибо ну крайне редко на практике.
Но ведь ровно 0.5 в double не бывает.
Всегда будет чуть больше или чуть меньше.
Хахаха, автор написал статью про джунов, а тут к нему набежали сеньоры, которые ещё и в теории погрешностей разбираются.
Кстати о погрешностях.
Знаете такую штуку, как функция линейной интер/экстраполяции?
lerp(x, y, r) = x + (y-x) * r
lerp(x, y, 0) = x
lerp(x, y, 1) = y
Казалось бы, что может пойти не так? А много что. Ошибка нормализации разности, и вжух, lerp(x,y,1) > y.
Правильный способ описан, например, вот тут:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0811r3.html
а в std::lerp для вещественных чисел даже используется FMA вместо отдельного умножения и сложения.
И в реальном энтерпрайзе редко заморачиваешься, например, производительностью
Смотря что энетпрайзить. Трейдинг и телеком - там постоянно речь о массивах или потоках данных. Но литкод там помогает примерно никак. Реально полезный навык - это уметь оценить О-большое не одной функции, а цепочки функций или целого модуля. Ну и улучшить, само собой. Литкод этому не учит. Только практика, только чтение и рефакторинг тысяч строк всратого кода.
Согласен. Я больше про интерфейсные вещи (со стороны фронта) и данные для тех же интерфейсов со стороны бэка. В 90% там очень небольшие объёмы.
Типичная задача фронта оценить два источника, один из которых надо обогатить вторым. И есть две стратегии, подготовить маппинг по второму источнику, либо тупо в цикле по первому делать поиск по второму. Я правда не парюсь и в 90% пишу маппинг, благо это одна строчка на "современном" js, но и вторая стратегия не криминал, особенно если значений 2-3 и там даже непонятно что быстрее поиск по ключу или тупой перебор)
const f = (x) => Math.floor(x) + (x - Math.floor(x) >= 0.5) ? 1 : 0 Хорошо подумали?
Думал дольше провисит. Вопрос, что именно тут не так? )
К кому вопрос? Мне это очевидно, вам тоже.
Да это же база(с)
Приоритет ? самый низкий, я не случайно рассуждаю в абзаце выше про скобки
Но если честно, сперва написал неправильно. Перед публикацией, на всякий случай, прогнал по всем выражениям тесты. И сильно удивился, что не так. Выражение глаза резало, но почему догадался не сразу. Решил, что не буду править )
Среди прочего - оно не пойдёт в качестве ответа на хотелку "уменьшить количество вызовов Math.floor". Как было два вызова, так и осталось.
Если соискатель написал задачу за 5 минут правильно и оптимально, не переписывая в процессе несколько раз код, то... Никакой информации интервьюер не получит.
Это уже проблемы интервьюера, который зачем-то даёт задачи, которые ни о чем не говорят.
Но на самом деле их дают не для того, чтобы увидеть людей, которые круто решают задачи, а для того, чтобы отсеивать людей, которые такие задачи не решают.
И такую цель они решают, наверное, неплохо. Если вы стартап, и поток кандидатов не очень большой - это конечно довольно глупо. А если у вас на каждую вакансию очередь, то в принципе и ок.
Если человек выучил решение задачи - это не значит, что он её решил. И тем более, не факт, что её решил бы.
Для меня (и многих "работодателей") более интересен кандидат, который не (сразу) решил задачу, но, при получении решения, искренне восхитился (а что так можно было?
Это да.
Причем при наличии современного гугла и даже бесплатного чатгпт, можно сидеть и ковырять решение. Человек у которого логика работает, даже без образования докопает в нужную сторону и выдаст надежное решение, если не идеальное. Потому что не просто взял первое рабочее решение с инета, а доколупался до того, как оно работает и уже аргументированно выбрал вариант.
А для этого да, нужно чтобы человеку было интересно копнуть и соображалка работала.
Ревьюверы в таких случаях смотрят не на то, что человек решил. Решил - ок, молодец красавчик, но это вообще не важно.
Ревьюверы смотрят на то, что человек не решил. Если не решил - пока прощай.
Это просто инструмент по сужению воронки найма.
Всегда думал, что нельзя проверять на равенство числа с плавающей точкой. В C/C++ это UB, а в JS как?
Ниже правильно прокомментировали: ">=" нормально, но "==" в С/С++ точно UB, даже компилятор предупредит об этом.
А какой смысл существования флага -Wfloat-equal в компиляторах С/С++? Чтобы подсветить в предупреждениях все случаи проверок на равенство в коде.
Не очень понимаю, какой и чего уровень вас поражает, но это факт - проверка чисел с плавающей точкой на равенство это как минимум небезопасно.
Советую ознакомится с интересной статьей, правда про пайтон.
Проверка чисел с плавающей точкой на равенство часто работает не так, как ожидается программистом с недостаточными знаниями, поэтому маркируется предупреждением. Но всякое число с плавающей точкой, кроме семейства nan, гарантированно равно самому себе.
Это явно проблема недостаточности знаний программиста… хотя избыток выпендрёжа тоже вредит, я вот активно использовал NaN, чтобы преднамеренно маркировать результаты, которые мы при имеющихся входных данных рассчитать не можем. Предельно логично, но каааак оно тормозиииит :(
Работать с этими результатами дальше оно не мешало, в любом случае надо держать в голове возможность прилёта на вход NaN (дело было на плюсах). Максимум — немного дисциплинировало в этом плане. А вот в плане быстродействия это был просто злодейский поступок :) Не такой, конечно, как M$-овские курсоры, сжирающие половину проца на мигание, но уверенный шаг в эту сторону :-/
Хотя я и с памятью в том проекте так же обращался. Шёл на любые мерзости, лишь бы потом не упереться в границы расширяемости и не рефакторить :-D Всё равно получилось на порядок быстрее и стабильнее практически точного клона, переписанного на модных «безопасных и стабильных» языках. А для самых ходовых случаев прикостылил сжатие :-D
Я согласился с другим комментатором, что ">=" не является проблемой, но продолжаю настаивать, что именно проверка на равенство плохая идея. При работе с double или float вы теряете точность, поэтому результат вычислений может быть близок к чему-либо, но не всегда равен. Возможно вы имеете в виду работу метода Math.floor(x) , про который я не знаю, но который точно возвращает число без дробной части. Но я беру общий случай, что после каких-либо вычислений сравнивать числа с плавающей запятой через == нельзя.
Если вы не знали про такую особенность флоатов, то именно ваш уровень экспертизы нулевой, может тут и вся статья неправильная...
Видимо вас задел термин UB. Если что-то не UB, но если я воспользуюсь этим, то результат ХЗ, то это UB.
Раз уж вы решили написать статью, а у вас что-то спрашивают, то, думаю, не стоит быть настолько грубым. Если вы думаете, что я трачу ваше время, то не отвечайте совсем, чем так.
Если что-то не 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
То есть язык дает определенные гарантии и предсказуемость результата.
Давайте все-таки использовать общепринятую терминологию, а не выдумывать свои значения для существующих терминов.
Эмм, нет. Undefined Behavior это конкретный термин из конкретных языков программирования, который специальным образом обрабатывается компиляторами, для чего он собственно и введен. Компилятор C/C++ исходит из того, что в программе не может быть Undefined Behavior, что позволяет ему для оптимизации игнорировать все инварианты в которых он возникает. Если бы == для FP был Undefined Behavior, компилятор мог бы просто удалить весь код который зависит от вычислений в которых он встречается под предлогом "так быстрее". При этом последствия для программ полагающихся на код с UB могут быть какими угодно, в шутку говоря хоть динозавр из монитора вылезет.
Вы хорошо понимаете теорию погрешностей?
А если программист, который сравнивает вещественные числа, как раз хорошо понимает, и следит за наличием-отсутствием погрешностей в своём коде? У него будет результат ХЗ? Или это у вас будет мнение ХЗ о его результате?
Давайте начнём с самого простого: 0.5 == 1.0 / 2.0, тут хз или не хз?
Для начала надо ответить себе на вопрос, чего вообще пытается добиться наш горе-программист, сравнивая (на сях, раз о них заговорили) какой-то результат вычислений с чем-то ещё. Калякать код, не представляя, что за этим стои́т с точки зрения здравого смысла — это даже не смешно.
А ответив на вопрос, «что и зачем я сравниваю», можно получить выводы от « == или fabs(Diff)<.000001 » до «да чёрт же ж, тут весь алгоритм надо на фиксированную точку переделывать и следить, чтобы разрядности хватало без перескоков работать».
Хотя у меня был ещё похабный случай «дабла тут хватит, у нас никогда хвосты не добегут до младшего разряда». Не делайте так :) это я охамел :)
О! А расскажите, пожалуйста, подробнее про последний случай. Хотя теоретически это можно себе представить, но на практике ведь результаты любых физических измерений менее точны, чем дабл. Как так получилось?
На входе было что-то типа fixed point 16 bit, а проверить надо было что-то типа «попадает ли точка на отрезок» (ну или что-то похожее). Не помню, что именно, но там было что-то вроде пары умножений того на это, а этого на то, после которых не могла длина числа достичь длины дабла, то есть по факту вся эта геометрия была не плавающей, а пиксельной (даром что в дабле лежала) и понятие «попадает/не попадает» там имело смысл, в отличие от бесконечно точных измерений :)
Я пальцем потыкал в вычисления, прикинул, насколько может удлиниться хвост и могут ли возникнуть ошибки округления, заменил флот на дабл (флота не хватало) и забил на эту проблему, так оно и работает лет эдак полтора десятка :)
Вообще такое, конечно, надо обильно обкладывать камментами, ибо вдруг кто-то прочитает и решит, что это нормально :) а потом будет какой-нибудь Бидон крестовым походом на сишников идти, мол, код у них небезопасный %)
Спасибо! Неправильно понял смысл Вашего предыдущего комментария и подумал, что вам не хватило дабла. Удивился. С другой стороны, зачем-то ведь придумали четырёхкратную точность. Пытаюсь понять.
Поэтому и надо обкладывать камментами насчёт очень узких границ применимости. А то кто-то «улучшит точность» на входе — и всё посыплется.
Даже если это среднее значение, то у него устраняется только случайная погрешность, но не систематическая. Поэтому по идее оно никак не может превосходить точность самых точных физических измерений, которые ограничиваются 14 цифрами.
x/2 в формате числа с плавающей точкой IEEE-754 имеет ровно такую же точность, как x (если вообще представимо нормализованным числом). Это происходит благодаря нормализации.
Ни одна арифметическая операция над вещественными числами с плавающей точкой, кроме умножения на константу 0, не может повысить точность.
Ваш аргумент ещё можно понять в том смысле, что, например, значение 1/3 точно не представимо, и чем больше цифр, тем выше точность. Проблема, однако, в том, что 1/3 – это математическая абстракция, не отвечающая ничему в физическом мире.
fp не терял бы точность, если бы это было так
Потеря точности и её повышение - процессы, ну, разные.
Любые числа - это абстракция. Но флоат/дабл именно эту абстракцию и представляют, поэтому к чему этот довод?
Это довод к тому, что при расчётах чего-либо, связанного с измерениями, вам, скорее всего, никогда не придётся делить точную 1 на точную 3. И даже если придётся - полученное число будет тут же умножено на какую-нибудь неточную величину, на фоне неточности которой ошибка в последнем разряде у 1/3 будет совершенно незаметна.
Как минимум, нужно учитывать ещё и количество операций наподобие деления.
Там вроде всё удалось привести к общему знаменателю и избавиться от деления. Вообще в таких задачах избавляться от деления — вещь первоочередной значимости, если это возможно (а тут, опять же, надо понять, чего мы считаем; если это, скажем, соотношение отрезков в 3D-рейкасте, то от деления не уйти, и надо ограничить, допустим, рассматривание стенки героем до некоей ненулевой величины).
Но вообще «первое слово дороже второго» — «решение похабное, не делайте так». Там надо было перевести всё в буквальные целочисленные вычисления с буквальными пикселами, где царствует int 64. Дабблы, даже тщательно обложенные камментами — похабень.
Тем более, что оно бы ещё и в скорости прибавило (это был боттлнек, поэтому и сравнения там были максимально быстрые, то есть через « == »). Но в какой-то момент лень победила, работает — всё, забил :-/
Пардон :) Я действительно весьма двусмысленно выразился насчёт похабности этого случая :)
Ну что поделаешь — это был пример UB в естественных языках :-D :-D :-D
С другой стороны, зачем-то ведь придумали четырёхкратную точность. Пытаюсь понять.
4-кратная точность увеличивает как размерность мантиссы так и экспоненты.
Есть 2 разных проблемы:
1. Недостаточная точность fp-вычислений (начиная со "сложить массив с минимальной ошибкой" и заканчивая "решение плохо обусловленных дифуров").
2. Переполнение fp-value.
Переполнение fp-value довольно специфический случай, который нужен 1.5 человека.
А вот накопление неточности - это довольно сложный случай, с которым бороться софтварными методами можно лишь ограниченно и рано или поздно вам просто захочется иметь больше бит мантиссы.
https://en.wikipedia.org/wiki/Floating-point_error_mitigation
но на практике ведь результаты любых физических измерений менее точны, чем дабл
Разделите мне, пожалуйста, вот этот угол на три равные части. На практике.
Так они и не спорят с тем, что проверка флотов на равенство - плохая идея (2.32 ! = 6.32 - 4.0). Ребята просто говорят что это - не уб.
А какой смысл существования флага -Wparentheses?
Вы путаете undefined behavior и unspecified behavior.
Оператор == для чисел с плавающей точкой и defined, и specified. Загвоздка лишь в точности самого полученного значения с плавающей запятой. У FP неассоциативные операторы, накопление погрешностей, и невозможность точного представления конкретных чисел.
Вспоминается мне какой-то ассемблерный трюк с «Сахары», где байт со старшими битами мантиссы копировался в остальные байты мантиссы, то есть получалось только 256 возможных значений мантиссы — использовалось именно для того, чтобы «прибить к сетке» значения (обычно такое делается в гуях для комфортного восприятия глазами какого-то вывода данных).
На равенство плохая идея, на >= почему нет? Есть ещё приём проверка на чистое равенство с допуском, но тут он не нужен.
Это не уб, просто есть шанс неправильно сравнить 3.0 и 3.00000002. Если мы уверены, что не получим на вход "плохое" число (например, они идут из поля ввода с жесткими 2 знаками после запятой), то ничего страшного если сравнивать напрямую. В противном случае, нужно использовать ε равенство
Как-то так. Как я выше говорил — герою этой воображаемой ситуации надо бы просто задумываться, что, зачем и на предмет чего именно он сравнивает. Тогда он поймёт, нужен ли критерий «попадает в тот же пиксел» (отклонение меньше половины), «является тем же самым числом» (тут надо сравнить напрямую) или что-то «ещё более третье».
И если у кого-то си виноват в том, что человек не задумывается над смыслом своего писева, то у меня для них плохие новости :)
Написать функцию-стрелку (f), которая принимает на вход либо 2, либо 5 (гарантированно, что ничего другого прийти не может). И возвращает: если на входе 5, то 2, если 2, то 5. Использовать оператор нельзя. Время пошло.
Алгоритмические задачи превращаются в какие-то задачи-ребусы. На собесе в Яндекс я недавно, типа таких встречал, они, вроде как, на знания языковых конструкций, но на деле просто сбивают с толку, по сути - бессмыслица, на letcoode и coderun такие задачи не встречаются.
Оцените минимальное число углов у многоугольного люка, при котором он ведет себя как круглый?
Я недавно собеседовался в яндексе, одна задачка была похожа на реальную, вторая притянута за уши. Зато имела очень красивое решение. Я бы в лоб написал решение раза в три длиннее, но интервьер мне упорно не давал это сделать вытаскивая именно на решение "по красоте"
В чем именно ведет себя как круглый?
Не-не, так слишком просто )
Похоже на задачу триангуляции круга, при отрисовке. Минимальное, я думаю будет, больше 4, т.е. 4 угла - это прямоугольник, 5 - это многоугольник, похожий на круг, и чем больше углов далее - тем он больше будет походить на круг.
В идеале, нужно найти баланс между тем чтобы многоугольник(круг) не был визуально угловатым и количеством операций(углов), чтобы программа не тормозила.
Я вообще-то пытался в стёб над задачами (совместить заезженную задачу с математикой), но по ходу провалился ( Либо вы умеете в тонкий троллинг))
Если вспомнить, что у круглого люка два качества - легкость перемещения, его можно легко катить и, более важное непроваливаемость. То углов очевидно должно быть 20+, чтобы катить можно было. А чтобы не проваливался надо знать диаметр канта и диаметр люка, тогда можно будет (как-то) рассчитать минимальную ширину люка при минимальном n, большую чем диаметр канта.
Для особых задротов можно предположить, что кант будет тоже многоугольным, и тут уже математика, к которой вот я лично не готов ) Зато можно же в перебор - вот и алгоритмическое решение подъехало.
Люки круглые потому что производить круглые металические болванки проще чем многоугольные, по этой же причине и остальные предметы из металла, типа монет, тоже изначально круглой формы. Отстальное все это фантазии. Когда техпроцесс позволяет люки делают какой угодно формы и никого не беспокоят проблемы проваливающейся крышки или необходимости зачем-то эту крышку катить.
Это в странах с готическим шрифтом они не проваливаются. У нас лучше всё-таки в круглые.
Идея для научной статьи: Корреляция между частотой использования засечек в типовых шрифтах и количеством травм полученных при падении в люк...
Есть мнение, что в данном случае крышка не проваливается по той простой причине, что она не снимается, а откидывается, на шарнире.
"За N комментов до Гитлера"
Но кстати, как раз Гитлер сперва настаивал на фрактуре, а потом передумал и стал настаивать на антикве.
подозреваю что там более широкая ступенька сделана чтобы люк по диагонали таки не провалился. Иначе думаю проектировщика быстро проклянут работники предприятия своими готически-католическими проклятиями :)
так и есть, и я никогда не понимал людей которые говорят "а вот круглый не проваливается" ведь и там и там нужно сделать бортик в любом случае. Не так уж и сложно рассчитать размер бортика для квадратного люка так, чтобы диагональ у бортика была меньше чем сторона у люка.. Вроде как соотношение диагонали к стороне вообще константная величина
он на шарнире, его невозможно открыть иначе, чем по стрелочке с надписью "Open"
И мне казалось, что люки отливают, а не пилят из болванок, а потом ещё и гравируют...
Вам его еще надо шлифовать, да и чтобы отлить надо сделать форму. Какую форму для отливки сделать проще(дешевле) - круглую или прямоугольную?
вы так говорите, как будто это риторический вопрос и ответ всем очевиден.
так какую легче отлить? а почему? а дешевле?
Попробуйте сделать в куске гибса круглое отверстие, а потом квадратное. Желательно сверло уаттса не использовать.
при чем тут гипс и сверло? По вашему форму под отливку метала сверлят? Ну я вот собственно к этому и поднял вопрос - вы очевидно не эксперт в литье при этом рассуждаете как будто понимаете что-то
Попробуйте сделать в куске гибса
За что вы так с Гибсом?
В куске гипса квадратное делается элементарно. Опалубка из досок, по-вашему, какая проще? А мелкие отверстия - ну, возьмите брусок и ткните в гипс до того, как он схватится.
Кстати, у нас иногда встречаются и вот такие люки:
Само собой, такой в принципе сложно заставить провалиться. Но почему-то очень редко их видел.
ИМХО дело не в простоте производства, а банально в том что у круглого люка заметно меньше площадь, а значит и объем требуемого материала.
Крышка не проваливается в люк, видимо. Но тут надо знать диаметр люка и крышки.
Я всегда понимал эту задачу как упражнение на рефлексию над моделями. Достаточно ли того упрощения реального люка которое у меня в голове? Какие особенности я забыл?
Реально я видел и квадратные люки крышки, и я довольно сильно ожидаю что даже такую крышку в закрываемое ей отверстие вы нарочно-то замучаетесь просовывать, с шестиугольной миссия становится практически невыполнима (потому что а) крышка толстая и б) она закрывает люк потому что размер дырки меньше размера крышки, она лежит на "полочке"; численное соотношение между этими параметрами при котором задача для шестиугольника становится нерешаемой даже теоретически читатель может вывести самостоятельно, для люка метрового диаметра это единицы сантиметров).
…а ещё бывают допуски литья и самая злая ситуация — крышка пролетела метр-полтора и вклинилась наглухо, а автокран подъехать не может. Усилие её выдирания сами можете представить, если хоть раз работали с такими массами.
Поэтому в третий раз вынужден повторить — программист должен понимать смысл того, что, с чем и зачем он сравнивает :-D
Был случай — человек на полном серьёзе боялся остатка от деления 1000000000 микросекунд на три, типа, накопится и мы рассинхронизируемся. При этом данные шли с другого девайса и он это знал.
Когда я покрутил пальцем у виска и спросил, в курсе ли он про достигнутую на современных кварцевых генераторах точность, до него дошло %) Когда он понял, что, с чем и зачем он сравнивает — сразу же добавил все нужные алгоритмы коррекции, поправки и ресинхронизации, и всё у него заработало :) Они у него были под рукой, просто он в нужный момент не задумался о смысле того, что пишет %)
Собственно, вот и вся проблематика отрасли. И никакие Расты тут никаким боком не валялись.
человек на полном серьёзе боялся остатка от деления 1000000000 микросекунд на три, типа, накопится и мы рассинхронизируемся.
А у Вас не возникала мысль, что он что-то знал?
в стрессовой ситуации, например на лайв-код интервью
Завист от того, в чем именно "как круглый". Чтобы его было легко катить, углы при вершинах должны быть достаточно большие. Но тут нет четкой границы - чем больше вершин, тем больше угол, тем легче катить. Из бытового опыта кажется, что 20 угольник уже будет достаточно круглым. 5 угольник - точно нет. 10 угольник - наверное да.
Чтобы люк внутрь не проваливался, как круглый, надо, чтобы разница между диаметром люка (2 наиудаленнейшие точки) и наименьшим сечением была минимальна, меньше толщины люка. Ну, это примерно, потому что если рассматривать люк сверху у него сечение будет прямоугольник и надо чтобы он в N-угольник не пролазил. Еще надо учесть, что дырка из под люка на самом деле на сколько-то процентов меньше люка, он же на каких-то краях лежит.
Тут надо нарисовать N-угольник и подумать. Кажется, минимальное сечение - это высота из вершины в противоположную сторону (или высота между противоположными сторонами для четного N). Диаметром будет или расстояние между противоположными точками для четного N, или ближайшая хорда (разделяющая (N-1)/2 и (N+1)/2 вершин). Можно вывести формулы там будут какие-нибудь косинусы каких-нибудь Pi/2N и какая-то штука должна быть меньше ширины люка. Тут еще где-то будет фактор уменьшения дырки под люк.
Тут надо нарисовать N-угольник и подумать.
Считаем, что место под люк круглое. Люк радиуса r лежит на ободке толщиной z.
Люк - это вписанный многоугольник. Его можно разбить на n равнобедренных треугольников. Высота треугольника h = r * cos(x), где x - это половина угла. n = pi / x
Чтобы люк не упал, должно выполняться r - h < z. Подставляем формулу для h и cos(x) = 1 - x*x/2. Решаем.
Вы считаете количество вызовов floor в строке кода, а не в рантайме выполнения?
Тогда надо бы это проговорить, а то первое что в голову приходит - избавиться от двух вызовов в рантайме и написать что-то вроде этого:
const f = (x) => x % 1 >= 0.5 ? Math.floor(x) + 1 : Math.floor(x)
или вообще так
const f = (x) => Math.floor(x + (x % 1))
Без такого уточнения, не сразу понял как вы так сократили "вызовы" floor в переписанном (не обращая внимание на нехватку скобочек) и почему я один негодую, а комментарии молчат по этому поводу)
Огонь! Я и не знал, что так можно. Думал что остаток только для целых чисел (c-шник детектед)
Но статью вы на момент комментирования до конца не дочитали )
А вот так работать не будет, но вы близки)
const f = (x) => Math.floor(x + (x % 1))
Первое можно еще чуть упростить. Сначала уберем дублирование 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))Но для отрицательных чисел оба способа работать не будут.
Если бы соискатель написал бы % - я бы сказал, что его тоже нельзя ) Мне нужно прийти именно к безтернарному виду. По крайней мере без тернарника вне параметров Math.floor
Для положительных и отрицательных правильно
const f1 = (x) => Math.floor(x + (x >=0 ? 0.5 : 0.50000000000000005551115123125782702118158343))
Вещественный остаток - это всё те же игры с округлением, только спрятанные под капот.
Так что не считается!
Огонь! Соискатель знает что такое округление, понимает как получить дробную часть.
Эм... А в чем тогда проблема начать с того, чтобы взять и спросить, что вы знаете про арифметику с плавающей запятой? Тут же разговаривать, при желании, можно дольше, чем в пресловутом вопросе про что происходит после ввода url. Я не про то, чтобы заучивать наизусть IEEE 754, а про то, какие чудеса начинаются, когда в конечное количество битов нужно попытаться запихнуть множество, которое бесконечно и непрерывно. Неассоциативность (в общем случае) операций, положительный и отрицательный нули и много чего еще.
У меня был начальник, который любил задачу для собеса, в которой надо было работать с остатками. И я сам бы удивлен, что задачка такая простая, когда сам проходил собес. И ещё больше тем, что половина кандидатов на сеньорскую (!) позицию не знала как взять остаток нативно или хотя бы с помощью функций округления.
Но и задавать вопрос соискателю про его, возможно, вопиющую некомпетентность в лоб не очень хорошая идея. Да и практические навыки чего бы не проверить?
Когда на собеседовании постепенно повышаешь сложность задач, что бы увидеть, на каком уровне кандидат "поплывет", есть неплохой шанс самому "поплыть" раньше кандидата. Например, когда кандидат даст решение, о котором ты еще не подумал.
Так что подобное собеседование больше похоже на мальчиковую игру меряться длиной (фокусного расстояния объективов).
Так это ж хорошо, если сам поплыл раньше кандидата. Надо брать.
Не всегда, а может случайно попал в одну из немногих тем где собуседуемый более экспертен. Хотя это уже неплохой показатель о кандидате, факт.
Так это ж хорошо, если сам поплыл раньше кандидата. Надо брать
...узелок и топать отсюда, пока он обживается в бывшем моём кресле!
Сразу видно что вы про диагноз overqualification не слышали...
Не первый раз уже пишу эту телегу, но если алгоритмы даже по мнению автора не дают нужной информации - так может и не нужно?
У меня есть готовое решение для этой задачи, вот как придется(если недайбог придется) участвовать в найме, то обязательно применю:
(пишу для своей специальности джава бекенда но уверен все читающие умеют в экстраполяцию)
Берем и делаем проект в схожей тематике с рабочим, но очень сильно упрощенный. Докер, База, что вы там ещё юзаете, апи, контроллер, сервисный слой, горстку сущностей и пару базовых функций. Например для условного банка можно сделать абстрактный кошелек который умеет делать deposit, withdraw, createWalled, deleteWallet ну и ещё пару функций придумайте по своей специфике проекта.
На интервью берем значит человека, кидаем ему сслку на гит и говорим сделай git clone. Открывает проект, поясняем ему как его запустить если есть специфика а дальше...
1) просим рассказать что за проект, как он работает, полазить по файликам и покоментировать что он видит. На этом моменте можно будет полнейших нулей сразу выкинуть
2)даем рандомную придуманную на ходу задачу - добавить ручку, для ручки сущность, для сущности миграциию в базу, и в сервис метод который будет делать то да сё. Не нужно ничего усложнять, пусть задача будет на 15 минут. Если человек сразу теряется и не понимает что делать - ну это джун, его за ручку можно вести и пояснять что да куда писать и в процессе понять нужен такой или нет. Если мидл, он сразу сориентируется и быстро всё накидает, там можно в процессе всяких корнеркейсов накидать, чтобы проверить знает ли он кто такие эти ваши уровни пропагации транзакций и все ли у него будет ролбекаться
3)Можно прошлые решения других собеседуемых просить зарефачить/задебажить итд
И при этом всем можно прямым текстом сказать - гуглить можно прям при мне, можно в чат гпт запросы закидывать и вообще все что хочешь делать. Именно так человек работать в реальности и будет и именно это и стоит проверить.
в процессе вы будете видеть - а человек вообще понимает как проект строится? Быстро ориентируется в коде, читать то умеет? Знает как функционал внедрять? А гитом как пользоваться, клонировать, ветки создавать, коммиты оформлять.
ну и собственно если человек все это понимает и может выполнять задачу идентичную реальной, то его можно смело брать и не тратить время на следующих 10 кандидатов
такой подход решает все проблемы интервью и их хакинга кроме разве что одной - если за кандидата кто-то другой пройдет или наговорит ему в наушник, ну тут уж ничего не поделаешь. Зато, такое интервью избавляет вас от "100 золотых вопросов по %language_name% от ложноотрицательного результата по тому что человек просто в стрессе не смог алгоритм решить. С другой стороны дает понимание - как человек реальные задачи решает, как он код пишет и структурирует, какие инструменты использует, умеет ли гуглить нормально и искать быстро, хоткеи использует? функции ide? как вообще задачу обсуждает, задает ли уточняющие вопросы, видит ли проблемы в ТЗ или сразу прет напролом не включая голову. В процессе можно с ним пообсуждать(не дрочить, а обсуждать) теорию - как он применяет, что он применяет, как его решение будет под нагрузкой работать, нужно ли такое сложное если нагрузки не будет итд итп.
Я обычно примерно так и делаю, даю кандидату кусок говнокода (с правильным-то каждый сможет) и прошу рассказать, что он делает. У меня был в Сбере был отборный пример. Если его переписать по феншую, то он в 3 раза будет длиннее, а так все умолчания делали именно то, что надо. Жаль не догадался при уходе скопипастить.
Но если играть в задачки, то мои мысли выше)
Единственно верный вид собеседования разработчиков
Если честно, понятия не имею почему так не делают (или делают редко). Потому нагло поспекулирую.
Опытный сеньор (возможно даже мидл) может понять по данной кодовой базе что у вас проблема в архитектуре приложения. И, соответственно запросить выше зарплату. Или вообще отказаться.
Может поэтому так не делают? Кроме того часто нужно погружение в предметную область. Кажется что никто просто не хочет этим заниматься.
Также хотел бы отметить, что требовать, например при рефакторинге или имплиментации фичи, писать реальный код бессмысленно. А то и вообще неуважение к интервьюируемому. Букавы любой сможет на клавиатуре набрать. Достаточно просто плана действий. Если, конечно вы не джуна нанимаете или начинающего мидла.
(Вот сейчас снова прочитал ваше сообщение и кажется вы именно про начинающих мидлов и джунов писали).
не в коем случае не имеется в виду использовать свой реальный проект, что вы. Наоборот СУПЕР упрщенный намек на реальный проект. Если у вас 20 микросервисов, можно сделать просто два, чтобы можно было проверить точно ли собеседуемый знает как консюмера в кафке настроить. Никаких выводов об архитектуре реального проекта кроме стека из этого сделать не выйдет.
Просить писать реальный код, по моему не проблема, если пишем простейшую логику. В том же примере с wallet ну буквально нужно создать метод который принимает переменную с денежками, что-то с ней делает на уровне арифметики, ну хз кешбек считает и пишет в базу результат. Просто джун денежки будет писать интом и не в курсе будет что при сложении с плавающей точкой потеряется точность вычитсления, кто-то упустит транзакцию или что например при списании за которое начисляется кешбек списание откатится а начисление кешбека нет по тому что вложенность транзакций не верно сделана итд
И самое главное - ну уж сениоров то не нужно лайвкодингом проверять, вы бы ещё CTO заставили алгосы решать.... погодите, CTO же не заставлют их решатЬ?! НЕ ЗАТАВЛЮТ ПРАВАДА ВЕДЬ!?!??!
Это не работает. Если вы более-менее крупная компания, то ваш собес (суть приложения с точностью до кода) утечет в сеть после нескольких интервью. Что, приложение менять? Как менять? У данного подхода, в отличие от стандартного лайвкодинга отвратительная вариативность. Плюс ко всему, любой рефакторинг - вкусовщина та еще. Можно холивар на пустом месте развить (если вы из джава бекенда, то знаете, какой замес идет вокруг слова var, например). И что, из-за субъективщины с собеса отлететь? Спасибо, но нет. В лайвкодинге субъективщины сильно меньше.
то его можно смело брать и не тратить время на следующих 10 кандидатов
А вот это вообще атас: кто первый встал, того и тапки. Поиск работы превратиться в херову беготню похлеще того, что есть сейчас. Так хотя бы у тебя есть шанс прорваться на интервью и победить оппонента своим уровнем (пусть и уровнем подготовки к собесу), то в предложенном варианте ты уже априори проиграл.
ну так прикол заключается именно в том, что вам как компании нужно нанять не ЛУЧШЕГО САМОГО СУПЕР ПУПЕР ИЗ СОТНИ ПРЕТЕНДЕНТОВ а просто того, кто вам подходит и кто справится с работой.
Ну утечет прога в интернет, люди будут знать что там за проект, и что? Они для собеса научатся ПИСАТЬ КОД КОТОРЫЙ БДУЕТ РАБОТАТЬ?! ну отлично нам именно это и нужно - можешь писать код, мы тебя берем. А задачи как раз бесконечны, ты на каждом собесе получаешь дополнительные куски кода, а значит новые задания всегда будут уникальными. Один человек добавил политики расчета кешбека, ты добавляешь запись их в базу, третий добавляет выбор категорий, четвертый все это рефачит итд.
И да, вопрос был сформулировн именно с точки зрения нанимающей стороны - им нужно нанять человека который справится с задачей, а они зачем то занимаются фигней, проверяя нерелевантные метрики и подключая вкусовщину на уровне ЭЙчАр. Вот вам решение - проверили умение писать "код эдэнтичный натуральному" в процессе собеса как раз произойдет РАБОЧЕЕ общение - как к задаче подходит, что уточняет, как подходит к формальным вопросам типа того же var или не var. И всё - можно его просто брать и просто нанимать, он абсолютно очевидно справится с типовыми задачами.
Ну утечет прога в интернет, люди будут знать что там за проект, и что? Они для собеса научатся ПИСАТЬ КОД КОТОРЫЙ БДУЕТ РАБОТАТЬ?!
Во-первых, можно и без капса обойтись. Во-вторых, если прога утечет в интернет, то в к любым вашим вопросам под данной кодовой базе легко подготовиться (да хоть жпт-агента всю кодовую базу грузануть).
А задачи как раз бесконечны, ты на каждом собесе получаешь дополнительные куски кода, а значит новые задания всегда будут уникальными.
Не будут они уникальными, т.к. вы сами говорите о "типовом" проекте и "типовых" задачах. Поэтому и подготовиться легко. Это плохо, т.к. в итоге не проверите кандидата: он просто надрочился специально под вашу кодовую базу. Да, на литкод, в теории, тоже можно надрочиться, но, повторюсь, у лайвкодинга сильно больше вариативность (в банк литкода входит несколько тысяч разноплановых задач), а значит к нему сильно сложнее подготовиться.
Ну так прикол заключается именно в том, что вам как компании нужно нанять не ЛУЧШЕГО САМОГО СУПЕР ПУПЕР ИЗ СОТНИ ПРЕТЕНДЕНТОВ а просто того, кто вам подходит и кто справится с работой.
Прикол заключается в том, что для вашей конкретной конторки, в которую минимальный конкурс (и вам надо отфильтровать совсем нулевых вкатунов), данный способ прокатит. Я же изначально писал о "более-менее крупной компании". Там это не катит из-за огромного потока кандидатов, в котором (не во всем, конечно, а в его некотором подмножестве) вам надо выбрать самого сильного, который не понизит, а в идеале, повысит средний уровень сотрудников компании (прочитайте про bar raising в амазоне).
Еще раз повторю: крупняку не нужен заурядный крудошлеп, крупняку нужен человек, "решающий задачи бизнеса" (самому не нравится этот штамп, но в последнее время его распространяют с высоких трибун): сегодня это будет круд, завтра кубер поднять, послезавтра архитектуру продумать. Поэтому надо проверить, как человек мыслит. Для этих целей лайвкодинг норм (хотя не идеален). Ваш собес не годится.
любым вашим вопросам под данной кодовой базе легко подготовиться
человек который может сходу писать бизнес логику в окружении которое примерно повторяет ваше - это человек который сможет писать вашу(без капаса) бизнес логику в вашем(без капса) окружении. Так это же буквально тот кто вам нужен, добрый день.
Не будут они уникальными, т.к. вы сами говорите о "типовом" проекте и "типовых" задачах.
Они будут уникальными на том уровне на которым им достаточно быть уникальными. 90% задач в IT и есть типовые и 90% вакансий в IT решают именно эти задачи, в том то и дело, что есть небольшая горстка людей которая упорно это отрицает, в то время как статистика показывает что это именно так и есть.
вам надо выбрать самого сильного, который не понизит, а в идеале, повысит средний уровень сотрудников компании
Дело в том, что алгоритмические интервью имеют недоказанную эффективность, статистически она не дает преимуществ, у меня в сбере 3 знакомых сениора в разных отделах на разных языках и все что я от них слышу это то что собесы проходят на мидла полнейшие нули, последняя история была что парень не справился миграцию простейшую написать(при этом алгоритмическое интервью он прошел).
Спросим тех же сениоров, кто им нужен в команду - в среднем обычный "крудошлеп", лишь бы он понимал как стек работает. Алгоритмы в работе используют единицы, однако чтобы подготовиться к собесу, приходится месяцок плотно долбить литкод, вместо того чтобы плотно подолбить свой стек.
Еще раз повторю: крупняку не нужен заурядный крудошлеп, крупняку нужен человек, "решающий задачи бизнеса"
а задачи бизнеса на 90% состоят из заурядного крудошлепства. Это просто факт. Самый распространённый вид приложений это круд, среднестатистические задачи в it это круд. Я понимаю, у вас может быть не так, но вы взгляните на ситуацию со стороны. Да банально откройте ХХ и гляньте какие какие требования к кандидату - подавляющее большинство требований подразумевают круд.
сегодня это будет круд, завтра кубер поднять, послезавтра архитектуру продумать
Вот отличный пример того, как вы обобщаете свой личный опыт и его натягиваете на все айти.
Допустим у вас команда 10 человек.
Сколько из них будут писать круд? - в какой-то момент все будут, это точно
А сколько из них будут кубер поднимать? Один. Один раз на проект.
А что самое интересное - алгоритмы ему поднять кубер не помогут никак, а попросить на "базовом" проекте что-то в кубере крутануть вообще то тоже можно.
Поэтому надо проверить, как человек мыслит.
Каким образом мой пример исключает проверку того как человек мыслит? Ну сформулируйте вопрос правильно и увидите не просто как он мыслит, а как он мыслит в рамках вашего конкретного стека, а не абстрактных foo bar baz
Во-вторых, если прога утечет в интернет, то в к любым вашим вопросам под данной кодовой базе легко подготовиться (да хоть жпт-агента всю кодовую базу грузануть).
Понимаю, что пример не вполне эквивалентный, но все же. Когда я учился в университете, лабы по программированию не менялись не то что годами, а, скорее, десятилетиями. Принимали их разные люди, когда-то преподаватель, когда-то аспиранты-лаборанты, отношение к процессу у всех было разным. Так вот, один из проверяющих, пообщавшись пять-десять минут, мог абсолютно безошибочно понять, кто выучил все возможные вопросы, но понимания при этом ноль, китайская комната в реальной жизни, а кто реально что-то понял и разобрался (про вариант с взял у предыдущего курса/купил, думаю, понятно сразу).
2)даем рандомную придуманную на ходу задачу - добавить ручку, для ручки сущность, для сущности миграциию в базу, и в сервис метод который будет делать то да сё.
Наблюдаем спину кандидата, который либо не знает, что такое "ручка", либо ему глубоко противна такая формулировка) Сорян, накипело.
просим его решить алгос, он решает, берем на работу. На работе говорим "сделай ручку" и получаем тот же самый резульат, только теперь все усложняется тем фактом что мы его наняли, пусть даже на испыталку.
Ну и конечно "сделай ручку" я написал в комментарии на хабре, задачи как раз нужно ставить так, как они будут ставится в проде. Если у вас принято сделай ручку - пишем "сделай ручку" если у вас принято "реализовать функционал сервиса позволяющий реализовать получение Х в виде У, методы проверки бла бла бла бла". Опять же, можно же прям на этом же проекте тестировать аналитиков - даешь им описание того что уде готово, просишь написать тз на новую фичу.
И в реальном энтерпрайзе редко заморачиваешься, например, производительностью.
Моё развлечение прошлой недели: попытки отлаживать код, исполнение которого занимает 18 часов. После пары часов медитации с инструментами анализа, без изменения базового алгоритма, время уменьшается до 75 минут. Да, это относительно экзотичный сценарий, но не то чтобы нулевой.
А самое главное, как раз если в норме команда разработки "не заморачивается" производительностью, то оценка асимптотик должна быть на уровне спинного мозга: логика "если окажется медленно, поправим" работает только если кто-то post factum тратит время и силы на оценку не медленно ли оно. А без этого отдел маркетинга поможет клиентам свыкнуться с мыслью что с этой скоростью надо жить, и мир в целом станет немного хуже.
Я всегда люблю в оптимизацию, иногда излишне, но часто сталкивался с тем, что мои коллеги не парились. На мой вкус слишком часто. Но в прикладном ПО, по крайней мере на фронте, часто можно реально не заморачиваться. Тупо не те объемы. А если что, то можно и в "помощь зала", отдать что-то внезапно затормозившие старшим товарищам на напильнинг и полировку
Если есть 1) "старшие товарищи" и 2) способность сказать "возможно тут проблема" вместо двадцати железобетонных аргументов "это так и надо" (к сожалению, она есть не у всех), то хорошо. А если нет ни того ни другого, то приходится рекомендовать клиентам использовать Firefox, потому что приложение кушает гигабайт в десять минут, а ответственный за фронт программист считает что так и надо.
Я могу быть пристрастен, лично мне как раз было неплохим отвлечением поупихивать вчерашний LeetCode в 7 мс времени, но от полного игнора производительности я проблемы в задачах за которые платят деньги вижу достаточно регулярно.
Не программист. Но добавить 0.5 к округлению сразу приходит в голову. Это же на уровне школьной математики задача.
В том-то и проблема, что чем больше «модных, стильных, молодёжных» решений, тем дальше программисты от школьной математики, логики и здравого смысла :( Идёт какое-то закукливание в волшебный мир орехов.
Сишник-приборостроитель — это физик+математик, умеющий кодить. Парадокс в том, что его код часто работает лучше, чем код человека, умеющего виртуозно кодить со всеми современными сверхмощными решениями. Потому что он не оторвался от (здравого) смысла происходящего.
Его код может работать лучше, но весьма вероятно он будет на 99% состоять из нечитабельного месива однобуквенных переменных и рефакторить/дорабатывать такой код будет очень больно.
…а по ночам он вообще ест детей… К любому портрету можно внизу на стене пририсовать такое туловище, которое захочется. Хоть козу, хоть франкенштейна-младшего. Ни одно описание не может вместить всю вселенную — поэтому всегда останутся белые пятна, которые можно заполнить по своему усмотрению.
Код, написанный с пониманием сути происходящего вне кода — как правило, очень легко читается другими людьми, тоже понимающими суть происходящего вне кода. Он структурирован и прокомментирован именно в соответствии с тем, что при этом происходит в материальной вселенной.
Не, ну бывает всякое, тут я не буду спорить… у всех бывает «всякое» :)
Чуть-чуть не успел дополнить комментарий…
…если хотите реальных, а не надуманных проблем — то, например, очистка массива через sizeof(). «Настоящий программист» никогда так не сделает, а «инженеру» эти правила хорошего тона неведомы — он сделает, и потом за ним «настоящий программист» где-то поменяет статический массив на указатель с динамической аллокацией, а посмотреть, эквивалентны ли они — не догадается, потому что все привыкли писать «по феншую», чтобы они были эквивалентны везде. И вместо memset (массив, 0, sizeof(массив)) будет memset (указатель, 0, sizeof(указатель)), то есть по сути обнулятся только 4 или 8 байт в начале, а не весь массив. Классика для программиста, а инженер в неё может влететь запросто.
В отличие от «нечитаемого месива однобуквенных переменных», эта категория проблем реальна и типична для.
Т.е. в реальной жизни задача, на которую на собесе выделяется полчаса может решатся и сутки-двое и бизнес это вполне устроит.
Вот только вчера об этом говорили с коллегами. Что куда важнее написать тесты вдоль и поперёк, особенно если это какой-то новый алгоритм (а зачем повторно реализовывать существующие?).
Мне вообще непонятно, каким образом алгоритмические, а точнее спортивно-олимпиадные задачки заехали в большинство собесов. У вас ещё более-менее адекватная задача, а зачем красно-чёрные деревья реализовывать на листке бумаги, я откровенно не понимаю.
А обычный сеньор, который оказывается звездой на letitcode вызывает вопросы. Когда он нашёл время на все эти задачки?
А на этот вопрос вы сами себе отвечаете:
О! А я её на собесе яндекса решал
Захочешь в Яндекс — и не так, простите, задницу рвать начнёшь. Добро пожаловать в чеболизацию по-русски. Я честно пытался найти ДРУГИЕ причины, но мне кажется пора перестать делать вид, будто они есть. Причина одна и стара как мир: если у тебя столько бабла, что люди стоят в очереди чтобы хоть как-то прильнуть к нему, то ты можешь делать что хочешь. Это касается как людей, так и компаний.
Мы вот рады, когда кандидат понимает, как работает flow-sensitive typing в TS, хотя бы просто на конкретных примерах. И то редко такие встречаются.
Я не готовился к собесу Яндекса. Я вообще был удивлён, почему они моё резюме рассматривали, у меня з/п стояла выше рынка. Но на собес сходил, получил удовольствие. Выяснил на след собесе (алгоритмическое я прошёл), что им требовались еще и хорошие скилы девопса. Увы, это пока(?) не ко мне.
Я не знаю когда вы проходили у них собеседование. Но последние года 2 мне прилетело от них наверное 5 или даже больше предложений из разных команд. То ли я такой красивый, то ли они уже всем подряд рассылают предложения. Сейчас они вообще предлагают поработать в нескольких командах и выбрать ту самую. Что-то мне подсказывает, что не всё так радужно у них в найме.
Когда я учился программированию, в учебниках большими буквами было написано, что тестирование не гарантирует правильность программы и вообще не является инструментом разработки.
Современная увлечённость тестами, честно говоря, производит удручающее впечатление. Притом, что качество кода постоянно падает.
Это как если бы строители строили мост наугад до тех пор, пока он переставал бы разрушаться под проезжающими машинами.
Юнит-тестирование важно для рефакторинга (чтобы при малейших изменениях не утонуть в регрессиях) и неплохо помогает поддерживать хорошую архитектуру (к лапше вы просто не сможете написать тесты нормально). Интеграционное тестирование туда же.
Тестрование важно в целом для отлова ошибок. Оно не гарантирует их отсутствие, но при правильном подходе существенно помогает их отловить. Люди не роботы, и человеческий фактор всегда будет присутствовать. Невозможно всю жизнь писать код сразу правильно, ни разу не проверив, насколько корректно он работает. Ну, если вы только не Чак Норрис.
Альтернатива - формальная верификация, но для сколь-менее сложных вещей это настолько долго и дорого, что скорее утопия.
Тут скорее наоборот, современный софт часто скатывается в неработоспособное говно, потому что фирмы экономят на тестировании - мол, некогда тестировать, надо фичи херачить и рынок занимать, если что, юзеры протестируют, а мы обновление выпустим.
Что помешает написать тесты к лапше?
Ничто не помешает. Но тест к лапше тоже лапша. Сам факт лишних усилий по написанию сначала кода, а потом тестов, должен орать как сирена о том, что вы что-то делаете не так. Важно говорить об этом джунам в самом начале.
То что 3 метода на экран каждый по 20 когнитивки вы покроете легко. А один на 3 экрана и 20^3 когнитивки - или халтурно, или никак.
Как минимум:
1) батарея автоматических тестов по прошлым багам является инструментом защиты от регрессий и, по совместительству, хранилищем странных краевых случаев;
2) писанный протокол ручного тестирования позволяет быть уверенным что по крайней мере функциональность основных, оптимистичных путей выполнения не сломана совсем;
С моей точки зрения это вполне себе практически полезные, достижимые разумными усилиями гарантии.
что тестирование не гарантирует правильность программы и вообще не является инструментом разработки
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы:
а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста.
б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 99% случаев именно unit-тестирование.
Мне вообще непонятно, каким образом алгоритмические, а точнее спортивно-олимпиадные задачки заехали в большинство собесов.
Дык, избыток кадров при нехватке вакансий. Скоро вангую что будут требовать снять видео о себе при подаче на вакансию.
Эти интервью пошли из ФААНГов, где всякие большие данные и алгоритмы действительно нужны. Я, например, даю те задачки, которые сам лично в прод коммитил и они ни по какому критерию не отличается от литкодовских. Там и динамическое программирование есть и бинпоиски с жадностями.
Там же единственный минус этих собеседований - ложный отсев хороших кандидатов - не страшен из-за очереди за забором. Вот когда всякие мелкие фирмы с сайтами визитками начинают копировать эти интервью, то это каргокульт и они сами себе злобные буратины.
Edit: и кстати, снимать видео не заставят. Просто задачки станут сложнее. Сейчас дают leetcode medium, будут давать hard.
в js префиксный плюс, это устоявшаяся идиома для конвертации в number, кстати, можно и про неё поговорить
Не нужно про неё говорить. Её нужно оставить для JS-квестов типа "посчитайте среднее по массиву за 8 символов" и в таком духе. В реальном коде абсолютно нечитаемая магия, особенно если JS/TS для вас - очередной-язык-на-котором-приходится-прогать, а не мечта всей жизни.
По мне очень часто используемая идиома. Например, чтобы конвертнуть из string, особенно из форм
if (+form.age >= 18) { // ну началось
А поговорить можно про то, что это на самом деле это краткая форма
0 + form.age
и, возможно, в других языках с динамической типизацией оно тоже работает
Динамическая типизация вообще редко бывает слабой. Это чуть ли не уникальная фишка JS.
на самом деле это краткая форма
Что вы имеете в виду? В одном случае это бинраный оператор, в другом - унарный.
если вы точно знаете что это строковое представление числа, то Number(myStringNumber) намного понятнее, а если вы не знаете что вы туда скармливаете то плюсик все равно не поможет )
+{}
NaN
+{} >= 18
false
Я не знаю, как ты в мою форму подложим вместо строки объект, но теперь точно никакой порнухи, бро!
Зависит от стайлгайда. Если будет принят стайл гайд с Number() и String(), то я буду их использовать, а если нет, то + и ${}
И почти никто меня не осудит, поскольку идиомы устоявшиеся
В который раз убеждаюсь, что все эти интервью - полнейшая лажа. Буквально же автор признается в том, что его способ интервьюирования не работает. Давайте еще раз посмотрим внимательно, что нам говорят.
1. ТС придумал оригинальную, как ему кажется, задачу, которая, цитирую "Огонь! Соискатель знает что такое округление" - здорово отсеивает кандидатов, которые не посещали школу после пятого класса.
2. Периодически к нему попадают кандидаты, которые эту детсадовскую задачу решают не задумываясь
Автора это бесит, потому что его огонь-задача никак не помогла ему оценить кандидата. И почему-то это проблема кандидата, ведь он пришел подготовленный, негодяй какой.
Какая прелесть!
Что же делать? Перестать заниматься ерундой. Во-первых, не надо считать себя априори умнее кандидата на вакансию. Ну правда, кто ты такой, чтобы задавать мне детские задачки, проверяя, знаю ли я про округление. Это просто глупость и унижение. Во-вторых, у каждого есть определенный опыт за плечами, и это первое и главное, что определяет меня как специалиста, а не твои глупые вопросы на сообразительность. Если я имею за плечами условно десять лет веб-разработки, то очевидно, что я кое на что способен. Если не веришь, дай нормальное задание и будь готов оплатить мне потраченное время, не должен я тебе доказывать что я не идиот. В-третьих, есть испытательный срок, специально придуманный для отсева некомпетентных сотрудников.
В-третьих, есть испытательный срок, специально придуманный для отсева некомпетентных сотрудников.
Полагаю, этот механизм сейчас работает плохо из-за высокой доли вкатунов и откровенных самозванцев. Ну т.е. человек проходит фильтр, и сразу приносит компании минус 300-500к. А лишние деньги у всех закончились.
Вот не понимаю, зачем столько яда так агрессивно?
Мне хотелось проиллюстрировать идею и я взял самую простую задачу, в которой можно было показать как можно прийти к результату с помощью наводящих вопросов. Мог бы взять например сортировку вставками - но статья была бы больше, а вопросы "зачем это спрашивать?" всё равно бы были. Задачу на округление я обычно подкидывал людям вне работы. На собесе очень редко и только в качестве доп. вопроса.
По повода проверки округления. Я лучше проверю, что кандидат умеет в округление, чем не проверю. Это пара минут, которые могут сэкономить много времени потом. Да, мне более важно как кандидат проверяет входящие параметры в задачах (с чем люди лажают чаще, чем с округлением), но и бывают люди и не умеющие в округление с вполне приличным резюме. Если бы я с такими не сталкивался, я бы и не проверял, для меня это было откровением.
Джуна я бы точно проверил бы и не стеснялся бы.
показать как можно прийти к результату с помощью наводящих вопросов.
У меня не меньше агрессии, как отчитайте меня тоже. Программирование не вчера изобрели, уже поколение знающие люди говорят, что наводящие вопросы не работают, раздражают.
Вы вот буквально сделали все в примере, чтобы кандидат не вспомнил, что такое округление, а думал, как решить проблему кодом. А ведь проблема никогда не была в коде.
Не имеет значения, какие из этих дурацких задачек вы будете задавать, сортировку или нет, человек, который потратил время на щелканье задачек будет справляться с ними за милисекунду, потому, что моментально узнает паттерн, возможно даже будет достаточно опытен, чтобы дать вам потешить эго и предложить "улучшить решение".
Я еще никогда не понимал: "да это простейшая задача на уровене N класса..." да, блин, я уже забыл как большинство одноклассников не то что выглядели, а как звали, не говоря уже про то что когда-то учил, но регулярно не использовалось. Даже университетская программа, уже не так хорошо помню ту же линейную алгебру и какие-то простые геомеьрически алгоритмы даются со скрипом. Хотя в те годы я бы их щелкал быстро.
Почему надо готовиться, исходя из своего опыта. Как правило если говорим о бигтехах кандидат ограничен временем к примеру в час на 2-3 задачи из алгоритмической секции, если до этого не нарешивал скорей всего может уйти больше времени. Для львиной доли задач которые дают на собесах есть паттерны вроде "два указателя", "бинарный поиск", но как правило в работе такого рода задачи реализовать не требуется, а как известно нетренериуемый навык угасает. По себе знаю, что спустя полгода-год реализация корнер кейсов для того же бин поиска вылетает из головы как по щелчку.
Прорешивая тот же литкод решение становится очевидным, как только побьешься об него какое-то время, но попавшись в первый раз не всегда складываются мысли в пользу очевидного простого решения. Тут хочется задать риторический вопрос - если кандидат кандидат подготовился к собеседованию и знает ответы на все вопросы, смог и ответил на все вопрос, делает ли это кандидата подходящим для вакансии?!
Я не готовлюсь только по одной причине, я 10-лет назад, имея под рукой несколько лет абсолютно уникального и крутого опыта мог проиграть вчерашнему выпускнику МГУ с 0 годами опыта и придуманным опытом в резюме. Так и сейчас могу.
Я не понимаю, в чем ценность решения задачек. Может сейчас Bun любую из этих функций интерпретатором доведет до идеального времени. Может у вас в проекте es5 и полифилл .map медленнее, чем "for" в 24 раза, а вы тут native-C++ вызов Math обсуждаете.
Вот сядет какой-то чувак напротив меня и спросит такую задачку. И есть только 2 варианта исхода, - мне сразу придет в голову ответ и не сразу. И если не сразу, умея строить сложнейшие системы в мире, буду слушать "а что если вы немножко подумаете, как улучшить это решение, не волнуйтесь, если вы не сразу пришли к решению, это не обязательно повлияет на оценку"
Можно же просто открыть рот и поговорить, предложить мне рассказать что-то, что вызовет интерес к моей кандидатуре.
Да я тоже за собеседование про опыт и задачи решенные, и в обратную сторону про компанию и задачи, а не за экзамен. Ну максимум кусок кода почитать обсудить что код читаешь как-то а не просто теоретик. Дальше уже на испытательном только может быть понятно. Ведь чел может решить все литкод-задачки но не смочь разобраться в реальном продукте, как и обратное тоже может быть. Для тех кто редко проходит собесы и уже далек от студента стрессовость ситуации может затмить реальный опыт. Также человек может быть вообще не договоропригодным и не командным - как это понять на собесе?
Обычно я задаю вопросы по реальному коду. И если кандидат не может разобраться, то пусть он хоть крыло боинга в уме спроектировать может, то чем он мне может помочь? И да, если сразу идет туго, я задаю наводящие вопросы. Или подсказываю внешне кейсы, где код используется. Задача просто иллюстрация.
По поводу реального опыта и прочего. Эта статья - спин-офф другой статьи, где я как раз немного подстебываюсь над обобщаю опыт "технической составляющей" собеседований. Пока лежит в черновиках, но планирую в среду четверг дописать и опубликовать
Давайте оставаться в теме статьи, которую вы написали, озаглавили и дали по ней тезисы. Вы назвали статью "Почему я не готовлюсь", ваш главный тезис "потому, что задачки нужны, чтобы посмотреть, как вы думаете".
Я, среди прочих комментаторов не согласен, что задачки способны помочь увидеть, как кто-то думает, только то, как много собеседований ему пришлось пройти перед вашим и потеряв надежду заучить не только задачки, но и как "постепенно" на них отвечать, не вызывая подозрений.
В процессе изложения статьи вы показываете, что те, кто готовятся к задачкам правильно делают, соответственно, заявление в заголовке выглядит вашим confirmation-bias, а итоговый тезис содержанием статьи не поддерживается.
Будет другая статья, - прокомментируем другую. Написали бы по-другому статью, - я бы и прокомментировал по-другому.
Ага и попадется на интервьюера, котором у нужен барабанщик.
Кстати, возьмите задачку с letitcode, зазубрите, а потом представьте как вы будете отвечать не понимая задачи или даже понимая. Вам придется эмулировать варианты решения вроде как логичные, только не реализуемые или реализуемые неоптимально. Накидывать код, который кстати могут попросить и дописать. Имхо, это сложнее чем вы думаете)
Я бы вам рекомендовал не апеллировать к личному опыту и представлению, это непродуктивно, вы зачастую общаетесь с людьми гораздо опытнее себя, уже представившими, попробовавшими все на свете и отсобеседовавшими море кандидатов, если все будут мериться только своими впечатлениями, ничего полезного никто не извлечет.
Видите ли, проблема в том, что задачки отсеивают сильных кандидатов, а не неспособны отсеять слабейших. Вы совершенно правы, что человек, не имеющий никаких знаний, заучив задачки как текст ничего из них полезного не извлечет.
Но человек, регулярно проходящий собеседования это не человек, заучивающий текст задачки. Смысл в том, чтобы классифицировать задачи, - увидев несколько задачек на поломку значений в EventLoop будет не важно, что вы не помните код дословно, вы узнаете проблему. Вы не запутаетесь, не проглядите кусок задачи, помните внешний вид итоговой функции и даже легко сделаете вывод, что вас попросят дописать решение и не создадите себе проблем уникально или излишне решая первую часть.
Извините. А можно мне прогера, который умеет делать простейшие системы) Сложнейшие не надо, и так тут черт ногу сломить.
Я не понимаю, в чем ценность решения задачек
Они имеют ценность если вы ищете не опытного инженера, а просто человека с высоким уровнем IQ и базовыми навыками программирования, который будут быстро находить решения для незнакомых задач. Это очень специфичный отбор для узкого числа компаний, большинство же применяет алгособесы просто как карго-культ, не понимая зачем они это делают.
Я согласен с подходом автора. Проблема в том, что цель выбрать "идеального" из множества вариантов, а не быстрее нанять "достаточно подходящего". И в эмоциях.
1. У бизнеса есть идея/надежда, что такой "идеальный" и дальше таким останется на других проектах.
2. Проводящему собесы намного "интереснее" самоутвердиться и рассказать менеджеру, что тот кандидат "даже ... не знает".
Ну это эпик фейл для конторы. Хотя многих таки встречал )
Я так и не понял чего вы добились этими бредовыми задачками. С бредовыми требованиями. Задача была найти формальные отмазки почему отсеяли хорошего кандидата? К счастью меня никто такой бред пока не спрашивал. В том числе и на алгоритмических интервью.
Не используя дополнительных переменных. 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-ить код лучше, чем это делает либа.
Во многом я с вами согласен, но идея статью все таки не обязательно о найме только сеньора, и градации кандидатов больше для лулзов, чем как руководство к действию.
Мне интересно смотреть кандидатов, в ситуации когда они сталкиваются с лютой дичью трудностями, а не образцово показательной задачкой.
По поводу some вообще не имею ничего против, как и против спредов в resume. Я знаю что some работает в некоторых случаях почти всегда медленнее, чем find/findIndex, а сред медленнее, Object.assign, или прямое присваивание свойства, если оно не одиночное (и то вкусовщина). Но читается и some и спред лучше, поддерживать проще (по моему мнению, так-то можно спорить). И если у меня нет задачи выжать железку до кровавого пота, то я использую и то и другое). И да, я чаще использую подготовленные маппинги внутри циклов, чем поиски с тем же some. Но опять же я не парюсь и в небольшой выборке воткну some и spred просто чтобы написать на несколько строчек кода меньше.
Ну и если в команде не принято some я не буду писать some ) Я и не в таких извращениях вполне разумных стандартах участвовал.
По поводу 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: нам нужна его позиция
Тут нет выбора. Каждой задаче свой инструмент.
Мне интересно смотреть кандидатов, в ситуации когда они сталкиваются с
лютой дичью
Если лютая дичь очень оторвана от реальных задач то ценность таких тестов крайне низкая. Более того, это нерациональный отсев достойных кандидатов, которые могли бы стать отличным дополнением вашей команды.
больше для лулзов
Мне кажется вся статья скорее для лулзов. Хотя подана довольно серьёзно.
Читал статью, согласен )
Врать не буду, сам не проверял, но у меня коллега оптимизировал затычку с производительностью, обнаружил, что 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 - для меня это оградка, что там реально экшен. Но опять же всё на вкус (и в данном случае на объём). Конечно, если объем неизвестен, лучше предполагать, что он большой.
Мне кажется вся статья скорее для лулзов. Хотя подана довольно серьёзно.
Чужую статью каждый обидеть норовит )
Имелось ввиду, что 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. А разница в асимптотике внезапно оказалась вопросом вкуса.
Да блин, куда мы катимся.
Чужую статью каждый обидеть норовит )
Приходите ко мне в статьи и обижайте. Я просто люблю называть вещи своими именами.
А людям плевать. Хоть 1000. По моим недавним тестам разница уже видна на 10 элементах. На 100 она уже неприличная
Блин что такое можно на воротить на 100 элементах. V8 неприлично быстрый. Там между нажатиями клавиши можно то массивы на 1000 элементов сортировать, никто залипания не заметит
Это очень странный тред. Не врубиться поначалу, это нормально, с кем не бывает. Но вот это искреннее непонимание сути проблемы к 6-му уровню вложенности уже подмывает авторитет автора статьи.
V8 неприлично быстрый
Да конечно. На порядки медленее сишного кода.
Помимо того что веб-разработчики часто думают что V8 неприлично быстрый, они зачастую верят что V8 оптимизирует их говнокод, хаха. Много раз уже на такое натыкался. Естественно познания в том как работает V8, как устроены объекты в памяти и т.д. обычно отсутствуют как класс. Только вера в бога V8, ведь в Google олимпиадники работают, они там всё оптимизировали. Ах... Не знаю это должно быть грустно, смешно или смешно и грустно.
Спасибо за ваш комментарий. Он есть яркая демонстрация до чего мы (web-разработчики) деградировали. Написать O(n^2) вместо O(n) на пустом месте теперь норма. Не ну а что, мы же в 1\60 секунды ещё помещаемся, т.е. пользователь проблему не увидит. А раз не увидит, значит это не важно. Нет залипания = нет проблемы. Merge :) Спринт горит!
По сути вы даже не видите в этом проблемы. Честно говоря, после этого все эти рассуждения про джунов, мидлов, виды округлений, скорость .find-а и пр. просто теряют всякий смысл. Тут база сломана. Сама основа.
Сейчас сюда нужен комментарий про "Premature optimizations is the root of all evil" :)
Я уверен, что я не очень плохой программист, хотя я не программист чисто, а "разнорабочий".
Но я бы не догадался о точном ответе в этих всех задачах, особенно под давлением на собеседовании. Вообще ожидание точного ответа на единственный вопрос (или три) всегда мне казалось самым худшим вариантом. Обычно чем больше вопросов, тем больше понимаешь уровень человека, по крайней мере это мне всегда помогало на большом количестве собеседований, которые я сам проводил.
Скорее - это значит, что я плохой интервьер, если не смог дотащить до решения. Я там выше в комментах писал, что задача на округление была придумана как развитие идеи задачи x => 7-х, поэтому мне показалось, что это хороший путь к решению. Но, опять же, пример абстрактный)
После ответа я понял, но я не о том даже. Просто если кто-то на один вопрос не ответил - это не показатель, вот я о чем.
Я не могу сказать, что хороший интервьювер, уже курс посетил, но все-равно много случайного. И всегда все супер субъективно.
Еще я заметил, что один на один - это неправильно. Можно какой-то ответ трактовать не так или джуна посылают делать интервью, а он решает, что человек сказал ерунду.
Общий посыл статьи понятен, но пример не очень удачный - floor(x + 0.5) это супер-известный паттерн, примерно как !!x или ~~x. Я не знаю, что и где нужно проспать, чтобы не знать этого. Хотя, как справедливо заметили выше, возможно это фильтр мимокрокодилов.
Почему я не готовлюсь к алгоритмическому интервью
Потому что я не хожу на собеседования, где есть алгоритмическая секция.
Если серьезно, на рынке куча вакансий в самых разных направлениях (как бэкендер говорю) – и финтех, магазины и CRMки, и какая-то аутосорс разработка, какие-то датчики, сканеры, интеграции с 1C. При этом разные базы, разные архитектуры, паттерны, целая россыпь вспомогательных технологий по типу кэширования и брокеров сообщений. Чего только не написали разработчики, что необходимо поддерживать, развивать и иногда переписывать. А еще у продуктов есть огромная бизнес сложность, которую надо знать и понимать, поэтому с наскока в новой компании вряд ли получится себя проявить, потому что ближайшие 3-5 месяцев будете изучать домен приложения, используемые подходы, основные процессы внутри приложений и их взаимодействие и т.д.
Я бы оценивал умение мыслить и понимать, как строить связи в БД, как организовать общение между приложениями, как проводить тестирование и сделать автоматический пайплайн выкатки, как выделить переиспользуемые вещи в библиотеки и т.д. Если кандидат может на эти темы рассуждать, а уж тем более может на своем опыте рассказать, то скорее всего он быстрее въедет в текущий проект, быстрее адаптируется и будет приносить пользу, нежели тот, кто сможет из себя выдавить решение какого-то алгоритма. Причем сейчас уже расцвет нейронок, можно целые методы скармливать нейронке, которая предложит декомпозицию, разделит по интерфейсам, и перепишет алгоритм с известным и более удачным решением.
Я среди собеседований не люблю два вида зла. Первое, где тебя проверяют на алгоритмы. Причем вот именно на "понимание", и если ты их не решал и не сталкивался по работе (а скорее всего и не сталкивался), то все эти наводящие вопросы нисколько не помогут. Интервьюер будет считать тебе некомпетентным, потому что ты не знаешь "базу", а у тебя тоже будет осадок, вроде и работаешь, и опыт есть, и успешные проекты за спиной, а тут какую-то "базу" не знаешь.
И второе, что не сильно уступает первому, это когда тебя проверяют насколько из тебя хороший статический анализатор получится. Тебе расшарили экран, перед тобой 20 строчек кода в каком-то онлайн блокноте, скомпилируй в голове. А там все что угодно, от абсолютно идиотских случаев множественного наследования с базовыми конструкторами, до каких-то задачек создания потока внутри нового потока.
Почему нельзя спросить теорию, если очень хочется - можно спросить вглубь, узнать что кандидат знает помимо верхов, где использовал, какие камни и т.д. Попросите спроектировать небольшое приложение, пусть расскажет какие будут компоненты, как буду храниться данные, как выдаваться и т.д. Можно сделать лайвкодинг — типа вот обработай массив ФИО и сделай какую-то итоговую строку, или подцепится к какому-то API и сформировать результат.
Про это примерно будет в след статье.
А про статанализатор - зря. Вам же показали, что вы там чинить будете, если что. Так что у вас есть право испугаться и убежать. А вот если код с потолка взят и там ошибка в <T<T1, Partial>(T3).... То тоже можно понять, что им никто на самом деле не нужен
А на счет теории... мне кажется, что просто не знают как спрашивать, может автор и знает, но все как обычно... коммуникация, один называет термин так, другой сяк... а объяснить значение, четко и по делу... времени не хватает.
А вот практика.. тут уже по делу можно судить, и вопросы задавать
Сначала думал, что это очередная статья в стиле "есть куда более лёгкий способ отсеять людей, чем алгоритмы", но к концу прочтения изменил мнение и во многом согласен с автором.
Я бы догодался до решения, на собесе, но к сожалению не сразу. Вот примерно, что набросал, когда прочитал и понял задачу: (x) => Math.foor(x) + (x % 1 => 0.5 ? 1 : 0)
Однако, решение в идеальном примере, мне нравится больше. Моё слишком громоздкое и хоть условие с 1 floor соблюдено, это точно всё и близко не уровень сеньора. Плюс, мой основной ЯП не JS и далеко не всю его специфику знаю.
Согласен со всем, кроме того, что "зубрить алгоритмы нужно в основном джунам". Честно я бы никому их зубрить не рекомендовал, если это напрямую не связано с работой. Знать основы алгоритмов думаю нужно всем, но углубляться в них сильно, пожеланию.
Решенная задача в лоб, лучше красивой нерешённой) Это специфичный прием, кому-то знакомый, кому-то нет. Сеньорность и джунство, это шуточки, которые я видимо недостаточно выделил как лулзы.
Когда я даю эту задачу для меня больше интересна реакция человека на решение. Не важно, сам он её решил или я в конце концов рассказал. Обычно её я даю больше для проверки на софтскилл, насколько кандидату кайфово от красивого решения.
К этому моменту мне хардскилы обычно понятны. А для статьи выбрал потому что она простая и красивая и можно, пусть чутка коряво, подвести к решению.
Да, лулзы не выкупил и воспринял относительно серьёзно.)
Поэтому мне статья и понравилась, вы всё верно делаете и такой подход одобряю. Самому не нравятся собеседования экзамен лайк. Помню был собес, где спрашивали по всей теории, несколько часов. Когда не мог ответить, ведущие просто, молчали упиваясь моментом. Причём один раз говорил, что надо идти, но реакции ноль. С высоты текущего опыта, понимаю, что они сами в вопросах слабо разбирались. Лучшие же собесы, когда всегда уходил из компании с хорошем настроением (не важно был ли офер). Люди использовали похожие на ваш способы. Не задавали вопросы с молчанкой, а вели диалог. Мне понравился метод в одной компании, когда давали плохо написанный класс, говоря: "давайте вместе исправим". После диалога всё становилось понятно, т.к проверяли не олимпиадный рефакторинг, а навыки общения, способность быстро разбираться в чужом коде и искать решение проблем, используя все доступные возможности. Вы делаете если не точно так же, то примерно в этом же ключе, так что полностью поддерживаю.
Касаемо задачи, по идее это второй вариант решения из статьи, только заменил x - Math.floor(x) на x % 1. Про остаток от деления, помню со студенчества, поэтому первым в голову и пришёл. В люблю случае согласен, эта задача нужна для другого.)
Считаю полнейшим маразмом, если в формулировке задачи есть: не используя чего-то. Давайте тогда ставить условия: А теперь то же самое, только с мышкой в левой руке... А теперь не сидя, а стоя на одной ноге.
Если есть инструмент, то его надо использовать любым доступным способом, иначе это дебилизм какой-то. Главное — качественный результат. В данном случае — быстрая, надежная программа, использующая минимум ресурсов, написанная с небольшой затратой времени программиста.
Анекдот про вводные помните?
Вообще это можно сказать устоявшаяся практика, давать новые вводные по задачам, кто я такой, чтобы её ломать? )
Когда я учился на права, инструктор сказал мне относись к экзамену как к игре. Тут немного не те правила, по которым ты будешь ездить, но чтобы ездить ты должен пройти эту игру.
Вот сейчас ты включил поворотник направо, а впереди нас дятел, который купил права и не знает, что надо включать правый поворотник, когда главная уходит налево, а ты едешь прямо. Он сейчас подумает, что хочешь свернуть на прилегающую и щеманётся с прилегающей как на пожар. Но на экзамене ты должен включить поворотник, даже если опять увидишь это корыто) Иначе он будет ездить, а ты нет
надо включать правый поворотник, когда главная уходит налево, а ты едешь прямо
??? Это в каком месте ПДД такое написано?!
А если работает светофор, то надо, по его мнению, учитывать направление главной дороги при включении поворотников или нет?
Я за полмиллиона километров водительского стажа не припомню, чтобы видел на дороге хотя бы одного водителя с таким странным образом мыслей. Хотя может и не обратил на кого-то внимания.
P.S. Ещё подумал - может быть, Вы имели в виду не направление главной дороги (что является исключительно вопросом приоритета движения при отсутствии светофора), а изгиб улицы?
Значит, это отменили уже. В 21 году действовало ещё (забавно, что когда "город" сдал в упор не помню включал я поворотник или нет, притом скорее нет)
Никогда такого не было. По требованию ПДД, сигнализация указателем поворота должна быть однозначно понятна другим участникам движения. В том числе её должны понимать и те, которые, например, едут сзади и ещё не видят видимых вам дорожных знаков (особенно если вы на фуре) и, в частности, не догадываются о направлении главной дороги.
Думаю, дело не в главной дороге, а в том, что она просто уходит влево. То есть водитель видит перед собой обычный перекрёсток, а по всем документам это двойное примыкание дороги справа, совмещённое с крутым поворотом.
К сожалению, бюрократы живут в написанной ими же реальности, и с реальностью, что дана нам в ощущениях, их реальность совпадает не всегда.
Такая проблема действительно есть.
Видимо да. У нас в строгино есть два поворота на пп 6016 https://yandex.ru/maps/213/moscow/?ll=37.395207%2C55.790663&z=16.79 , где при движении прямо мимо поворота в пп (когда он остаётся по левую руку) надо на экзамене включать поворотник, три года назад так точно
Мой бы первый вопрос был "а почему я не могу использовать стандартную функцию?"
После какого либо ответа, я бы полез в исходники этой функции и скопировал много раз проверенное и гарантированно рабочее решение.
В ЖС это невозможно, поэтому третий вариант - вбить в гугл "округление числа JS" и посмотреть способы решения. Даже если решение очевидно - могут быть подводные камни и нюансы, которые надо проверить заранее.
Ну и когда я буду уверен что решение (x + 0.5) оптимально (а оно не оптимально, выполняется куча лишних операций), я буду его использовать.
При этом речь вообще не про логику или математику. На месте этой функции может быть любая другая. Алгоритм бы не поменялся. То есть уровень моей квалификации допускает ошибки даже в простейших (на первый взгляд) действиях, и я бы хотел видеть похожий подход и от джунов.
Чьё собеседование, того и правила)
И как много реально хороших специалистов нанимаются после собеседования с позицией "мой созвон - мои правила?"
И как много людей придет к вам на собес после того как вы эту позицию совершенно по-хамски озвучили?
Как минимум на одного меньше, но попробуйте дать другой ответ не используя функцию вычитания \sarcasm
Собес - не экзамен и не чесание ЧСВ любого из участников, а способ договориться и присмотреться друг к другу
Если ваша позиция - "я тут барин, мои правила, хочу - верчу", то либо у вас очень много денег для найма, либо я вежливо с вами попрощаюсь в конце собеса и больше не буду желать работать с вами вместе
const 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))
Извините, что не в тему, но есть пара мыслей:
1) как же специфичен js (он не плох и не хорош, он для своих задач задумывался и применяется)
2) решать алгоритмические задачи на js - это использование инструмента не по назначению
Ну серьезно, вся эта дичь с конвертацией и с неявными преобразованиями типов в зависимости от расположения переменной/оператора в инструкции (помимо плохого дизайна языка) должна наталкивать на мысль и на вопрос "для чего используют js в целом?". По идее, ответ на этот простой вопрос уже многое может сказать о качестве соискателя.
Весовой коэффициент алгоритмических секций переоценен, на мой взгляд
Я тоже считал js каким-то недоделанным языком, который придумали для боли. Но потом начал на нем плотно писать и удивился. Как раз к тому времени появился v8, который шустрит как электровеник, сахарок: стрелки, нормальные классы, куча библиотек и... Мне очень комфортно
Я бы расценил задачу как "догадайся, какой ответ у меня в голове" и либо сразу ушел бы, либо начал бы троллить собеседующего:
"У вас политики безопасности запрещают Math.round(x)?"
"Как часто я буду встречать такой минифицированный код на проекте?"
"Чем обусловлено именно Math.floor, по моему опыту такие специфические задачи (мы же реальную задачу решаем, да?) обычно содержат неявные требования, которые можно решить эффективнее."
Правда, если вы на собедесовании "доводите" программиста (во всех смыслах) до нужного вам изящного решения, то выкиньте эту задачу или перестаньте собеседовать.
Лучшие задачи, наоборот, не имеют одного конкретного изящного решения которое вы ждете и позволяют наблюдать за тем, как человек размышляет и какие подходы имеет. Более того, я обычно для снижения стресса и избавления от "экзамена" сразу говорю, что задача не имеет конкретного решения
Это тоже метод, но разве я где-то в статье писал, что нужно вот такую конкретную задачу? Не путайте пример с рекомендацией)
либо сразу ушел бы, либо начал бы троллить собеседующего
Отсеять кандидата, с которым потом намучаешься из-за его плохих гибких навыков (софт скилз) - хороший результат собеседования.
Только вот ведь какая загвоздка - ни один работодатель ни то что не мучался, а даже не жаловался на мои софт-скиллы. Раньше, до исхода айтишников даже обратно звали.
Так что моя т.з. верна - даже для проверки софт-скиллов существуют задачи куда лучше.
не жаловался на мои софт-скиллы
Во-первых, Вы на 100% уверены, что умение решать логические, математические и, возможно, алгоритмические задачи не помогает лучше решать практические задачи, хотя это не доказано. Более того, Вы демонстрируете своё негативное отношение к тем, кто считает иначе.
Во-вторых, Вы судите о целесообразности поступков собеседника, не зная его мотивов. Например, собеседующий может задать вопрос, чтобы узнать, как Вы реагируете на подобные вопросы. Возможно, он даже рассчитывает услышать от подходящего ему кандидата ответ "не знаю" или подобный.
В-третьих, троллинг собеседующего выглядит нерационально.
Что касается Ваших работодателей, то я могу назвать несколько возможных причин, почему они этого не заметили или это для них не критично.
Ну, или мы на хабре, а не на собеседовании или работе)
Если подумать, то мои софт-скиллы даже лучше чем твои потому что мне, при всей грубости, хотя бы хватает достоинства не перевирать собеседника:
"Вы на 100% уверены, что умение решать логические, математические и, возможно, алгоритмические задачи не помогает лучше решать практические задачи" - вот это какая-то тупая инсинуация, не делай так.
не перевирать собеседника
Я не перевираю. Возможно, я сделал неправильный вывод из Вашего резко негативного отношения к математическим (про округление) и логическим (про вычитание) задачам на собеседовании.
это какая-то тупая инсинуация
Инсинуация - это когда кто-то пытается представить добросовестное заблуждение (если я, действительно, неправильно Вас понял) как "перевирание" (намеренное искажение).
начал троллить собеседующего
На олимпиадах такое же. До 9-го класса на них всем пофиг, а после 9-го они дают поступление в универ. Поэтому до 9-го побеждают самородные брильянты, а в 10-м появляются куча старательно зубрящих девочек, которые не покладая рук, зубряТ олимпиадные задачки с утра до вечера.
Забавно, что все зубрилы написали про базу, а все не зубрилы с удовольствием мозг почесали.
Я сам, хоть не плаваю в вопросе приоритета операторов, но часто предпочитаю написать лишнюю скобку. И быть уверенным что все сработает так, как я задумал.
Я скобки ставлю всегда. И не потому что я боюсь, что "неправильно знаю приоритет операторов", а потому, что знаю, что через какое-то время придут честолюбивые дублёры — и вот они могут и не знать приоритета, вкорячат в середину моего выражения какое-то своё; оно вычислится по приоритетам и поставит колом всю систему, после чего вся команда будет неделю искать, а в чём, собственно, дело. Поэтому лучше я потрачу два лишних нажатия клавиш и поставлю скобки сейчас, чем кто-то (и, возможно, даже и я, если буду ещё живой) получит проблему на неделю разборок.
P.S. И это не теория — это реальная история из жизни.
"Уставы пишутся кровью. Пусть даже не всегда нашей кровью" (c)
const f = (x) => Math.floor(x + 0.5)
А вот тут коллега исполнил классический танец по граблям под названием "сложение двоичных чисел с плавающей запятой". В том случае, что при X >>> 0.5 вылезут ошибки округления при приведении порядков у обоих чисел.
~> cat test.c
#include <stdio.h>
main() {
float a = 1234567939550609408.0;
float b = 0.5;
printf("a = %f\n",a);
printf("b = %f\n",b);
printf("a+b = %f\n",(a+b));
}
~> gcc test.c
~> ./a.out
a = 1234567939550609408.000000
b = 0.500000
a+b = 1234567939550609408.000000
Я знал что узнаю много нового из своей же статьи )))
(В ужасе:) То есть Вы никогда не слышали о приведении порядков при сложении чисел с плавающей запятой??? А ну вон отсюда, джун, мануалы курить!!!
И что? Как это мешает округлению?
Как это мешает округлению
Округлению это не мешает. Это мешает правильному округлению.
(Ну, примерно как мышь слону не мешает. Но есть нюанс.)
Как это мешает правильному округлению?
То есть пример, где показано, что а + b == a (по мнению компьютера), Вы не заметили?
Я прекрасно знаю об этом обстоятельстве и в третий раз спрашиваю, как ваш пример мешает правильному округлению?
Округлению, может, и не мешает (хотя я проверять не стал — может, и мешает) — а вот прибавлению 0,5 мешает абсолютно точно.
Ещё раз: это Вы мне сейчас предлагаете найти для Вас тот (те) конкретный(е) случай(и) из числового ряда, где оно реально мешает? Я показал принципиальную возможность такого исхода.
Ещё раз: это Вы мне сейчас предлагаете найти для Вас тот (те) конкретный(е) случай(и) из числового ряда, где оно реально мешает?
Конечно.
Я показал принципиальную возможностьтакого исхода.
Не показали. Вы показали только то, что сложение не всегда увеличивает число, но этого в данном случае и не требуется.
Округлению гарантированно не мешает, потому что, если число x + 0.5 отличается от x меньше чем на точность - значит, x в представлении с плавающей точкой гарантированно уже целое:
#include <stdio.h>
int main(void) {
float a = 1234567939550609408.5;
printf("a = %f\n",a);
// prints 1234567939550609408.0
}
У @Wesha не очень убедительный пример получился, давайте я попробую:
#include <stdio.h>
#include <math.h>
float my_round(float f) {
return floorf(f + 0.5f);
}
int main() {
float counterexample = 0.4999999701976776123046875f;
printf("%f, %f\n", my_round(counterexample), roundf(counterexample));
return 0;
}
orenty7@orenty7-laptop:~/tmp$ clang -lm main.c && ./a.out
1.000000, 0.000000
Эта программа не имеет отношения к рассуждениям @Wesha
Ваша константа является более запутанным способом записи числа 0.5f. А результат округления 0.5 зависит от конвенции.
Эта программа не имеет отношения к рассуждениям @Wesha
Это иллюстрация лишь для первой части его рассуждений, про то, что сложение может вызвать проблемы.
Ваша константа является более запутанным способом записи числа 0.5f. А результат округления 0.5 зависит от конвенции.
Нет, моя константа не является способом записи числа 0.5f, вы легко можете это проверить, например, тут или запустив
#include <stdio.h>
#include <math.h>
int main() {
float a = 0.4999999701976776123046875f;
float b = 0.5f;
if(a == b) {
puts("equal");
} else {
puts("not equal");
}
return 0;
}
Я подумаю над Вашим примером.
Согласен, что обозначенная Вами проблема существует. Для мантиссы (1)1111...11111 нормализация при сложении с 0.5 преобразует её тоже в 0.5, т.е. (1)0000...00000, что в сумме даёт единицу.
Вместе с тем, эта проблема не носит принципиального характера, так как младший разряд всё равно ничего не решает. Хотя стандарт IEEE-754 и требует максимально точно его выставлять, но реальные процессоры не всегда это соблюдают.
Более того, в каких-то реализациях функции округления, возможно (а в некоторых численных алгоритмах – безусловно) округление как раз фактически и производится сложением с 0.5 и отбрасыванием дробной части.
Ваша мотивация как интервьюера отчасти понятна, хотя и не близка мне. А вот зачем соискателю не готовиться к интервью совершенно неясно
Пробуем повысить до миддла. Задаём вопрос: «А как сократить количество вызовов функции округления?»
Может я туплю, но кажется что в коде выше этой фразы и ниже количество вызовов одинаковое. Там где написано 3 функции всё равно будут вызваны только 2, по крайней мере в логике if then было бы так. Или тернарный оператор предвычисляет обе ветки?
Вы заменили алгоритмическую задачу на задачу-квиз. Которую легче выучить чем алгоритмическую и сложнее до неё дойти в процессе решения. Хотя такой способ интервью тоже есть
Меня на многих собеседованиях спрашивали вопросы из условно 3-х категорий:
алгоритмические задачи (простые) которые редко будут встречаться в жизни
квизы про язык "что выведет этот код", но такие кусочки кода которые ни за что не пройдут code review
"давайте спроектируем твиттер". Ага, вот так ваш CTO, 2 архитектора, 5 аналитиков и 10 синьёров дадут проектировать новую огромную систему новичку в одно лицо.
Ну и по фактическим ошибкам:
const f = (x) => Math.floor(x + 0.5)математически не верно, 2.5 округляется до 2.0 а не до 3.0 В комментах есть решения, которые учитывают этот фактДля скриптовых языков у меня железное правило "есть встроенная функция - используй её и ни в коем случае не делай руками". Потому что авторы языка/библиотеки мало того что подумали над алгоритмом, так ещё и некоторые оптимизации могут применить. У них преймущество x10 всегда. Опередить их можно только если они ступили
Leetcode пишется именно так. Можно же было проверить, известный сайт
На Leetcode нет задач на вращение дерева. Вообще нет. Ни одной нет.
Есть несколько на суффиксный массив, на хеши (в том числе кольцевые), на Фенвика, на Trie, на дерево отрезков. Есть пара на сортировку (надо оценить количество шагов при сортировке вставками). На "сделай мне красно-чёрное дерево, кучу, хешмапу" задач нет. Есть библиотеки с этим делом и ими можно (иногда нужно) пользоваться
математически не верно, 2.5 округляется до 2.0 а не до 3.0
Математически как определить, так и будет. Есть два подхода к этому вопросу, оба со своими плюсами и минусами.
Округление 2.5 до 2.0 базируется на представлении о бесконечно точных числах, ровно в середине отрезка которых находится значение 2.5. И тогда чётные округляются вниз, а нечётные вверх.
Но поскольку в действительности компьютерных вещественных чисел с плавающей точкой на отрезке конечное количество, причём чётное, то так рассуждая, получается, что для симметрии надо округлять всегда вверх.
А на практике это неважно, потому что есть погрешность.
Степени двойки (в том числе отрицательные) представляются точно. И получить в рассчётах точно одну вторую (поделить один на 2) - запросто.
Округлять надо так, чтобы последней цифрой не было 5.
1.45 округляется до 1.0
Но если сделать в два округления, по разрядам, то будет 1.45 -> 1.5 -> 2.0
А если математически округлять, то будет 1.45 -> 1.4 -> 1.0
Ваш довод о цепочке округления имеет смысл (хотя сама цепочка округления - не особенно хорошее решение).
Однако можно ведь рассуждать и по-другому. Например, допустим, мы хотим, чтобы в каждом числовом диапазоне [N; N+1) была равная вероятность попасть в левую и в правую половину при округлении (далее используя какой-нибудь метод Монте-Карло). Тогда 4.5 надо округлять до 5.
Всё зависит от цели округления.
const f = (x) => Math.floor(x + 0.5)математически не верно, 2.5 округляется до 2.0 а не до 3.0 В комментах есть решения, которые учитывают этот факт
Открываем консоль браузера (F12, если не знаете), вводим:
> Math.round(2.5)
3
> (x) => Math.floor(x + 0.5)
> f(2.5)
3
ЧЯНТД?
статья вызвает диссонанс в разрезе двойных стандартов..
Если соискатель написал задачу за 5 минут правильно и оптимально, не переписывая в процессе несколько раз код, то... Никакой информации интервьюер не получит. Точнее придётся выбирать между версией, что на интервью бриллиант от программирования. И версией, что человек просто неплохо подготовился, а, возможно, вызубрил задачу наизусть.
почему это по тексту выглядит как "плохо" для других, а для тебя хорошо ?!
Огонь! Соискатель знает что такое округление, понимает как получить дробную часть. Если не знает, я не против рассказать. Даже интереснее будет.
в итоге ЧСВ победило, а как же заставить интервьюируемого думать ?!
Считаем, что миддл детектед. Опять же не точно, и нам бы, в идеале, нужен сеньор, хотя бы потенциальный.
А обычный сеньор, который оказывается звездой на letitcode вызывает вопросы.
снова, здорова, выглядит противоречиво.. может для сеньора нужна проверка знаний совсем не про алгоритмы ?!
Нужно написать функцию (f) округления положительных чисел к ближайшему целому, используя только Math.floor.
Боже какая дичь! Автор, что вы хотите этой задачей проверить? Какие навыки?
Эта задача не проверяет кодинг скилы, она не проверяет навыки программирования, знания или применения библиотек и фреймворков.
Это вообще не алгозадача от слова никак.
Про представление чисел с плавающей точкой уже сказали, там все не так просто.
Мне кажется таких интервьюверов, а заодно и непоредственного руководителя, надо просто уволить одним днем.
В команию могут попасть абсолютные неадекваты, а адекваты просто развернутся и уйдут. Что еще хуже, для индустрии задаете в корне неверные стандарты.
сли честно, в реальной жизни умение решать "алгоритмические задачи" не то чтобы не понадобится, но за 30-летнюю "карьеру", у меня было только одно место работы, где чаще, чем раз в месяц приходилось решать задачи близкие к алгоритмическим.
Конечно не было, если вы задаете такие вопросы на собесе, то какой вменяемый руководитель допустит вас до серьезных вещей.
У меня неоднозначные впечатления от алгозадач литкода, но как правило, разработчики с опытом справляются с ними хорошо и это просто входной фильтр и не более того. Но таким инструментом тоже надо уметь пользоваться.
При всем уважении к статье автора, если на техсобесе меня будут просить решать только и исключительно такие задачи на "проверку смекалочки", никакой собес компания не пройдет, а интервьюера я отдельно запомню
Потому что высока вероятность, что после найма я обнаружу новых коллег, которые умеют вычитать из семерочки двоечку и менять местами значения в двух переменных без третьего контейнера
Это не алгособес, это не тестирование computer science и не отсев выпускников курсов. Это чек на общий ПТСР от количества костылей на прошлой работе и умение их городить, простите
Потому что выпускники джавакурсиков очень часто знают как округлять чиселки местами в инвертированных черно-класных B-деревьях, их этому научили. Их не научили что в synchronized надо передавать не любой объект до которого автоподсказка идеи дотянется и не показали что будет если случится хеш-коллизия у двух объектов на хайлоад проде
Чекнуть "компилятор в голове" на собесе - тема-то хорошая, но проверяйте пожалуйста хоть что-то похожее на настоящую работу после найма
Если приложение - джейсономешалка - мапы, флатмапы и прочие монадические выверты над объектом алгебры данных. Если числомолотилка - умение числомолотить
А "набор уловок старого лиса-синьора" не проверяйте. В проде эти навыки скорее вредны чем полезны, а потерять хорошего разраба которые спросит "чоблин, в смысле напиши округление при помощи конкатенации строк, зачем?", вежливо закончит собес и никогда к вам не наймется
7-х, конечно, короче записывается, но точно ли это оптимальное решение?
С точки зрения программирования как профессиональной деятельности (а не как искусства), оптимальный код:
выдаёт правильный ответ для все возможных входных данных
легко пишется
легко читается
легко модифицируется
использует разумное количество ресурсов
Теперь давай сравним
7-xи
switch (x) {
case 2: 5
case 5: 2
}По пунктам:
одинаково
switch натурально пишется переложением ТЗ, 7-x - неочевидное решение
смотря на код switch можно сразу понять исходную задачу, 7-х не говорит ничего о входных данных
если надо добавить обработку ошибок или расширить область действия функции, switch явно выигрывает
Надо мерить! На этот вопрос чёткий ответ дадут только бенчмарки.
Короче, говно твои задачи, из разряда сколько шариков от пингпонга в боинг влезет.
По пятому вопросу вы кривите душой. Ясно, что арифметическая операция будет на современных процессорах намного быстрее, чем ветвление. Другое дело, насколько нам это нужно, и какое вообще отношение имеет к JavaScript.
можно сколько угодно теоретизировать. Бенчмарки решают. Вы можете сколько угодно фантазировать, что быстрее на современных процессорах, и забыть про branch predictor, параллельное выполнение двух веток и тд
ну и допустим, 7-х потребляет в 100 раз меньше ресурсов, чем switch - это не значит, что надо срочно бежать оптимизировать. Оптимизация нужна в узких местах, и первое что нужно сделать - убедится в необходимости оптимизации, потом заняться профилированием и найти места, где оптимизация принесёт значимые результаты.
По моему мнению, главное на интервью - это понять как человек думает и как решает проблемы.
А мне надо получить работу чтобы было что кушать. Поэтому я приду на собеседование максимально подготовленным.
И вообще, это оплошность интервьюера, если он даёт задачи, которые ничего не показывают. А по показанной задаче — я надеюсь, вы её максимум стажёрам даёте.
Резонансная статья поднимает уйму системных проблем найма в ИТ компании:
Какие-то проблемы с самооценкой лидов при найме новых сотрудников (оценка уровней на глазок относительно лида, токсичность, хамство и прочие артефакты присущие в большей степени российской ИТ отрасли - в зарубежных компаниях существует код взаимодействия, что создает комфортные условия работы и даже трудоустройства - хотя тоже встречались нюансы)
Отсутствие единых стандартов квалификации в отрасли (все эти грейды мидла сеньера высосанные из пальца и минимальные знания, которыми должен облатать по мнению очередного доморощенного специалиста - сплошная субьективщина)
Некорректное сравнение технических навыков (кто сильнее кит или слон, пути соискателей - один из веб, а другой из военки и чего их опыт сравнивать)
Отсутствие в целом развития индивидуального пути отрасли (здесь меня больше беспокоит калька стеков вакансий вроде Python+Django, Golang+Gin, Java+Spring, C#+MSSQL и так далее). Если например компания заявляет, что они специалисты в отрасли хранения данных, то ну какого черта там делает PostgreSQL внезапно. Пишите свое решение.
Вообще поднимаете отличный вопрос и это вопрос не только к ИТ отрасли, а скорее вопрос управления и мотивации: каким образом строить ИТ компании и как управлять людьми, а что еще более важно как сотрудники должны отвечать на вопросы "Что такое уважение?", "Кого считать профессионалом такого-то уровня?", "Как сравнивать и отображать опыт одной отрасли на другую?", "Как в целом построить индустрию в стране где 30 лет идет подражание зарубежным технологиям?".
Я думаю, что эти все вопросы может прояснить арбитр - Минцифры. Потому как сейчас будет просто очередной спор и кого-то унесет в технические вопросы, а кто-то начнет рассуждать про экономическую выгодность и прочее.
Не понимаю негатива к алгоритмом и задачам. Я тоже этого не понимал пока не стал их регулярно решать, бывают очень полезные. Я их рассматриваю как тренировку ума, примерно как хождение на тренировку. Если ты программист, то должен поддерживать себя в хорошей форме. Я это понял когда недавно не смог на собесе решить простую задачу. Навык программирования поддаётся тренировке и если ничего не делать, то этот навык атрофируется. Но спрашивать сложные задачи на собеседовании считаю бредом. Многие упоминают про вращения дерева, я тоже это делал, но сходу низачто не сделаю. Время выделять на решение задач считаю необходимым, иначе кроме как красить кнопки ничего делать не сможете. Мне доставляет большое удовольствие найти красивое и оптимальное решение, эстетика в этом определённая есть. И если не решать сложные задачи, то зачем вообще в программисты идти? Алгоритмы это безусловно сложно и интересно.
Я их рассматриваю как тренировку ума, примерно как хождение на тренировку.
Поддерживаю.
Я тоже этого не понимал пока не стал их регулярно решать, бывают очень полезные.
Могу привести пример из другой области (хотя, конечно, аналогия не может служить доказательством).
Связь между бегом (спринтом) и жимом лёжа или становой тягой не очевидна. Тем не менее, она есть. А было время, когда считалось, что спринтер должен быть худым, чтобы бежать быстрее.
Если приносит удовольствие, то почему бы и нет. Я в основном говорил про "набитость для собесов". Я вот имея смешной рейтинг в шахматы, люблю решать задачи. Если меня возьму на должность мастера спорта на основании решения композиций, то очень сильно удивятся, когда я выйду на работу ) Да я ещё дофига могу рассказать по английскому началу, сицилийским дракону и найдорфу и гамбите чарлика, ибо только в эти дебюты и играю или к ним свожу. Что не сильно меня поднимает в мастерстве, просто позволяет на проиграть до 15го хода (но не всегда).
Если человек решил 4 задачи вместо запланированных двух, то мне придется ещё потратить час, чтобы погонять его по предметке. Ибо см. ыше
Я честно не могу понять что вы понимаете под набитостью. Алгоритмов очень много и заучить все очень сложно. Если кто-то действительно смог, то честь и хвала, по крайней мере память феноменальная. Я так не могу, даже быструю сортировку с листа не могу написать, а кто-то легко. Ну а если дают лёгкие задачи и те что встречаются везде то удивляться не стоит что их могут быстро решить. На недавнем собесе мне как раз "повезло". Попалась задача которую я до этого решал на литкоде и ответ знал заранее. На литкоде она помечена как сложная, хотя я бы её отнёс к средней. Считаете что компания которая меня наняла просчиталась? А вообще любой собес не может дать точный ответ подходит ли человек или нет. Для этого есть испытательный срок.
Попалась задача которую я до этого решал на литкоде и ответ знал заранее.
Поэтому и чтобы минимизировать другие источники шума, в ФААНГах, которые для совоих нужд эти интервью и спроектировали, дается сразу несколько секций алгоритмических интерьвю. Шанс того, что кандидату попадутся 4 из 4 задачек, которые он видел раньше, весьма малы. Особенно, если учесть что утекшие задачи интервьюверам запрещают использовать.
Если человек решил овер тыщу задач на литкоде, то шанс пройти собес у него сильно повышается по сравнению с тем кто решил 10, в том числе и за счёт того что какие-то ответы он будет знать заранее. Считаете это читерством? Яндекс сам рекомендует потренироваться месяц, два. Но лично по мне, месяц, два - мало. Нужно хотябы год регулярно решать, чтобы минимум 300 - 400 задачь было. Иначе шанс небольшой. Может конечно я такой тугодум и мне нужно именно натаскиваться, а другие от рождения способны решать без подготовки. Но что-то мне подсказывает, что это не так.
А еще если он выучит алгоритмы, то шанс у него повысится, потому что "какие-то ответы он будет знать заранее".
Запомнить решения 1000 задач с литкода невозможно. Есть минимальный шанс, что вот именно ту похожую задачку кандидат вспомнит, но в подавляющем большинстве случеев это не кандидат "знает ответ заранее", а кандидат приобрел навык решеня задач, выучил несколько алгоритмов и приобрел понимание когда, где и как их применять. Ровно то, что нужно любому человеку для прохождения такого интервью.
Ну, или перед вами человек дождя, и такой уникум будет весьма полезен в работе. Ему можно скармливать целые книги документации и он будет моментально вспомнать на какой странице про что-то нужное написано. Он будет сразу помнить про всю архитектуру любого проекта и не будет допускать самый частый вид багов: при реализации чего-то в одном углу проекта забыли о предположении в другом углу.
Я так не могу, даже быструю сортировку с листа не могу написать, а кто-то легко.
Собеседование - не экзамен. Могут взять того, кто не решил задачу. Могут не взять того, кто решил.
А если человек волнуется и теряется на собесах по физиологическим причинам, то ход его мыслей может оказаться сложно узнать. И я считаю это то, почему некоторым лайфкодинг не подойдёт, а другие кто мог бы, просто могут не хотеть.
"Math.floor() только один раз и без переменных"
а аргумент анонимной функции считаем за переменную?
const f = (x) => (floor => x - floor >= 0.5 ? floor + 1 : floor)(Math.floor(x))Мне это требование про временную переменную вообще показался странным. x + 0.5 и есть временная переменая, пусть и без имени. И функции стрелки это что-то. Вэб кидди одним словом.
Это притянутое за уши, зато вполне понятное условие. Запрет использования блоковой структуры () => {...; return ...}, ради которого бы всё делалось, мне показалось сложнее понятно написать.
Да и сам запрет искусственный, чтобы сократить объем примеров однострочниками, если бы я давал задачу на реальном собеседовании, я бы не требовал, ни стрелку, ни запрет блоков.
Вот такое решение даже для сеньора, меня бы удовлетворило. Поскольку это абсолютно корректное и рабочее решение. Как я писал в статье, меня больше интересует реакция на хак. Чем насколько быстро человек до него добрался. Умение же сделать быстро и добротно более важно, знания "это же базы". (ЗЫ я не пишу {} там где можно не писать, если нет соглашения об отказе от них. Но с {} после if'ов тоже решение было бы годным. )
const f = (x) => {
if (x < 0) throw new Error('А обещали, что отрицательных чисел не будет');
const base = Math.floor(x);
if (x - base > 0.5) return base + 1;
return base;
}
Ну так в том то и дело что многое в Вашей статье притянуто за уши. Если честно, то если бы мне такое попалось на собесе, то я бы скорее всего не пошёл бы в такое место. Подумал бы что какие-то упырки там работают. Мне и на алго собесах тоже попадались упырки, которые закидывали сильно сложные задачи и потом тешили самолюбие, какой мол кандидат тупой не может задачку за пол часа решить. Но они не понимают что кандидат эти задачи может найти и сложить о них не лучшее мнение. Ничего личного, просто повод Вам подумать.
Вы второй. Я не упоминал замыкания, так как не хотел перегружать статью спецификой (стрелка в JS, имхо, интуитивно понятная история даже для программиста на КОБОЛ). Но ждал в комментах большей активности, от тру-джиэсников в этом направлении)
Почему я не готовлюсь к алгоритмическому интервью