Тестовое задание
или
Coding при свидетелях
 Публичный пост    6 ноября 2020  2140

В Клубе, будем честны, много разного профиля разработчиков ПО. И этот батл в основном к вам: первый этап собеседования — тестовое задание или whiteboad (live, paper) coding?
Как принято в батлах: без оговорок о сложности, оплачиваемости и т.д.
Вы за красных или за белых за синих или за зелёных?

Связанные посты
16 аргументов и 298 плюсиков
за «Тестовое задание»
16 аргументов и 148 плюсиков
за «Coding при свидетелях»
за «Тестовое задание»
Важно увидеть реальный код, написанный осознанно

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

Мне кажется, это честно по отношению к личному времени разработчика (он пишет ТЗ лишь один раз), и дает интервьюеру возможность более полно оценить способность индивида к программированию (структурность, соблюдение правил, линтеров, бест практик, итд).

Ни один вайтборд на время этого не покажет. Вообще не понимаю зачем их делают, это же чистая лотерея.

Ну и напоминаю, что оценка кода — лишь один из маленьких этапов всего большого квеста найма.

Во всех тестовых, что я получал, было написано, что их нельзя публиковать %(

  Развернуть 1 комментарий

@emocoder, а что будет, если их опубликуешь?

  Развернуть 1 комментарий

@mixbez, не возьмут на работу второй раз, видимо

  Развернуть 1 комментарий

@emocoder, ну это хуйня, тикай з городу

  Развернуть 1 комментарий

@vas3k, границы-то закрыты!

  Развернуть 1 комментарий

@emocoder, ГРАНИЦЫ ТОЛЬКО В ТВОЕЙ ГОЛОВЕ ПОВЕРЬ В СЕБЯ

  Развернуть 1 комментарий

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

Первые отборы будут годными, а потом качество отсева упадет.

  Развернуть 1 комментарий

@0Lphcss3iiKRRz9w, дело не в тебе, дело во… других. Т.е. у любого адекватного программиста первая мысль посмотреть похожие решения. Программист находит твоё, делает косметику, сдаёт.

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

  Развернуть 1 комментарий

@smileijp, оценка истории коммитов не поможет как-то определить, скопипастил или нет? Понятно, что можно обойти при желании, но вопрос будет ли желание так запариваться.

  Развернуть 1 комментарий

@alexshevelev, самое простое, сказать, что ты и так тут сам себе самурай. Поэтому сначала закодил, а потом коммитнулся.

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

  Развернуть 1 комментарий

@0Lphcss3iiKRRz9w, так это компания собеседует. Что ее волнует, то и будет влиять на формат. Опять же, если код твой, проблем нет. Проблемы для компании, если ты стащил чужой и теперь выдаешь за свой.

На всякий случай оговорюсь. Я не то, чтобы хочу прям агитировать за конкретный формат.

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

Но во всех случаях, если ты просто хочешь ходить по собесам, формат задаст компания. Она нанимает. Последнее слово за ней.

  Развернуть 1 комментарий
за «Тестовое задание»

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

Вот прям люто плюсую. Ещё со времён школы такое, когда все контрольные на «отлично», а у доски всё в разы хуже.
Наткнулся недавно на отличную формулировку, когда начинаешь тупить в такой ситуации: «Я не глупый, я просто паникую» =)

  Развернуть 1 комментарий
за «Coding при свидетелях»
Нету времени на ТЗ + общение

Лично мне проще онлайн кодинг - можно вести диалог, уточнять что надо, а что нет. Плюс все равно это в разы быстрее, я как беру тестовое задание "на пару часов", как правило убиваю день - начинаю сомневаться, а то ли от меня хотят, может надо спросить, а может не надо. Уходишь в дебри кодстайла, тестов, CI, поиска библиотек или велосипедостроения и тд и тп. Вечно нету времени - вечером ребенок, с утра английский и работа. А так выделил час на собес, покодили вместе и забыл.

можно вести диалог, уточнять что надо, а что нет

ну это же можно и тестовом сделать, ведь это часть будущей работы - общаться, задавать вопросы. или я ошибаюсь?

  Развернуть 1 комментарий

@n3akr, как правило HR'ы шлют тестовой, а еще чаще агенты посредники, я пробовал так "спрашивать", ответы по два дня доходили. У меня, к примеру, нету желания по недели делать их.

  Развернуть 1 комментарий
  1. Вот задание на пару часов
  2. Убиваешь целый день на настройку окружения, потому что с нуля никогда ничего не начинал на работе
  Развернуть 1 комментарий

@emocoder, собственно да, примерно это и имел в виду. Не так давно, я убил два дня, пытаясь организовать миграции liquibase и их автогенерацию из jpa сущностей, по хитрому, как я это себе видел. В итоге тестовое не сделал, но зато хорошо изучил liquibase, вплоть до того, что сделал даже PR в их репу, но он висит уже полгода и никто не реагирует на него :)

  Развернуть 1 комментарий

@emocoder, о, да

В Cabify мне прислали задание понаделать сервисов, которые нужны для работы такси - задачка интересная, но то, что все это должно жить по канонам, каждый в своем докере, в том числе бд - сильно изменилось скоуп задачи, которую я бросил не перейдя к кодингу

  Развернуть 1 комментарий
за «Тестовое задание»
Не нервируйте программиста

Тестовое задание по факту — мини-работа. Вы даёте ТЗ, назначаете срок и в этот срок человек приносит своё "сделалъ". Ну, или не приносит. И тестовое даёт некоторое представление, а как он будет уточнять требования, насколько точно и педантично он выполнит ТЗ или чем будет отмазываться и как разговаривать о сроках.

Часто вопрос к тестовым ровно в том есте, в котором они вытекают из "мини"-работы в довольно обычную, которую при этом без внятного тз еще и не захотят оплачивать

  Развернуть 1 комментарий
за «Coding при свидетелях»
Всего час-два времени и все

Просто пишешь код небольлой промежуток времени, обсуждаешь и больше не думаешь о нем никогда.
Однажды мне дали тестовое с формулировкой:"Потратьте на него не больше часа" - окей. В итоге на собеседование ко мне придирались, что оно сделано небрежно. Ну офигеть теперь.

Когда присылают громадное тестовое, я на него смотрю и думаю:"Блин, на это я потрачу несколько вечеров," - и не могу себя заставить делать. Жалко времени. Я пишу код на одной работе, пишу код на другой работе. Я вообще не хочу тратить несколько вечеров на решение типовой задачи.

Был один идеальный вариант: после собеседования договорились, что мне отправят задачу, а я через пару часов залью решение на гитхаб.

Помню, в бородатые времена у Яндекса было что-то вроде «подойдёт ваш любой opensource-проект; если нет ни одного, напишите новый, по такому-то ТЗ»

  Развернуть 1 комментарий
за «Тестовое задание»
Реже просят «вращать деревья»

Реже попадаются абстрактные задания.

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

  Развернуть 1 комментарий
за «Тестовое задание»
Стесняюсь гуглить при наблюдателях

Я за тестовое. Нервозности меньше.

Могу делать когда хочу (хоть днём, хоть ночью), могу гуглить как хочу, SoF, форумы, чаты. Забыв какую-то простейшую хрень на собесе, будет очень стрёмно её гуглить. А сам с собой — не проблема.

К тому же, рабочий режим всё равно ближе по происходящему к тестовому заданию, чем к кодингу при наблюдателях.

Ну как-то так…

за «Coding при свидетелях»
Время и совместный подход к решению

Редко видел действительно короткие "домашние" тестовые задания, разве что откровенно джуновские. А что-то серьезное выливается в 1-2 вечера реальной работы.

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

за «Тестовое задание»
Проверяет более правильные вещи

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

Тестовое задание с последующей защитой ближе к тому, чем ты будешь заниматься. Я бы ещё включил в него некоторую коммуникацию - проверял бы способность кандидатов обсуждать неполные ТЗ, достигать компромиссов, сводить сияющие feature-packed бредни к компактному MVP и способность не реализовывать функционал, который не будет нужен.

Вот как раз умение обсуждать ТЗ и внятно объяснять свои решения совершенно незнакомым людям требует гораздо, гораздо большей стрессоустойчивости и красноречия чем потупить часок в Гугл-док. Я бы поспорил, что таких железных чуваков можно скорее встретить в отделе корпоративных продаж, а не среди разработчиков.

  Развернуть 1 комментарий
за «Тестовое задание»
За час решения олимпиадных задач ты наймешь непонятно кого

Сейчас нахожусь в поиске работы на прогревающемся тракторе. Заведомо не стал рассылать резюме в фаанг, потому что там надо вращать деревья. А я ios разработчик и мне все эти деревья и связанные списки в работе нужны почти никогда (есть применения, но не каждый день от слова совсем). Мелкие компании пока что не просили никакого вайтборда, а спрашивали именно существующий код на гитхабе посмотреть, чтоб даже тестовое не делать (хотя я и не против). Но тут попался на встречу букинг. Первый тур из 4 задачек прошел быстро и успокоился. Пообщался дальше, прошел в следующий тур и мне говорят - а теперь хотим посмотреть как вы решаете задачки в реальном времени. Прочтите зеленую книжку и готовьтесь по хакерранку. Вот и зачем? Код на гитхабе им неинтересен, про предыдущий опыт слушать им тоже неинтересно. Получается мой опыт коммерческой разработки больше чем 6 лет можно выкинуть и как специалиста меня показывают только знания обхода дерева и как быстро найти элемент в массиве? Уже вижу как проваливаю собес в следующую пятницу и больше никогда не думаю о работе в букинге.

Удачи на собесе. Ну и любой опыт пригодится. Хотя бы, чтоб больше в такое не наступать. И, конечно, странная практика: уже человек порешал задачки, но пусть теперь порешает задачки ещё и с присмотром.

  Развернуть 1 комментарий

@DmitryPopov, спасибо. Да, именно за опытом попробую на собесе посмотреть, что да как. Не ожидал такого поворота от букинга, честно говоря. Но видимо это бич больших компаний. Хотя казалось бы, вот мой гитхаб, я специально запинил и выписал репы, которые можно посмотреть и оценить мой код и чем я интересуюсь и работаю. Не, все фигня :D давай задачки.

  Развернуть 1 комментарий

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

Так что посмотри не только на то как решить задачу, но и на все эти танцы вокруг неё

  Развернуть 1 комментарий

@MarinaK, я знаю эту "мотивацию" собеседующих. Сам проводил не одно техническое собеседование, но никогда таким не занимался. Тут выше уже писали, что подобные хотелки посмотреть не отражают реальной картины. Онлайн кодинг может быть хорош в формате:
"У нас есть вот такой вот модуль, такие-то данные надо отобразить вот так-то. Как бы ты спроектировал это? Накидай интерфейсиков вот в онлайн редакторе, примерно как видишь.". И тут тебе уже открывается весь простор для фантазии, уточняй требования, рисуй диаграммы, пиши псевдокод.
А обходить дерево мобильному разработчику нужно примерно никогда (нет, бывает нужно, но это типа справочные алгоритмы. Если ты по какой-то причине не можешь обратиться к справке, то скорее всего мир рухнул и твоя айти работа уже не актуальна :)).

  Развернуть 1 комментарий

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

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

Нерешенная задача не факт, что крест на твоей кандидатуре, если ты проявил все ожидаемые нетехнические компетенции.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@angelooooook, а чего так? можно в личку, если не хочется тут (@petrachkovsergey в телеге)

  Развернуть 1 комментарий

@SergeiPetrachkov, а почему не ожидал от букинга такого?

  Развернуть 1 комментарий

@tomasmor, на это есть две причины:

  1. букинг != фаанг (наивно подумал я)
  2. Ну ладно фаанг, хрен с ними. Остальные же должны понимать, что раз я мобильный разраб, то со мной лучше говорить про мобильную разработку, а не про алгоритмы, ведь мы чаще решаем вопросы перекладывания джейсонов в кнопки и лейблы, а еще как абстрагировать это так, чтоб можно было не заморачиваться рутинными процессами (наивно подумал я во второй раз).

Я как бы по работе решал всякие сложные задачи и не описал бы свой опыт как просто перекладывание джейсонов, было очень много разного. Но ни разу не сталкивался с задачей обойти дерево, например. И почему-то я уверен, что у букинга тоже таких задач нет для мобильных разрабов. Почему я зацепился за деревья? Потому что в письме от рекрутера мне пришли материалы и темы для подготовки, которые можно сократить до "зазубри зеленую книгу"

  Развернуть 1 комментарий

Мне кажется что снова приходит мода на вращение деревьями. Меня уже и на фронтенде алгоритмы спрашивают на собесах.

  Развернуть 1 комментарий

@ganqqwerty, не, ну может в отсутствие примеров кода или отказе от выполнения тестового задания деревья и могут учитываться за валидный этап, но когда тут перед тобой все лежит, то как бы возникает резонный вопрос: "какого хрена?". Ведь вам посмотреть на мой код займет не так много времени, сколько сидеть и тупить в экран, пока я чертыхаюсь над задачей. Реактор финский меня порадовал - давай ссылки на гх, я посмотрю что там у тебя. Тестовое задание? Зачем, у тебя ж вот код лежит публичный. По нему и пообщаемся.

  Развернуть 1 комментарий

Боже какая жиза

  Развернуть 1 комментарий

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

@SergeiPetrachkov, А вот не соглашусь. Они не отражают полную картину - это правда. Но вот базовые вещи вполне неплохо себе отражают в значительном проценте случаев. Не в 100 - это точно. С другой стороны если 40-60 минут позволят отсеить хотя бы 70% людей, у которых пара проектов на гитхабе (непонятно кем сделанных) - оно того стоит.

  Развернуть 1 комментарий

Что об iOS разработчике может рассказать то, как быстро он развернёт связанный список кроме того, что он знает что это такое? :)
Я не против, что кому-то нравится решать задачи и что кто-то до сих пор не видит иного способа собеседовать профессионалов. Просто мне не по пути с такими компаниями.

  Развернуть 1 комментарий
за «Coding при свидетелях»
Я не программист, но мнение имею

Не знаю как в программировании, но в моей сфере тестовое задание это пол дня в лучшем случае, в худшем - несколько дней, неделя.

Новое веяние моды вообще за гранью добра и зла: приложите решенное тестовое к отклику, а потом мы может быть с вами пообщаемся 🤦‍♀️ ага, щас

В лайв-кодинге есть ограничение по времени, через пару часов это неминуемо закончится.

В программировании та же фигня. Простое тестовое «на полчасика» легко гуглится и ты получишь пачку одинаковых идеальных решений. Сложное тестовое требует кучу времени и усилий, куча кандидатов просто отвалится на этом этапе.

  Развернуть 1 комментарий
за «Coding при свидетелях»
Как правило coding при свидетелях занимает меньше времени

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

Главное, чтобы либо у собеседующих, либо у кандидата на вакансию была подготовлена площадка, где можно будет показать код, чтобы он вывел ответ в консоль, например.

за «Coding при свидетелях»
Час позора — и ты свободен

А то сидишь часами, и вроде написал, но вроде можно и лучше, и нафиг эти страдания вообще.

А бывает еще как пришлют какую-нить фигню, которую и делать-то неинтересно, и думаешь - ну нормально же общались, или вы правда думаете, что fizzbuzz покажет вам всю глубину моей души? И сидишь ищещь подвох.

Один раз мне в рамках тестового предложили написать эссе. ЭССЕ!
Вот уж что точно можно вынести в собсно собес.

Эссе о чём? О жизни, о работе, на свободную тему?)

  Развернуть 1 комментарий

@sleepydisaster, о хранении данных, вестимо. Это все-таки было типа техническое тестовое задание.

  Развернуть 1 комментарий
за «Тестовое задание»
На самом деле тут применима теорема Эскобара, но онлайн кодинг мне нравится меньше

Онлайн-кодинг ставит программиста в стрессовые условия, хотя его работа не предполагает выполнения заданий в таких условиях. Надо ли говорить, что результат работы при нервяке, вызванном наблюдающим, всегда оказывается хуже, чем может быть. Лично я из-за таких переживаний уже три раза проваливал собесы в Яндекс, хотя задачи-то там элементарные.
С другой стороны тестовые тоже нужно уметь составлять, они не должны подразумевать времязатраты в несколько рабочих дней, максимум - половину рабочего дня. А если больше, то справедливо было бы предложить разработчику оплату за выполнение этого задания.

за «Тестовое задание»
Мы же устраиваемся работу работать, а не спортивным программированием заниматься, верно?

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

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

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

Да даже софт-скиллс: как именно, какими словами кандидат сообщит о том, что в ТЗ косяк?

Что обсуждать-то после алгоритмических задач -- можно ли уменьшить Big-O решения? Здорово, а что я о кандидате пойму из такой беседы, кроме того, что он "Cracking the code interview" читал? Неее.

за «Coding при свидетелях»
Одинаковые трудозатраты с обоих сторон

Мой опыт показывает что в случае тестового "пару часов" ну никак не пару часов, а обратная связь по сделанному тестовому всегда приходит в письменном виде через HR-а. И ответные аргументы почему я сделал Х а не Y улетают в воздух. Ну и золотой фонд:

  • вот тестовое, тут на пару часов
  • убиваю целый день, присылаю
  • у вас тестов нет и память утекает
  • "В ТЗ тестов не было (даже в бонусных пунктах), а память не утекает. Давайте с профайлером посидим, я докажу (ну или вы мне покажете, я стану умнее)
  • молчание

Идеальный вариант - кандидату скидывают "рыбу" проекта (Hello - world приложение) с настроенными API ключами к сторонним сервисам (если надо) и задание (обязательные и желательные требования). Кандидат делает на своем железе, по ходу дела комментируя что он делает и в конце обсуждаем что получилось/не получилось и как реализовать недоделанное.

за «Coding при свидетелях»
Быстрее. Лучше конверсия.

Прикладная кодинг-задача в формате парного программирования на релевантную к проекту тему для понимания акуратности, знаний ООП, DDD на практике, использования структур даных, етц. Быстро отсеивает неадевкатов и программистов "на словах".
Можно либо писать что либо с нуля, либо рефакторить кусок кода. Зависит что мы ищем.

В условиях конкуренции за кадры тестовые задания отсекают слишком много кандидатов (нет времени делать, не так понял, показалось слишком обьемным, перехватили и.т.д).

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

  • тот же True Negative(не взять плохого)
  • тот же True Positive (взять хорошего)
  • ниже False Negative (не взять хорошего)
  • выше False Positive (взять плохого)

Каждый выбирает трейд-оф для себя :)

Все равно окончательно оценить рабочие качества и вписываемость можно только поработав вместе месяцок другой.

Если вы лучше всех и все к вам хотят, то можно и недельные тестовые давать.

за «Тестовое задание»
Меньше стресса и понятно какой будет код

Идеальное задание по мне – это короткое тестовое с последующим звонком с обсуждением твоего решения.

Со стороны соискателя тратишь больше времени, зато без стресса и с кодом, за который не стыдно, на выходе. Во время звонка есть возможность объяснить все свои решения и рассказать что можно было доделать.

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

за «Тестовое задание»
Если тестовое — это приглашение к основной фазе собеса

Вообще мне редко попадались тестовые задания, но два раза мне попались клевые, и я их запомнила.

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

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

А как Вы поняли, что будет сразу второй раунд?
У меня недавно так и вышло, написал код, потратил субботу, и мне дали говно ревью, без какой либо возможности обсудить. Основной идей было: нельзя использовать std::cout для логирования( хакеры могут взломать! Серьёзно Карл?! и не было ни слова в ТЗ об этом).

  Развернуть 1 комментарий

@AleksandrLiadov, ну мне так и говорили: вот вам тестовое, срок неделя, обсуждение в следующий вторник с 14 до 16, если есть вопросы по заданию - то пишите вот этому чуваку, он его составлял, если не успеете до этого срока - сообщите заранее, мы отменим/перенесем аппойнтмент.

Как-то так.

Не, тестовые без обсуждения - нафиг. Это какая-то игра в одни ворота получается.

  Развернуть 1 комментарий
за «Coding при свидетелях»
Задачи для вайтбординга обычно более понятные и простые

На самом деле, как мне кажется, оба варианта не являются взаимозаменяющими, а, скорее, взаимодополняющие. Это как "зубы чистить" vs "зарядку делать".

При этом очень важно при любом выборе давать наиболее понятную задачку. Для whiteboarding обычно задачка дается меньшего размера, потому что ее решение задерживает обе стороны. ДЗ же при этом делается асинхронно, поэтому есть возможность гуглить, и ревьюеры стараются придумать туда что-то нестандартное, при этом обычно здоровенное, на день-пару работы.

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

за «Coding при свидетелях»
Мне важно понять как человек думает и как принимает решения в процессе а не результат

Основная проблема и тестовых заданий и лайв кодинга это их ограниченность - конечно важно понять сможет ли человек быть полезным с конкретно вашим проектом и вашей кодовой базой. Самый простой вариант это дать несколько тикетов на пофиксить. Но чаще всего вы ограничены NDA/IP а то просто настроить окружение тот еще челлендж да и тикеты порой такие что без ментора не разберешься. А если еще у вас проекты раз в полгода меняются(аутсорс) или реорги или пивоты.

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

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

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

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

за «Тестовое задание»
Проверять нужно то, что потом будет использоваться в работе

Решение синтетических задач за ограниченное время в работе не используют, поэтому в топку.

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

  • Собеседования вида «защити домашку» — одни из самых продуктивных, что у меня были как и в качестве собеседующего, так и в качестве собеседуемого. Раскрывают подход к решению задач, покажет, можете ли вы говорить на одном языке (применительно к рабочим задачам) и покажет, как человек пишет реальный код.

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

  • Это не отменяет лайв-секций в общем. Например, собеседования на траблшутинг, архитектуру или на «попиздеть за технологии» я всё равно считаю полезными.
за «Тестовое задание»
Если время для тестового ограничено

У меня был и позитивный и негативный опыт с тестовыми.

Негативный: сидел в офисе рабочий день и фигачил круд, после чего получил 0 фитбека по самому заданию.

Позитивный: за 3 часа до звонка скинули задание. Оно было интересное. Я в спокойной домашней обстановке накидал решение. После чего мы продуктивно обсудити код, попросили добавить фичу. Тут и лайв кодинг, но уже спокойный и без нервов.

Подробнее про задание можно почитать тут: https://t.me/toxic_enterprise/39

за «Coding при свидетелях»
Проверка взаимодействия, приближенная к реальным условиям

Во-первых, на собеседование выделяется конкретное время (у меня обычно это 1,5-2 часа) и уважительно к обеим сторонам в него уложиться. Тестовое задание - это 2-4 часа кандидата и 10-15 минут на проверку от нанимающего. Несправедливо.
Во-вторых и в главных, при лайвкодинге можно сразу проверить, как человек дискутирует, как ищет решение, как взаимодействует с лидом при обсуждении решения. Код в гитхабе по результатам ТЗ всего этого не дадут.

за «Coding при свидетелях»
Сложнее читерить

На тестовое задание можно нанять синьора на апворке (сам видел там объявления) или более опытного знакомого, особенно при подаче на джуна/интерна. Сталкивался со случаями, когда кандидаты откровенно валились, когда на следующем этапе написанный «ими» код обсуждался. Подозреваю, что чем выше уровень и чем уже специализация, тем менее актуален этот аргумент, но там и в принципе ниже важность умения кодить.

за «Coding при свидетелях»
Из двух зол второе лучше

Я сразу выскажу свои фи касательно тестовых заданий:
Каждый раз когда процесс интервью предлагают начать с ТЗ, подо мной сгорает кресло. Я могу понять когда тестовое просят в самый последний этап и предупреждают об этом, но бывают случаи, когда еще до голосовых интервью на чек адекватности и софт/хард скилов сразу просят написать какую-нибудь "очень нужную" шляпу. Очень забавно, когда на предложение глянуть в гитхаб говорят что нужно сделать именно их тестовое. Если и делать тестовое, то только оплачиваемое - имхо.
Такой подход это перекладывание временных затрат на плечи соискателя (глянуть код - 5 минут, особенно с типовым заданием, написать этот код - пара часов). Для меня такое отношение это что-то на уровне трекинга при удаленке.
Потому онли лайвкодинг - равноценно тратятся обе стороны, да и сразу понятно кто кого. Но я понимаю людей которые предпочитают ТЗ, не многим нравится писать код под чьим то надзором

за «Тестовое задание»
Простая проверка многих качеств

Даю тестовое задание (если нет подобного ТЗ в публичной репе кандидата) на неделю, позволяет выявить самостоятельных бойцов, тех кому нужен мастер, и оценить степень вовлеченности. Недели хватает и подумать и реализовать решение. Результат на публичный Github. В ряде случаев еще неделю-две дорабатываем проект (для закрепления внутренних правил разработки).

Да, и вторым этапом мы разбираем тестовое задание и вживую (Visual Studio Live Share) исправляем какие либо недочеты, или добавляем функционал.

за «Coding при свидетелях»
Вы готовы дать оффер кандидату на 30% больше?

Чем ваша контора лучше других контор которые НЕ дают тестовые задания? Почему кандидат должен потратить свое время на тестовое что бы попасть именно в ВАШУ компанию? Может у вас 4х дневная рабочая неделя? Или может зп на 30% выше рынка? Погодите погодите, наверное у вас работникам выдаются акции вашей компании и они так же ценны как акции Yandex, Google, Facebook?
Нет ничего из этого? А что же тогда есть то? А точно, зп в белую, соцпакет, и свободный график...свободный это когда баг на продакшене и вам надо будет в 2 часа ночи его устранять...ну так сорян у всех такие условия...
С гитом тоже не все так просто, хз как там у других но в моем личном гите только те проекты за которые мне капает денежка, и честно признаюсь код там вообще не идеальный, но кого это волнует если оно приносит заказчику деньги? А вот проект который будет "шатать" деревья или в крестики нолики со мной играть - мне деньги не приносит...

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

за «Coding при свидетелях»
Я собеседую в основном аналитиков и тестировщиков

Я собеседую в основном аналитиков и тестировщиков и слабо представляю формат тестового задания. Поэтому мне проще онлайн дать простую задачу и посмотреть, как человек будет рассуждать.

Если кто поделится идеями тестового задания для аналитиков и тестировщиков - буду признательна

за «Тестовое задание»
Психологический комфорт

Мне психологически проще написать тестовое задние в спокойной обстановке, чем переживать за то, что я затуплю на собесе

за «Coding при свидетелях»
Принципиально не делаю тестовых заданий

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

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб