Потому что кто-то там давно это придумал, а другие ничего умнее придумать не смогли, вот и повторяют. Ещё и оправдания разные придумали… Ко всем этим собесам можно подготовиться, даже обезьяну можно подготовить, вот только про реальную работу это ничего не скажет.

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

Во-первых, к секции алгоритмов кандидат готовится, демонстрируя возможность в короткие сроки «загрузить в оперативную память» какой-то объем знаний. Во-вторых, важно увидеть как кандидат ведет себя в реальных условиях, столкнувшись с не знакомой задачей.

Секция алгоритмов, для разработчика, по прежнему является эффективным инструментом продемонстрировать свои навыки.

Привет! Спасибо за вопрос!

Я не разработчик, но постараюсь ответить. Ведь в бизнес-аналитике тоже спрашиваем теорвер, и матстат. Может показаться что это оторванная от задач бесполезная возня)

Глобально я вижу два типа задач: 1. Создавать продукт из имеющихся технологий, фреймворков, набора готовых библиотек. В принципе повторить что-то известное.

Собрать для заказчика интернет-магазин в вебэ. дорожка сто раз протоптана, нет какого-то рокетсаенса.

2. В финтехе многие проблемы нужно решать самостоятельно, с нуля своей командой. Из этого вытекает необходимость придумывать оптимальные алгоритмы, собирать инфраструктуру под уникальную задачу. Креатив, аналитический склад ума и умение ПРИДУМЫВАТЬ решение — ключевое для успеха. У нас минимум задач по типу «собрать из известного» по готовому фреймворку.

Плюс на наших объемах цена ошибки и неэффективности слишком дорога. Известные решения могут уже не вывозить. Яркий пример— разработка корпоративного мессенджера TiMe. Ребята взяли опенсоурс и под капотом переписали кучу core сервисов. На старте загрузка контента была криво сделана, все жестко лагало. Под объема наших сотрудников решение работало плохо.

Резюме. Без умения решать «неизвестные проблемы» создавать новые продукты и технологии невозможно. Вот и пытаемся проверить умение думать, а не просто знание и умение как писать код.