Это спорно конечно. У нас долгое время было тестовое которое проверяло догодаешься ли ты до наследования. Никакой пользы в проде этот код не нес.

До лайвкодинга ещё нужно дойти 😅 Перед ним вполне могут предложить тестовое на несколько часов, после которого до следующего этапа ты так и не дойдёшь.

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

Не знала, что так бывает) какой смысл в тестовом до лайвкодинга, если второй вариант как раз-таки нагляднее, понятнее и прозрачнее..? Разраб. может это тестовое сделать совершенно любым способом, кроме как сам. До лайвкодинга обычно собес с обсуждением общих тем и техническими вопросами. Как правило, такого комбо хватает.

Бывает и не такое 😅

Да, относятся. Но не только к готовому результату тестового, а ко всему процессу его выполнения и последующему обсуждению.

Тогда декомпозиция задачи, которая целиком занимает 2-3 часа, выглядит излишней

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

Но тогда возникает обратный вопрос: если сильные специалисты не хотят тратить время на тестовое, точно ли такой отбор помогает компании найти лучших кандидатов? 🤔

Разумеется нет . Слишком условно и искусственно. В продуктиве очень много мелких деталей кардинально влияющих на процесс решения.

В данном случае , я потратил время на тестовое, просто тема интересная была. Самое прикольное - в ответ тишина, оьратнлц связи - 0. Так, пара мелких вопрос не относящихся к теме задания. На собеседовании ни слова не спросили 😎

В итоге по результатам решения тестового задания +3 полезных практических статьи в мой блог. В общем то неплохо 👌

9 часов - это тоже, мягко говоря, немало 😅 А 20 часов на тестовое - уже совсем серьёзный объём. Теперь даже интересно, как они это оценят. Возможно, посмотрят не столько на незавершённость, сколько на то, что вы успели сделать за это время и какие решения приняли. Если вернутся с обратной связью - расскажите, чем в итоге закончилась история? Реально интересно.

Ожидаемо по зарплатному фильтру не прошел. Так и сказали.

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

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

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

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

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

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

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

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

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

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

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

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

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

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