Абсолютно согласен, особенно актуально в среде дизайнеров. Делаешь тестовое, тебе отказывают, а идея идёт в брендбук недобросовестного работодателя 😅

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

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

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

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

Сейчас уже не знаю насколько такое было бы эффективно.

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

При этом с ИИ забавная ситуация: уже видел здесь мнение, что если говоришь на собеседовании, что активно используешь ИИ - это может насторожить. Если говоришь, что не используешь - тоже странно. И в итоге непонятно, какой ответ вообще считается правильным 😅 Понятно, что навык писать самостоятельно со временем может проседать. Поэтому я и продолжаю делать свои проекты и иногда специально решать что-то без агента. Хотя после того, как привыкаешь закрывать задачу с ним в 3-4 раза быстрее, терпения на ручной режим уже заметно меньше.

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

Считаю что главное понимать код и проект. Если код генерируется быстрее чем приходит его понимание, то тут и возникают проблемы. Я уже знаю случаи когда даже люди читающие diff'ы иногда говорят: "Фича слишком большая, читать не буду. Я проверил, всё работает, тесты проходят, значит норм". Честно говоря не хотелось бы такого будущего. Хочется понимать как и что работает, а так же получать кайф от написания кода, как раньше когда ты написал, оно заработало и кайфуешь от осознания этого.

Подписываюсь под вашими словами. Кто бы знал ещё лет 5 назад, что фраза про удовольствие от написанного своими руками кода будет звучать почти романтично 😄

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

Должно. Но много вкусовщины - то есть а мы пишем так !!!! И не как иначе - об этом на проекте договариваются обычно между собой. Широкий разброс технологий и версий технологий - обычно в онбординг это приводится к норме и еще куча ньюансов. Иными словами для нормального написания тестового задания разработчик должен потрать много времени. А то что говорится - да за 2-3 часа успеешь - я тут просто приводил пример уже. Мне дали тестовое - я всунул его в ИИ - перенес результат и оформил - еще и запустил - ушло как раз присловутых 2-3 часа. При этом я код по 8 часов в день тогда писал и пишу сейчас. То есть рука набитая. И тестовое задание было из разряда ниже среднего. То есть простенькая задача с ньюансами. А бывает что готовую систему хотят и специально еще ловушки встраивают - что бы написать такое замучались

Понял, что вы имеете в виду. Согласен: иногда уже по самому описанию тестового понятно, что это далеко не история на 2–3 часа. И если от кандидата ждут нескольких вечеров полноценной работы, мне кажется вполне логичной компенсация такого времени. Оплачиваемое тестовое в этом смысле выглядит хорошим компромиссом. Другое дело, что встречается такое, мягко говоря, далеко не всегда 😅