Comments 20
Map count = new HashMap<>();
А почему нет дженериков?
Два цикла
В одном так for (char c : s.toCharArray()) {}
В другом так for (int i = 0; i < s.length(); i++) {}
Один метод разные подходы?
Если брать фронтенд (только за него могу говорить) - за 10 лет работы из которых 5 java и 5 kotlin (в том числе в бигтехе, где в собеседованиях обязательная алгоритмическая секция) - задачи которые требовали бы алгоритмы сложнее "ультра легко" попадались 2 раза (и заняли - ну день).
В первом случае алгоритм был нагулен, во втором придуман посидев пару часов с листом бумаги.
Ради веселья и в качестве "игры" - не вижу ничего плохого. Но про практическое применение - мне кажется это способ убедить себя, что развлечение на самом деле не ради веселья - а обучает.
Если человек может оценить сложность алгоритма и не упороться в квадратичную, на очевидно линейной задаче - как будто дальше польза сходит на нет.
Плюс в коде все эти алгоритмические решения обычно ужасно плохо читаются - и если данных гарантированно мало - лучше самый простой код, а если гарантированно много - лучше поискать решение от человека который специализируется именно на алгоритмах а не изобретать велосипед.
Но реальность такова: если вы хотите расти — алгоритмы знать нужно или хотя бы желательно.
Так всё-таки "нужно" или "желательно"?
Они в действительности помогают мыслить как инженер: структурировать задачи, оценивать сложность, писать оптимальный код, ну и шаблонно мыслить
"Мыслить как инженер" помогают не столько алгоритмы, сколько здравый смысл и опыт в разработке. "Оптимальный код" = сферический конь в вакууме. Сегодня оптимальный, завтра нет...
Знать базовые коллекции и сложность операций с ними полезно. Алгоритмические задачки помогают это закрепить.
Полезно-то полезно, а неполезно (вредно) становится, когда тебя на собесах заставляют красно-черные деревья в голове рекурсивно крутить...
Красно чёрные деревья это далеко не базовая коллекция. Там более десяти вариантов, как крутить надо, собеса не хватит раскрутить.
Встречал много персонажей, верящих в обратное. Легко представляю, как они начитались таких статей о "важности алгоритмов", и решили потом эти алгоритмы вворачивать к месту и не к месту, в том числе на собесах.
Ну пускай дерево будет не красно-черноё, а обычное бинарное. Вы легко напишете код по удалению произвольного узла из него?
И в качестве бонуса, можете попробовать вспомнить где подобные знания пригождались вам в жизни, в "боевых условиях"?
Nuff said.
Что надо на практике:
уметь оценить сложность кода по времени и по памяти
знать стандартный инструментарий, знать какие там сложности по времени и памяти у основных структур данных и алгоритмов
знать про сторонние оптимизированные либы типа fast-utils
видеть по метрикам, где у тебя затыки по CPU и RAM
уметь пользоваться профайлером
уметь в тесты и рефакторинг
Что надо на собесе:
обливаясь пОтом за 15 минут понять мудацкое описание задачи и родить O(1) решение
если вдруг посмеешь родить не O(1), а O(n) или не дай б-г O(nlogn), то выслушать едкий комментарий
Так что нет. Алгосики на собесах это исключительно про алгосики на собесах. Никто меня не убедит в обратном.
Из хороших тактик, решить самому, посмотреть десяток решений, выбрать лучший подход и написать его по памяти самому. Даже в простой задаче может быть несколько вариантов хороших решений.
Довольно забавно выглядит, когда крутотехи гоняют на собесах по алгоритмам и system design, а потом их разработчики пишут на хабре статью о том, как они собрали велосипед из известной субстанции и палок и с треугольными колёсами. Причём палки так и не подвезли.
UGC-площадки, не запрещающие генерённое нейросетями УГ и не борющиеся с их наплывом, обречены на уничтожение. Уважаемой администрации пора бы уже вынуть голову из песка.
Литкод собесы изначально задумывались как способ индусам отшивать американских инженеров, чтобы типа законно выдавать H1B своим собратьям. У которых ни знаний ни опыта, но зато куча свободного времени прорешать надуманные задачки.
Ну а дальше все ломанулись бездумно копировать эту дичь. Как результат - выше метко подмечено: такие "специалисты" могут только велосипед из говна и палок соорудить.
StringBuilder вместо сложения строк
Orly? Как он делает код короче?
Deque как стек или очередь с обеих сторон
А старый добрый LinkedList чем плох?
Чтобы расти в профессии, нужно решать прикладные задачи, от алгоритмических польза примерно как от игры в шахматы. А на собеседованиях какого-нибудь синьора просить алгоритмы решать - такое. Я, лично, задачку давал, только если много лишнего времени, и то, чтобы послушать рассуждения, а не получить конкретное решение
В начале статьи написано "Обязательно или хотя бы желательно". Это же противоречие
Как Java-разработчику эффективно решать алгоритмические задачи