окей, принято

всем привет, а ни кто не в курсе о проведении каких либо "соревнований" по тестированию в рунете в ближайший месяц?  где то видел предложение регистрировать на подобное мероприятие свою команду, но сейчас уже не найду

Мне почему-то, внезапно, кажется, что между готовностью разбираться с незнакомой задачей и анти-перфекционизмом нет прямой взаимосвязи. Почему Вам кажется обратное?

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

Если при этом человек не готов потратить Н времени на тестовое задание - значит нам с ним в разные стороны и это экономит всем время.
Win - win.

Связь - в количестве незнакомого. Возможно, я не права, так как с джунами не имела дела уже лет пять, и сейчас под  джуном подразумевается нечто более квалифицированное, ближе к тому, что под джуном видят в США где-нибудь. Но тут для выполнения задания требуется: уметь базово в докер; иметь представление о тестинге апи, как это вообще делается, что проверяют и т.д.; уметь писать автотесты = знать хоть один фреймворк и хоть один язык программирования, или хорошо уметь в Постман (еще вопрос, что проще). Если ничего этого нет, у человека должны быть очень завышенные представления о том, что он может это освоить за неделю - или сколько там дается на это ТЗ - или заниженные представления о задаче.  С этим обычно и коррелирует подход "и так сойдет". С хорошей и тщательной работой обычно коррелирует некоторая неуверенность в своих силах :)

Это просто наблюдения за джунами :)

А так, конечно, готовность разбираться с незнакомым - хорошее качество.

А вы попробуйте мидлов приглашать. Все равно придут джуны, но хоть чуток полегче будет. (это шутка, если что).

А это для всех грейдов работает.

У Сергея Пирогова было на канале показательное сэмпл-интервью в этом плане, только я как всегда название канала не помню

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

Это, конечно, утрировано, но отражает суть.

и наизусть iso 10218

У нас в КЗ вот на такое Епам приглашают:

https://community-z.com/events/qa-camping

Приглашаем принять участие в QA Camping
В нашем онлайн лагере участники со своими командами в течение трех дней будут выполнять задания по написанию Тест Плана и Тест-Кейсов, а также оценивать трудозатраты и риски.
Победителей ждут призы!

на эти аргументы мне возразить нечего, я лишь расскажу случай из моей практики. Был на проекте сотрудник, чьи компетенции лежали исключительно в доменной области, работе приложения и знании откуда куда скопировать значение и куда потом в эксельке положить. Но некоторый опыт взаимодействия с автоматизацией дал плоды и сотрудник в одиночку разобрался с известным фреймворком и самостоятельно написал покрытие функциональности на питоне. Да, на код без слез смотреть нельзя, но код работающий и решающий важные бизнес задачи. Теперь этот сотрудник на другом проекте участвует в написании тестов на джаве. Я не делал код-ревью, да и сам не бог весть какой джавист, но уверен, что у человека все получится. Но если бы те, кто этого сотрудника собеседовал  самом начале, не проверяли бы работоспособность и понимание доменной области, а попросили бы в докере запилить тесты на селениуме, то сложный мануал-онли проект вероятно не досчитался бы толкового сотрудника и не появилас бы одна саксесс-стори.

Ответ очевиден - если для задачи нужно 5 лет обучения робототехники, то надо брать не джуна на джунскую зп.

Не, там именно соревновательный процесс, какая команда быстрее и больше багов найдет.

Недавно было, ага, тоже у нас.
Пока свежего не видел.

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

Если задание Шу направлено на выявление способности не бояться разбираться в больших массивах новой информации, то отсев "перфекционистов" здесь -- положительный результат.

И потом, получить базовые представления о докере за пару часов не предполагает автоматическое обретение "умения в докер". Задача решена -- отлично. То же самое и с автотестами: можно не уметь ни в какой фреймворк, но написать тест. Кривой-косой, но пруф оф концепт будет.

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

напоминает анекдот про "1 рубль за удар молотком и 999 за то, что знаю, куда бить"

Так я и не говорил, что мне нужен идеальный красивый код.
Я говорил, что мне нужно решение, которое человек считает достаточным.
Если он выдаст переусложненную вундервафлю - это будет настолько же плохо, насколько и код «на который без слез не взглянешь». Но главное что бы:
1) Человек решил задачу.
2) Мог рассказать почему именно так («по другому не умею» - тоже ответ).