Программисты решают задачи по-разному!

[@denis_lopatkin]

Задачу можно решить за O(n) по времени и O(1) по дополнительной памяти используя только две строковых переменных - текущее формируемое слово и слово максимальной длины, встреченное ранее.

[@Splish_Splash]

Если предложение состоит и одного слова то худший случай все таки O(n) по памяти

[@АлексейКутасов-п7и]

зачем строковые переменные - позиции начала и конца текущего ответа, а так же позиции начала и конца текущего слова. А потом вернуть какой нибудь slice, либо дефолтное значение, если позиции начала и конца ответа невалидны. иначе непонятно, как с O(1) памяти хранить текущее слово что то типа def is_letter(ch: chr) -> bool: return ch.isalpha() def longest_even(text: str) -> str: lans = -1 rans = -1 lcur = 0 for rcur in range(len(text)): if not is_letter(text[rcur]): lcur = rcur + 1 elif rcur - lcur > rans - lans and (rcur + 1 - lcur) % 2 == 0: lans = lcur rans = rcur + 1 default = "00" return default if lans == rans else text[lans:rans:1] (не пишу на питоне, так что не судите строго)

[@АлексейКутасов-п7и]

​@@Splish_Splash O(1) по дополнительной памяти, те количество памяти минус то, которое потребуется под ответ

[@denis_lopatkin]

Ну да, с указателями даже лучше

[@ARMENIA181]

There are different approaches to programming. One way is to write simple solutions, which might lead to encountering bugs. Another is to attempt covering all possible edge cases, which can result in never completing the task. I believe the best approach is to initially avoid writing code. Instead, start by writing a test. This test should simply and effectively cover the requirements. Then, proceed step by step: write one small test and follow it up with the corresponding code.

[@evgenasd8892]

А можно в тесте реализацию внутреннего устройства выполнить в сложном стиле а можно прямолинейно но без возможности масштабирования . Так что придется переписывать все заново, либо можно усложнить, тогда времени потребуется больше. А можно не уложиться по времени и начать делать космолет. Так как же найти золотую середину??

[@linatroshka]

На интервью лучше то решение, которое удовлетворяет ожиданиям интервьюера)

[@den-rad]

Я за решение конкретной задачи, если нет дополнительных указаний. Любую задачу можно усложнить, когда будет нужно. Программисты часто любят делать универсальные решения, они выглядят красивее, но никто не знает будущих потребностей бизнеса.

[@YuriyIva]

согласен. Валидацию можно добавить как отдельной функцией перед вызовом функции, которая выполняет задачу. Или произвести после. SOLID.

[@СтависВега]

Как поставлена задача, так и решаешь. Если заказчику нужны особые условия он их прописывает в ТЗ.

[@const8576]

По идее в решение на python не сложно добавить фильтр на символы - всего одна лишняя итерация и всё равно будет O(n), что быстрее варианта с сортировкой. Проблему со значением по умолчанию тоже в принципе не сложно обойти - способов много. На собесе в таких случаях обычно наверное всё же алгоритмику проверяют, поэтому чем быстрее, тем лучше. С другой стороны, если что-то такое писать в проде, то зависит - если нужна скорость, надо делать оптимально как на python. Не нужна - тогда наверное предпочтительнее вариант на JS, т.к. он понятнее, читаемее и меньше времени требует на написание. Тем более что сортировка всего лишь n log(n) - не сильно медленно. Вот если бы там какой-нибудь n^2 был бы, тогда стоило бы заморочиться. Ваш кэп

[@alexander.shakhov]

по логике, кажется, что нужно решать так, чтоб асимптотика была лучшей: O(n) против твоего решения O(nlogn). Однако лучше предоставить это выбор интервьюеру. Предложить все возможные варианты, подсветить нюансы и эдж кейсы, задать ему вопрос, мол можно так и вот так решить, как хотите чтоб я это решил? Я думаю ему важно как ты думаешь, отсюда и вывод, что ты готов предложить несколько вариантов, еще и проблемы подсветил какие ты увидел. А далее, напишешь код уже обговорив все за и против. Важно спрашивать, чтоб не тратить время на написание кода, так как если выясниться, что от тебя требовалось другое, то придется переписывать, а время ограничено. Вот как-то так

[@EgorFrade]

быстрее O(n) не получится

[@Splish_Splash]

@@EgorFrade имеется ввиду что решение с сортировкой nlogn

[@alexander.shakhov]

не получиться, все верно. Поэтому и пишу, что асимптотика должна быть лучшЕЙ, а не лучшЕ@@EgorFrade

[@EgorFrade]

@@alexander.shakhov понял

[@Pavlovnik92]

Если бы я увидел в работе твое решение, я бы был за него, а на интервью(алгоритмическом) конечно примут решение из видео-примера. Это как было задание: Разверните строку и ты можешь написать (код swift) "некая строка".reverse(), но дальше интервьер говорит - а теперь представь что у нас нету этой функции и есть только циклы и счетчики))) и начинается. Все же прохождение собеседований это отдельный кейс решение неких типовых задач, который редко потом в работе применяем

[@Dimonina]

если это для интервью, то конечно интервьювер хочет увидет O(n). Для реальных проектов, если вы не занимаетесь парсингом какого-то гигантского объема текстов, то лучше будет решение, которое легко читается. Собственно тут подход такой - в реальной жизни пишем умеренно, чтобы люди после тебя потратили минимум времени на понимание твоего кода (так как разраб в течение дня больше читает код, а не пишет, а это деньги бизнеса), на интервью - для хорошей оценки от интервьювера :)

[@xjaxjax]

у меня всегда решение уменьшается в процессе раздумья)) Что-то сделал, потом уже отложил и делаешь что-то другое, потом вечером приходит идея что можно сделать быстрей и проще, переделываешь. А на интервью - как повезет))))

[@0xreset]

Когда я только увидел задачу, уже в голове нарисовал красивое решение используя bucket sort. Потом когда увидел как решили задачу в этом шортсе, понял насколько сильно я люблю все усложнять)

[@SiriusBlackNuar]

А что по этому поводу думает ChatGPT?

[@Poloskun4ik]

Ну лично я бы в начале уточнил контекст задачи. Так как способность уточнять сложность проекта еще на старте это очень важный навык. Сказал бы прямо- есть 2 решения: простое быстрое и универсальное, но сложное. Ну либо определил ожидание экзаменатора по реакции на предыдущее задание. Сам считаю, что для простых проектов нужны простые решения. Не нужно закладывать базу под масштабирование и универсальность, это можно сделать позже, если будет такой запрос.

[@ДжедПрайс]

На интервью лучше дать решение, чтобы пройти интервью - очевидно же :) На проде да - много есть тонкостей разных и ограничений, их лучше учитывать, чем не учитывать, но на интервью меньше времени на это, скорее всего задачка была не про правильность "от и до", а про умение мыслить и решить задачку (основную её часть). Но - если удалось быстро учесть больше тонкостей это однозначно будет плюсом.

[@arahnid_9844]

На интервью, лучше сделать решение максимально близкое к поставленой задаче. И в зависимости от того как она поставлена, лучше делать или быстрое, или что б все пограничнве случаи учитывало)

[@SashaKuzikov]

Какое-то время думал над ситуацией. Лично мне самому никогда в жизни не приходилось быть на собеседованиях, кроме случаев, когда приходили ко мне. Но несколько разборов и собеседований видео на KZbin. Подобные задания практически никогда не подразумевают решений "в лоб". Да и сложность алгоритмов решения имеет огромное значение. Поэтому использование сортировок и регулярных выражений практически всегда остаются проигрышным вариантом.

[@ИльнурДавлетбаев]

В программировании есть довольно известный принцип - KIS - keep it simple stupid (на русском чаще звучит как "делайте вещи проще"). Ответ на вопрос?

[@indarelloivanov2180]

на python решение которые применяется на сайтах с задачами типо leetcode, решение на javascript это то как задачи решаются в реальных проектах

[@chilibean6152]

Вот таких видео не хватает

[@arzievsultan]

Решение, которое читабельное, то есть композиция из функций.

[@vitaliiivanov9514]

На интервью нужно решить задачу на данном в условии множестве входных значений. Если оно определено нечётко, уточнить у интервьюера.

[@RomanCoxy]

Я думаю на интервью лучше предложить оба варианта)

[@t1m1yepp]

два видео за день, сильно

[@larchanka]

Это короткое, вдруг появилось желание его снять, поэтому я быстро сделал )

[@NickBardier]

А если вот такую регулярку применить replace(/[^а-яА-Яa-zA-Z]/g, '') ?

[@NickBardier]

Даже еще проще replace(/[^а-яa-z]/ig, '')

[@DreamingDolphing]

@@NickBardier Так кроме русского и английского, на свете есть много других языков.

[@johannschmidt8261]

Наверное сильно зависит от постановки задачи. Я бы придерживался KISS-Prinzipа и не делал бы того чего от меня не требовалось делать.

[@Splish_Splash]

Можно сделать питоновское решение также O(n) и учесть все что сказано в ролике(возможно даже лучше так как только алфавит остается), единтсвенное "слово-слово" превращается в "словослово" что скорее всего не ок longest = '' default = '00' for word in text.split(): filtered = ''.join(filter(str.isalpha, word)) if not len(filtered) % 2 and len(filtered) > len(longest): longest = filtered print(longest if longest else default)

[@Lelouch-]

Если учесть привет-привет как разные слова и цифры в конце слов допустим дом2 не учитывать то вот решение: def find_longest(text: str): result = '' stack = '' for char in text: if char.isalpha(): stack += char elif len(stack) % 2 == 0 and len(stack) > len(result): result = stack stack = '' else: stack = '' return result if result else '00' print( find_longest('i am longest word in the text with number1') )

[@Splish_Splash]

@@Lelouch- отлично, только крайний случай "one two we loooooooooooongest" не учтен ;)

[@Splish_Splash]

@@Lelouch- достаточно в конце ретерн изменить на самом деле, но показательно :)

[@igorchesnokov482]

Мне кажется, от условий задачи должно зависеть. Вот предположим, что ввод предложений будет не ручной, а программный, от какого-то другого сервиса, который гарантирует отсутствие endg-кейсов. А Вы добавили проверку, которая в данном случае не нужна и замедляет программу. Я думаю, что надо решать конкретную проблему, а не эфемерную...И код проще и его дальнейшее совершенствование может пойти по неожиданному пути...

[@MrBurikella]

А с каких пор trim убирает двойные пробелы? Он же только с начала / конца строки обрезает пробелы. P.S. А на интервью лучше спросить у интервьювера что важнее в задаче: умение выяснить дополнительные требования тоже ценно

[@zlobolet]

что вернуть из строки "a b c d 00 11 aa" ?

[@bjornaven5942]

Признаюсь честно Миш это первый мой лайк твоему видео, не смотря на то что я смотрю тебя уже года 2 мне лень ставить лайки, но тут такой подробный разбор, я в восторге 🎉

[@HEX_CAT]

❤❤❤🎉🎉🎉

[@thepantelemon]

Я не знаю как питоновский сплит работает, создает ли он массив или возвращает итератор и парсит каждый раз когда я прошу следущее слово, если так то питоновское решение намного лучше. js может при каждом вызове прогонять всю строку и создавать массив распарсенных слов и передавать этот массив дальше, почему это плохо? представь что ты делаешь это на сервере с 100 мб оперативки, а строки мегабайт по 30 хотя бы.. и сортировка тоже увеличивает сложность.скорей всего в js используется quick sort алгоритм, сложность которого worst case квадратичная... т.е. ты из задачи с линейной сложностью сделал квадратичную, поздравляю :) Опять же если всё это понимать и для маленьких строк может и так сойдёт.. но не на интервью точно.

[@ВладиславКресак-б3ъ]

Ну если читаешь код, то лучше бы все было написано как 1 варинт, представьте себе 3к строк в стиле варианта на питоне

[@mikemerinoff]

Кажется, если решать как задачу, просятся указатели

[@iSonsaku]

Всегда нужно учитывать нюансы которые могут возникнуть позже. Хотя для этого есть тестировщики, можно на них всё сбросить. Пускай мучаются

[@Blackbearded]

Вы же понимаете, что после "мучений" тестеров будут мучаться разработчики?)

[@iSonsaku]

@@Blackbeardedда понимаю. Тут смысл в том чтобы делать не на отЪябись , а нормально. Большинство прочитают комментарий и увидят себя в нём, следовательно начнут огрызаться или доказывать

[@Blackbearded]

@@iSonsaku я тот самый тестер, который мучился с подобным на старте работы в айти. И по опыту могу сказать, что людей, которых вы описали, исправляет обычно снятие с проекта/увольнение из компании. Хоть и бывают случаи, когда не меняется ничего)

[@romandeveloper7720]

а yagni пофиг?

[@serdotsenko]

на интервью нужно дать то решение, которое от тебя жду 🤓 показывать на интервью что ты умнее чем человек который тебя интервьюирует, не нужно! это как пилить сук на котором сидишь. это конечно если цель - пройти собеседование и устроится на работу если такой цели нет и собесы это просто тренажёрный зал для ума, то конечно нужно показать весь свой интелектуальный потенциал во всей его красе 😎

[@woodzimierz9621]

Как понять, умнее ли ты интервьюера, чтобы случайно не обидить его красотой решения? Учесть наличие не буквенных символов - это правильный ход и его отстутствие может как раз сыграть негативную роль на интервью.

[@you-are-not-allowed]

Так задача же явно на сложность алгоритма, так что ваше решение хуже

[@DreamingDolphing]

Так он решал для бизнес-кейса. Но если это будет случай, где тысячи предложений, то будут проблемы с производительностью и вот тогда надо будет делать специальный алгоритм.

[@ilmerainen478]

сложность алгоритма в обоих случаях O(n)

[@you-are-not-allowed]

@@DreamingDolphing такие задачки чаще всего на знание алгоритмов, а не на решение бизнес-задач. В литкоде (для примера) по-вашему есть реальные бизнес-задачи?

[@you-are-not-allowed]

@@ilmerainen478 нет

[@NyanCoder]

А разве регексп не было бы выгоднее написать `[^\w ]+`?

[@twogog8981]

Регулярку можно прямо в сплите писать sentence.split(/\s|,|\.|!|\?/)

[@klklj8254]

Автор написал говнокод и оправдывается

[@zemamba]

let findEvenWord = (sentence = '') => sentence .replace(/(\.|,|-|_|:)/ig,'') .trim() .split(' ') .filter(e => e.length % 2 === 0) .sort((a, b) => a.length > b.length ? -1 : 1)?.[0] || '00'; findEvenWord('Hello, my man, How are you - doingddddd.,')