В Клубе, будем честны, много разного профиля разработчиков ПО. И этот батл в основном к вам: первый этап собеседования — тестовое задание или whiteboad (live, paper) coding?
Как принято в батлах: без оговорок о сложности, оплачиваемости и т.д.
Вы за красных или за белых за синих или за зелёных?
за «Тестовое задание»
за «Coding при свидетелях»
Давно топлю за мантру: либо покажи код на гитхабе, либо вот тебе тестовое задание, сделай, потом сможешь выложить его на гитхаб и показывать на следующих интервью в других компаниях.
Мне кажется, это честно по отношению к личному времени разработчика (он пишет ТЗ лишь один раз), и дает интервьюеру возможность более полно оценить способность индивида к программированию (структурность, соблюдение правил, линтеров, бест практик, итд).
Ни один вайтборд на время этого не покажет. Вообще не понимаю зачем их делают, это же чистая лотерея.
Ну и напоминаю, что оценка кода — лишь один из маленьких этапов всего большого квеста найма.
Мне очень тяжело делать что-то вразумительное в условиях вайтборда. Начинаю волноваться, вплоть до появления тремора. Ну не привык я к таким условиям. Проходит только когда я хорошо знаком с присутствующими. На работу не влияет.
Лично мне проще онлайн кодинг - можно вести диалог, уточнять что надо, а что нет. Плюс все равно это в разы быстрее, я как беру тестовое задание "на пару часов", как правило убиваю день - начинаю сомневаться, а то ли от меня хотят, может надо спросить, а может не надо. Уходишь в дебри кодстайла, тестов, CI, поиска библиотек или велосипедостроения и тд и тп. Вечно нету времени - вечером ребенок, с утра английский и работа. А так выделил час на собес, покодили вместе и забыл.
Тестовое задание по факту — мини-работа. Вы даёте ТЗ, назначаете срок и в этот срок человек приносит своё "сделалъ". Ну, или не приносит. И тестовое даёт некоторое представление, а как он будет уточнять требования, насколько точно и педантично он выполнит ТЗ или чем будет отмазываться и как разговаривать о сроках.
Просто пишешь код небольлой промежуток времени, обсуждаешь и больше не думаешь о нем никогда.
Однажды мне дали тестовое с формулировкой:"Потратьте на него не больше часа" - окей. В итоге на собеседование ко мне придирались, что оно сделано небрежно. Ну офигеть теперь.
Когда присылают громадное тестовое, я на него смотрю и думаю:"Блин, на это я потрачу несколько вечеров," - и не могу себя заставить делать. Жалко времени. Я пишу код на одной работе, пишу код на другой работе. Я вообще не хочу тратить несколько вечеров на решение типовой задачи.
Был один идеальный вариант: после собеседования договорились, что мне отправят задачу, а я через пару часов залью решение на гитхаб.
Реже попадаются абстрактные задания.
Я за тестовое. Нервозности меньше.
Могу делать когда хочу (хоть днём, хоть ночью), могу гуглить как хочу, SoF, форумы, чаты. Забыв какую-то простейшую хрень на собесе, будет очень стрёмно её гуглить. А сам с собой — не проблема.
К тому же, рабочий режим всё равно ближе по происходящему к тестовому заданию, чем к кодингу при наблюдателях.
Ну как-то так…
Редко видел действительно короткие "домашние" тестовые задания, разве что откровенно джуновские. А что-то серьезное выливается в 1-2 вечера реальной работы.
Плюс лайвкодинга в том, что на нем можно(и нужно) вести диалог. Можно проговорить варианты, обсудить их плюсы и минусы, выбрать самый подходящий и оставить без реализаций не важные для задачи детали. Я считаю что это дает больше знаний о кандидате, чем вылизанный кусок кода.
Кодинг при свидетеле проверяет ненужные программисту вещи: стрессоустойчивость, скорость кодирования и красноречие. А на работе стресса, как правило, нет, сидишь расслабленно в офисе, кодировать надо в срок, но плюс-минус месяц, да и задачки потупее. Ну, либо фирма - сраная потогонка со стрессами, опенспейсом, неумением заменять дедлайны на просто лайны - или вообще геймдев. Я бы держался от таких подальше.
Тестовое задание с последующей защитой ближе к тому, чем ты будешь заниматься. Я бы ещё включил в него некоторую коммуникацию - проверял бы способность кандидатов обсуждать неполные ТЗ, достигать компромиссов, сводить сияющие feature-packed бредни к компактному MVP и способность не реализовывать функционал, который не будет нужен.
Сейчас нахожусь в поиске работы на прогревающемся тракторе. Заведомо не стал рассылать резюме в фаанг, потому что там надо вращать деревья. А я ios разработчик и мне все эти деревья и связанные списки в работе нужны почти никогда (есть применения, но не каждый день от слова совсем). Мелкие компании пока что не просили никакого вайтборда, а спрашивали именно существующий код на гитхабе посмотреть, чтоб даже тестовое не делать (хотя я и не против). Но тут попался на встречу букинг. Первый тур из 4 задачек прошел быстро и успокоился. Пообщался дальше, прошел в следующий тур и мне говорят - а теперь хотим посмотреть как вы решаете задачки в реальном времени. Прочтите зеленую книжку и готовьтесь по хакерранку. Вот и зачем? Код на гитхабе им неинтересен, про предыдущий опыт слушать им тоже неинтересно. Получается мой опыт коммерческой разработки больше чем 6 лет можно выкинуть и как специалиста меня показывают только знания обхода дерева и как быстро найти элемент в массиве? Уже вижу как проваливаю собес в следующую пятницу и больше никогда не думаю о работе в букинге.
Не знаю как в программировании, но в моей сфере тестовое задание это пол дня в лучшем случае, в худшем - несколько дней, неделя.
Новое веяние моды вообще за гранью добра и зла: приложите решенное тестовое к отклику, а потом мы может быть с вами пообщаемся 🤦♀️ ага, щас
В лайв-кодинге есть ограничение по времени, через пару часов это неминуемо закончится.
Согласна со всеми доводами из зелёной ветки. Не нужно уделять много времени, можно пообщаться с собеседующими, чтобы уточнить, что именно они имеют ввиду. Как правило, собеседующие не хотят тратить много времени, поэтому задачка, скорее всего, будет не очень сложная, минут на двадцать. При решении даже простой задачи, подход и ход мыслей джуниора, миддла и сеньора будут значительно отличаться. Очевидно, что собеседовать тим лида задачками никто не будет.
Главное, чтобы либо у собеседующих, либо у кандидата на вакансию была подготовлена площадка, где можно будет показать код, чтобы он вывел ответ в консоль, например.
А то сидишь часами, и вроде написал, но вроде можно и лучше, и нафиг эти страдания вообще.
А бывает еще как пришлют какую-нить фигню, которую и делать-то неинтересно, и думаешь - ну нормально же общались, или вы правда думаете, что fizzbuzz покажет вам всю глубину моей души? И сидишь ищещь подвох.
Один раз мне в рамках тестового предложили написать эссе. ЭССЕ!
Вот уж что точно можно вынести в собсно собес.
Прикладная кодинг-задача в формате парного программирования на релевантную к проекту тему для понимания акуратности, знаний ООП, DDD на практике, использования структур даных, етц. Быстро отсеивает неадевкатов и программистов "на словах".
Можно либо писать что либо с нуля, либо рефакторить кусок кода. Зависит что мы ищем.
В условиях конкуренции за кадры тестовые задания отсекают слишком много кандидатов (нет времени делать, не так понял, показалось слишком обьемным, перехватили и.т.д).
С кодинг задачей, при меньших затратах времени с обоих сторон и более быстрой обратной связью мы имеем приблизительно:
Каждый выбирает трейд-оф для себя :)
Все равно окончательно оценить рабочие качества и вписываемость можно только поработав вместе месяцок другой.
Если вы лучше всех и все к вам хотят, то можно и недельные тестовые давать.
Онлайн-кодинг ставит программиста в стрессовые условия, хотя его работа не предполагает выполнения заданий в таких условиях. Надо ли говорить, что результат работы при нервяке, вызванном наблюдающим, всегда оказывается хуже, чем может быть. Лично я из-за таких переживаний уже три раза проваливал собесы в Яндекс, хотя задачи-то там элементарные.
С другой стороны тестовые тоже нужно уметь составлять, они не должны подразумевать времязатраты в несколько рабочих дней, максимум - половину рабочего дня. А если больше, то справедливо было бы предложить разработчику оплату за выполнение этого задания.
На тестовом можно показать свой стиль кода, свой подход к решению реальных задач, знание фреймворков, библиотек. Написал так -- покрутил -- работает -- не понравилось -- переписал, рефакторнул, вот теперь красота.
Есть что обсудить на следующем этапе интервью. Почему именно так написал, почему не эдак, а как можно было бы лучше -- причём обсуждаться будут именно такие вот реальные рабочие кейсы, а не вращение сферических деревьев в вакууме.
Внимательность и логику кандидата проверить можно: мне пару раз попадались тестовые с ошибками в техническом задании.
Да даже софт-скиллс: как именно, какими словами кандидат сообщит о том, что в ТЗ косяк?
Что обсуждать-то после алгоритмических задач -- можно ли уменьшить Big-O решения? Здорово, а что я о кандидате пойму из такой беседы, кроме того, что он "Cracking the code interview" читал? Неее.
Мой опыт показывает что в случае тестового "пару часов" ну никак не пару часов, а обратная связь по сделанному тестовому всегда приходит в письменном виде через HR-а. И ответные аргументы почему я сделал Х а не Y улетают в воздух. Ну и золотой фонд:
Идеальный вариант - кандидату скидывают "рыбу" проекта (Hello - world приложение) с настроенными API ключами к сторонним сервисам (если надо) и задание (обязательные и желательные требования). Кандидат делает на своем железе, по ходу дела комментируя что он делает и в конце обсуждаем что получилось/не получилось и как реализовать недоделанное.
Идеальное задание по мне – это короткое тестовое с последующим звонком с обсуждением твоего решения.
Со стороны соискателя тратишь больше времени, зато без стресса и с кодом, за который не стыдно, на выходе. Во время звонка есть возможность объяснить все свои решения и рассказать что можно было доделать.
Со стороны работодателя надо потратить время и на ревью и на звонок, зато сразу можно оценить качество кода и во время звонка гораздо проще задать наводящие вопросы и прощупать сильные и слабые стороны.
Вообще мне редко попадались тестовые задания, но два раза мне попались клевые, и я их запомнила.
Оба тестовых мне потом пришлось защищать на втором раунде собеса, и там, и там по полтора часа. Вот это была самая жуткая часть. Как по мне, это гораздо тяжелее лайв-кодинга.
Нужно сказать, что все тестовые, которые мне предлагали, сразу предполагали второй раунд интервью с защитой и обсуждением решения. Если бы мне сказали "сделай тестовое, а мы решим, будет ли второй раунд", я бы послала таких товарищей на рынок кандидатов.
На самом деле, как мне кажется, оба варианта не являются взаимозаменяющими, а, скорее, взаимодополняющие. Это как "зубы чистить" vs "зарядку делать".
При этом очень важно при любом выборе давать наиболее понятную задачку. Для whiteboarding обычно задачка дается меньшего размера, потому что ее решение задерживает обе стороны. ДЗ же при этом делается асинхронно, поэтому есть возможность гуглить, и ревьюеры стараются придумать туда что-то нестандартное, при этом обычно здоровенное, на день-пару работы.
Оценивает кандидата и то, и другое примерно одинаково плохо, однако вариант с вайтбордингом, как мне кажется, более быстрый, плюс можно напрямую задать сразу вопрос, почему кандидат выбрал такой вариант решения, а не другой, а также попробовать реактивно понять ход его мыслей. С ДЗ все гораздо дольше, контекст утерян, взаимопонимание - тоже...
Основная проблема и тестовых заданий и лайв кодинга это их ограниченность - конечно важно понять сможет ли человек быть полезным с конкретно вашим проектом и вашей кодовой базой. Самый простой вариант это дать несколько тикетов на пофиксить. Но чаще всего вы ограничены NDA/IP а то просто настроить окружение тот еще челлендж да и тикеты порой такие что без ментора не разберешься. А если еще у вас проекты раз в полгода меняются(аутсорс) или реорги или пивоты.
К сожалению тестовое задание далеко не всегда сможет полностью показать все навыки сотрудника и каков был процесс решения, что наиболее важно а в некоторых моментах оно даже не очень удобно компании с точки зрения закона (оплачиваемая работа). Хотя надо отметить что этот вариант дешевле организации лайв-кодинг сессии.
Поэтому я считаю что более точно задачу оценки навыков написания кода решает тот самый лайв кодинг в ходе которого опытный итервьювер может определить насколько эффективно сможет этот человек решать задачи компании (на самом деле вопрос даже - "а готов ли ты с ним проект делать вдвоем, ревьювить код, писать доки, доверять ему ревью своего кода").
Но тут важно правильно организовать и оценивать процесс интервью - смотреть не решил/не решил, работает/не работает а больше - как происходит процесс написания кода (какие вопросы были заданы какие нет, были ли намеки на тесты, уточнил ли edge case, как именует переменные, оставляет ли комментарии) ну и насколько владеет базовыми знаниями.
Я к сожалению провожу довольно мало кодинг интервью, в основном архитекуру и дизайн, но в обоих интервью у меня есть интересные задачи и вопросы которые позволяют достаточно точно определить и уровень разработчика и опыт (опять же важно понять что "измерение" происходит для данной конкретной компании и то что вы прошли или не прошли это зависит от конктекста компании).
Решение синтетических задач за ограниченное время в работе не используют, поэтому в топку.
Если на встрече болтать, а не код писать, успеется обсудить гораздо больше.
Собеседования вида «защити домашку» — одни из самых продуктивных, что у меня были как и в качестве собеседующего, так и в качестве собеседуемого. Раскрывают подход к решению задач, покажет, можете ли вы говорить на одном языке (применительно к рабочим задачам) и покажет, как человек пишет реальный код.
Если кандидат не хочет тратить время на написание тестового проекта, я вполне могу почитать любой его проект на гитхабе и предложить защитить его.
У меня был и позитивный и негативный опыт с тестовыми.
Негативный: сидел в офисе рабочий день и фигачил круд, после чего получил 0 фитбека по самому заданию.
Позитивный: за 3 часа до звонка скинули задание. Оно было интересное. Я в спокойной домашней обстановке накидал решение. После чего мы продуктивно обсудити код, попросили добавить фичу. Тут и лайв кодинг, но уже спокойный и без нервов.
Подробнее про задание можно почитать тут: https://t.me/toxic_enterprise/39
Во-первых, на собеседование выделяется конкретное время (у меня обычно это 1,5-2 часа) и уважительно к обеим сторонам в него уложиться. Тестовое задание - это 2-4 часа кандидата и 10-15 минут на проверку от нанимающего. Несправедливо.
Во-вторых и в главных, при лайвкодинге можно сразу проверить, как человек дискутирует, как ищет решение, как взаимодействует с лидом при обсуждении решения. Код в гитхабе по результатам ТЗ всего этого не дадут.
На тестовое задание можно нанять синьора на апворке (сам видел там объявления) или более опытного знакомого, особенно при подаче на джуна/интерна. Сталкивался со случаями, когда кандидаты откровенно валились, когда на следующем этапе написанный «ими» код обсуждался. Подозреваю, что чем выше уровень и чем уже специализация, тем менее актуален этот аргумент, но там и в принципе ниже важность умения кодить.
Я сразу выскажу свои фи касательно тестовых заданий:
Каждый раз когда процесс интервью предлагают начать с ТЗ, подо мной сгорает кресло. Я могу понять когда тестовое просят в самый последний этап и предупреждают об этом, но бывают случаи, когда еще до голосовых интервью на чек адекватности и софт/хард скилов сразу просят написать какую-нибудь "очень нужную" шляпу. Очень забавно, когда на предложение глянуть в гитхаб говорят что нужно сделать именно их тестовое. Если и делать тестовое, то только оплачиваемое - имхо.
Такой подход это перекладывание временных затрат на плечи соискателя (глянуть код - 5 минут, особенно с типовым заданием, написать этот код - пара часов). Для меня такое отношение это что-то на уровне трекинга при удаленке.
Потому онли лайвкодинг - равноценно тратятся обе стороны, да и сразу понятно кто кого. Но я понимаю людей которые предпочитают ТЗ, не многим нравится писать код под чьим то надзором
Даю тестовое задание (если нет подобного ТЗ в публичной репе кандидата) на неделю, позволяет выявить самостоятельных бойцов, тех кому нужен мастер, и оценить степень вовлеченности. Недели хватает и подумать и реализовать решение. Результат на публичный Github. В ряде случаев еще неделю-две дорабатываем проект (для закрепления внутренних правил разработки).
Да, и вторым этапом мы разбираем тестовое задание и вживую (Visual Studio Live Share) исправляем какие либо недочеты, или добавляем функционал.
Чем ваша контора лучше других контор которые НЕ дают тестовые задания? Почему кандидат должен потратить свое время на тестовое что бы попасть именно в ВАШУ компанию? Может у вас 4х дневная рабочая неделя? Или может зп на 30% выше рынка? Погодите погодите, наверное у вас работникам выдаются акции вашей компании и они так же ценны как акции Yandex, Google, Facebook?
Нет ничего из этого? А что же тогда есть то? А точно, зп в белую, соцпакет, и свободный график...свободный это когда баг на продакшене и вам надо будет в 2 часа ночи его устранять...ну так сорян у всех такие условия...
С гитом тоже не все так просто, хз как там у других но в моем личном гите только те проекты за которые мне капает денежка, и честно признаюсь код там вообще не идеальный, но кого это волнует если оно приносит заказчику деньги? А вот проект который будет "шатать" деревья или в крестики нолики со мной играть - мне деньги не приносит...
Дайте человеку прочитать более менее сложный код, дайте ему на это время, и если он поймет что этот код делает, вероятность того что он сможет написать что то схожее будет высока.
Я собеседую в основном аналитиков и тестировщиков и слабо представляю формат тестового задания. Поэтому мне проще онлайн дать простую задачу и посмотреть, как человек будет рассуждать.
Если кто поделится идеями тестового задания для аналитиков и тестировщиков - буду признательна
Мне психологически проще написать тестовое задние в спокойной обстановке, чем переживать за то, что я затуплю на собесе
После работы у меня нет лишнего времени тратить пару вечеров на чье-то ТЗ, особенно, если таких компаний несколько.
А если задание на полчаса-час, то мне не сложно и в офисе его сделать на глазах у людей