Как-то проходил собес на котором молодая девочка спросила про алгоритм который применялся в функции datasets.map. Там выполнялось две строки кода в Pandas. Строки было две потому что выполнялось два разных действие и использовался DE подход и бережное отношение к данным. К тому же это повышало читаемость кода и снижало когнитивную нагрузку. Принцип гласит: В процессе трансформации данных каждое атомарное действие выполняется отдельно, это позволяет повысить возможности отладки конвейера, снизить затраты на его поддержку, повысить читаемость кода и снизить когнитивную нагрузку.

Ну програмиировать все же нужно уметь. Даже фронтендеру.

Вот как будто бы и хотелось мне, как бэку, чтоб коллеги (та и я сама) почаще думали об алгоритмической сложности написанного, особенно когда нагрузка в перспективе вырастает, но выяснить это вполне легко и не с помощью задачек м литкода. Я люблю обсуждения проблем, задач, или кусков кода на собеседовании и накидывание кусков псевдокода на ходу, если нужно. Так же, как бы мы общались с коллегой на проекте, раскуривая какую-то новую функциональность и укладывая ее в наши структуры. И тут уже видно многое - и формат привычен, осязаем. Примерно так же придётся работать. Помогут ли задачи оценить это мышление? Отчасти - не будет видно навыка работать с реальностью, ведь абстрактные задачки все фармят. Будет ли видно мышление? Отчасти да, даже если долго готовился и решил сходу - можно изменить условие и глянуть, как будет искаться решение. Но проще всё же беседовать о чем-то приближенном к реальности, имхо

Синьорита фронтенда?)

Саш, вот ей богу, щас совсем не думается 🫠😅 . Время байки 🤷‍♂️