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

Святая правда, меня так пару компаний потеряли. Я об этом писал в статье

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

И что этим тестовым заданием хотели посмотреть? Как я пишу код? Так для этого можно на гитхаб зайти посмотреть, я же его указал в резюме. Ну или прямо на собеседовнии можно простой код написать.
Узнать как я шарю техническую жесть и знания технологий? Ну так тут задача на один контролер с десятью строчками кода. Ну и опять таки — резюме, гитхаб, вопросы.
В другой компании дали обычную TDD кату пройти. Опять таки: ну и что по этой кате можно узнать? Шарю ли я ТДД? Ну шарю, это можно и вопросом выяснить. Может какую архитектуру я наваял в итоге? Так по ТДД архитектура всегда выходит не самая лучшая, зато рабочая. Это всегда так при разработке снизу вверх.
И да, тоже пять часов её втыкать не интересно.

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

А вот что мне реально понравилось и считаю хорошей практикой — это когда мне дали листинг кода и спросили какие ты тут проблемы видишь и как бы отрефакторил.
И тут да, сразу поехало: тут ненужный автобоксинг, тут дженерик бы дописать, вот это в метод заэкстрактить, тут в JDBC лучше сделать prepared statement и ещё забыли ресурс закрыть. 15 минут за которые интервьювер узнал про меня в разы больше чем за пятичасовое тестовое задание.
Когда в следующий раз буду сам собеседовать обязательно возьму эту практику.

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