Базовые структуры данных и алгоритмы это, в целом, то, что укладывается в двухнедельный курс по алгоритмам на условном стэпике - деревья, стэк, очередь, массивы разных видов, ну и соответственно поиски, сортировки и пр (на самом деле, скорее понимание гриди и д&к принципов).

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

Ага, спасибо. Все равно пока не могу понять, как знания алгоритмов (greedy, поиск и т.п.) могут помочь среднему джуну в среднем вебе/мобилках. Регексы? от них обычно больше проблем, чем пользы.

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

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

Тогда уж сразу паттерны проектирования, чистый код и знание устройства тест фреймворка

Вот к фемиде у меня, кстати, есть большие вопросы. Из-за этих задачек мы за год наняли 0 автоматизаторов. При том что приходили ребята в том числе с собственно внедренными фреймворками на 2к+ тестов в коммерческой разработке. Но да, без знания бинарных деревьев

Ну, ровно потому, что “тестировщикам алгоритмы нинужны”.

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

В разных ситуациях исход будет разным.

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

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

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

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

Продукт-то работал? Профит приносил? Зарплата человеку платилась, повышение получал? Вероятно - да, а значит - успешно реализовывал свой потенциал :)

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