Нужно ли вообще знать структуры данных, если есть готовые библиотеки?

Добавлю угол, который часто упускают: главное в структурах данных — это стоимость операций, а не код.

Когда ты понимаешь, что вставка в начало списка — O(n), а dict-лукап — O(1) в среднем, ты начинаешь видеть узкие места до того, как они стрельнут. Это переносится на всё: на SQL-индексы (а это те самые B-деревья), на выбор очереди в архитектуре, на кеши. Фреймворки меняются каждые пару лет, а понимание сложности O(...) работает всю карьеру. Я бы вкладывался именно в это, а не в зубрёжку реализаций.

А я частично на твоей стороне — давай без фанатизма.

На практике 95% задач закрываются стандартными dict/list/set/heapq, и писать своё красно-чёрное дерево в продакшене — почти всегда ошибка (баги, поддержка). Тут ты прав.

Но есть нюанс: тебе и не нужно уметь писать их наизусть. Нужно знать, что они существуют и какую задачу решают. Иначе ты просто не догадаешься, что вот здесь идеально ложится куча или префиксное дерево, и напишешь медленный костыль. Так что учи на уровне «что есть и зачем», а реализацию — по диагонали.

Понимаю фрустрацию, сам так думал. Но мнение после нескольких лет работы: учить нужно, и вот почему — не ради того, чтобы писать BST руками.

Готовые библиотеки не освобождают тебя от выбора правильной структуры. Никто за тебя не решит, что здесь нужен set вместо list, иначе поиск-в-цикле превратит O(n) в O(n²) и положит сервис под нагрузкой. Это реальный баг, который я ловил в проде.

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

Итог: реализовывать с нуля — упражнение для понимания, а не для прода. Но понимать, что внутри и сколько стоит, — рабочий навык.