Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Почему не стоит давать тестовые задания. И почему не стоит их делать

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

Для начала определимся с контекстом. Тестовое задание (домашнее задание, ДЗ) — это задание, выполняемое кандидатом вне собеседования, схожее с его должностными обязанностями. Далее мы будем рассматривать применимость ДЗ как этап фильтрации кандидатов на позиции разработчиков. Скорее всего, похожие проблемы будут возникать и при найме других технических специалистов.

Теоретически ДЗ выглядит очень привлекательно, ибо наниматель, как он считает, может увидеть, что умеет кандидат в «боевых условиях», и тем самым упростить процесс найма. Проблема в том, что это так выглядит только на первый взгляд. На практике же часто оказывается, что «достойных» кандидатов находить становится еще сложнее, а на рынке полно «неадекватов», которые берут ДЗ и отвечают «мы вам перезвоним».

Чтобы понять, насколько применимо ДЗ для поиска специалистов, попробуем ответить на 2 вопроса:

  • Какие выводы можно сделать из невыполненного задания?
  • Какие выводы можно сделать из выполненного задания?

Какие выводы можно сделать из невыполненного задания

Можем ли мы сказать, что кандидат не является хорошим специалистом, если он не выполнил ДЗ? К сожалению, нет. Оказывается, что у людей бывают и другие интересы помимо программирования. И поскольку программированием человек занимается 8 часов (ну или 4-6) на работе, то в свободное время ему логично уделять другим своим интересам. Те же, кому не хватает 8 рабочих часов для любимого занятия, довольно часто имеют свои пет-проекты, и совсем не факт, что ваше ДЗ будет интереснее, чем уже начатые проекты. Бывает и еще одна категория людей — те, у кого не установлено все необходимое для работы на домашнем компьютере. Таким образом, в придачу к тем, кто не может выполнить задание, мы также отсеиваем тех, кто не хочет выполнять или не может выделить достаточно времени на выполнение задания.

Какие выводы можно сделать из выполненного задания

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

Излишне позитивное впечатление от ДЗ может создать похожие проблемы и при найме «не джуниоров». Как-то во время собеседования у меня не спрашивали ни одного вопроса по Spring, потому что «из моего решения было очевидно, что у меня большой опыт с этим фреймворком». На тот момент мой опыт со Spring состоял из 2 просмотренных видосиков и проекта длиной в 3 дня.

Размер и типы заданий

В размере тестового задания как раз и кроется основной фактор, который делает его неэффективным инструментом. Если задание занимает менее часа, то его вполне можно дать во время собеседования. При таком подходе есть возможность проверить те самые «problem solving skills», которые многие путают с алгоритмическими задачками. Как раз благодаря небольшому времени на решение довольно популярны алгоритмические задачи. Из плюсов таких задач можно отметить простоту проверки, ибо если код читабельный (это требование актуально для всех адекватных компаний), то на проверку такой задачи уйдет минут 10-30. А еще есть Codility и другие сервисы, которые позволяют автоматизировать процесс. К сожалению, у этого подхода есть небольшой недостаток: сама алгоритмическая задачка проверяет только знание кандидатом конкретного алгоритма (максимум группы алгоритмов). Многие подсознательно устанавливают порядок между базовыми знаниями CS и всем остальным (работа с БД, корректное применение паттернов, умение писать тесты и т.д.). В реальном мире эти навыки параллельны.

В задание менее 4 часов довольно сложно впихнуть задачу, требующую большего, чем просто выполнение механических действий. Именно поэтому типовые задачи в диапазоне 2-4 часа — это напилить CRUD, разобраться с API или инструментом. С точки зрения проверки такого задания, оно схоже с ревью небольшого незнакомого вам проекта. Если задача — просто быстро понять, нет ли грубых залетов, такое ревью можно и на 15 минут сделать. Но в таком случае зачем было давать тестовое, подобное решение может быть закрыто прочтением резюме и тем же 15-минутным общением с кандидатом по телефону (если уж хочется сэкономить время на проведение собеседования). Более же вдумчивое ревью займет минут 30-60, что соизмеримо по времени с общением на интервью, но проверяющий не имеет возможности уточнить, почему были приняты те или иные решения, в отличие от интервью.

Задания от 4 часов до 2-3 дней. Из позитивных моментов, вы сможете проверить насколько кандидат мотивирован получить работу в вашей компании (по крайней мере насколько он прямо сйечас мотивирован). При этом в плане затрат вашего времени на вдумчивую проверку задания уйдут те же 30-60 минут, но уже с большей вероятностью 60, чем 30. На таких заданиях уже можно ожидать какого-то определенного уровня качества. При этом нужно понимать, что любое решение задачи — это всегда trade-off между качеством и скорость выполнения. И вполне может оказаться, что решение было сделано хуже, чем могло бы быть, как раз потому что кандидат не сложен к overengineering. Чтобы узнать, почему было принято определенное решение, нам нужно таки провести собеседование. Таким образом, мы потратили дополнительно час своих работников. Также необходимо понимать, что любое задание, которое занимает больше одного вечера (теоретически вечер — это 4 часа, в реальности — 2), очень существенно уменьшает количество желающих его выполнять.

Идеальное тестовое задание — это испытательный срок (ИС). Практика показывает, что большинство негативных моментов связанных с компетентностью человека и его умением работать в команде, всплывают в первую неделю-две испытательного срока (конечно же, бывают случаи, когда такие моменты проявляются уже после ИС, независимо от его длины :) ). Поэтому некоторые компании практикуют ДЗ на 3-5 дней. За этот период мы можем увидеть, как человек решает достаточно комплексные задачи, насколько качественный код он выдает, как общается с командой (уточняя требования, например). Тут есть 2 проблемы. Первая — затраты времени со стороны компании будут составлять где-то 1 час на день задания. Вторая проблема состоит в том, что множество людей, которые согласятся его выполнять, будет сведено к тем, у кого (на момент решения задания) достаточно свободного времени, чтобы впихнуть в него 24-40 рабочих часов, и достаточно денег, чтобы потратить 24-40 часов не на работу и не на отдых. Хотя это, наверное, не проблема, а просто новый вызов для ПМов и ХРов: как мотивировать такого человека работать предсказуемо в течение длительного периода времени :)

Ранее были описаны случаи, когда ДЗ идет как этап, предшествующий интервью. Бывают случаи, когда ДЗ дают после интервью. Зачем же? Формулировки бывают разные, но они сводятся к тому, что после интервью наниматель не получил достаточно информации, чтобы принять решение. К сожалению, ДЗ и в этой ситуации не помощник. Тут нужно приводить в порядок процесс самого интервью. Понять, что человек не подходит, можно за 15-45 минут, понять, что человек подходит, можно за 30-60. В этом случае ДЗ — это просто попытка интервьюера снять с себя ответственность.

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

Когда тестовое задание эффективно

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

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

Но я люблю делать тестовые задания

Бывают случаи, когда кандидаты предпочитают делать ДЗ. Наиболее распространены 2 типа мотивации: кандидату интересно делать ДЗ, кандидат предпочитает сделать ДЗ вместо «задачи на бумажке». В первом случае все намного проще: нравится — делайте. Но, возможно, стоит задуматься о более предсказуемых способах получения задач для своего хобби или самообучения. Второй же случай сигнализирует о серьезном пробеле в ваших профессиональных навыках. Ибо, как указывалось ранее, «задачки на листиках» проверяют во многом способность человека получить необходимую для решения информацию и объяснить свой подход другому человеку (интервьюеру или члену команды).


Image by Visual Generation

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному1
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Ради этого даже зашел на доу. Всплыли воспоминания, октябрь 2016, очередная «молодая и перспективная» позвала на собеседование. Приехал к ним в офис, полтавский шлях 4 (Харьков если что), здание СпецВузАвтоматики, подымаюсь на третий этаж. Чтобы вы понимали всю комичность ситуации, один кабинет, в нем один светильник, 3 самых дешевых офисных стола и 3 человек за ними со своими ноутбуками, все это гордо именуется IT-компания. Время уже за 20+. Говорим по поводу работы, ну как всегда, чем занимался, какие технологии.Потом мне говорят: «будешь делать тестовое?», ответный вопрос: «сейчас?», мне говорят: «ну да», и в голове мысли — а за что бороться? где цель ? ради чего? — ради того чтобы работать с 9 утра и до 21 вечера и при этом 3 мудака будут мне рассказывать что я им еще спасибо говорить должен,мол с улицы забрали ? сказал твердое НЕТ, обосновывая тем что уже поздно и я устал, на что услышал «нам такие не нужны». Закрывая дверь сказал на прощение : «пока пацаны» и в ответ «и тебе удачи». Короче, господа «очередные майкрасофт», прежде чем давать тестовое задание посмотрите вокруг, а стоит ли ваша контора того, чтобы люди тратили на вас свое время.

Продолжаю настаивать на своей мысли о том, что:
1. Тестовое задание уместно только ПОСЛЕ интервью и достижения предварительного согласия сторон работать друг с другом.
2. Тестовое задание тестирует только один скилл — навыки практического кодирования.

Полностью согласен с автором. ТЗ полная хрень. Тоже пару раз попадал на эту удочку, когда был менее опытным. Тратишь уйму времени, а на тебя просто забивают, ибо к времени, когда ты сделал ТЗ, они уже наняли другого человека, или ещё чего то произошло. Максимум, что можно делать — это прийти на собеседование с ноутом и созданным проектом (либы и все остальное подключено) и попросить человека реализовать пару классом и тестов. Причем вообще не важно будет ли оно работать, главное пообщаться с человеком и увидеть ход его мыслей. Это обычно занимает до 20 минут.
Мое мнение такое: если к тебе не стоит очередь из сотен или тысяч кандидатов — то иди ты лесом со своим тестовым заданием. Если нанимают мидоа или сениора — то чаще всего это нужно именно компании, а не разработчику. А то очень умиляет тебя уболтают пойти на собеседование, а потом начинают спрашивать почему вы хотите у нас работать и предлагают за просто так потратить кучу своего личного времени на ТЗ.
А кучу людей можно отсеивать телефонным звонком минут на 10-15. Идиотов или просто людей которые сильно не тянут на вакансию отметить так очень легко. А преглашать в офис уже после короткого общения.

Тестовое задание только за тестовую зарплату.

Я помню первое ДЗ — сделать почтовый сервер. Меня взяли и первой же задачей было перевести сервер в прод.

244 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Хоч я не просив кандидатів зробити тестове,
Сам колись робив тестові (які явно не робота, а для демонстрації навичок)
І злом їх не вважаю.

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

По затратам времени тоже вполне честно: на 2 интервью и тестовое кандидат тратит примерно 5-6 часов, у нас получается примерно столько же

На всё 3 часа максимум — 5-6 это уже «работать у нас большая честь» ©

а на 3 лишь честь среднего уровня?)

Типа того). Просто не понимаю, зачем тратить столько времени друг-друга. В последнее время относительно много собеседую, и стал ещё бОльшим противником длинных интервью, а особенно задротских. Больше 1.5 часа на тех. собес для линейного дева — это, ИМХО, уже слишком. Кстати, одна компания, находящаяся очень высоко в топе рейтинга крупнейших работодателей DOU, на данный момент страдает именно этим — при чём, детальный чек-лист на 2 страницы они рассчитывают проверить за час, хотя объёма там часа на 2-2.5...

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

Не так давно делал тестjвое ТЗ. Обычно когда предлагают — сразу отсылаю лесом такие конторы, ибо один раз был случай: сделал, а оказывается им просто надо было сделать определенный скоп для своего проекта, а нужного человека не оказалось. В итоге потратил время и получил отказ, так как денег на открытие полноценной вакансии у них не было.

В другой раз так же сказали — делай мол тестовое ТЗ. Опять пошел против своего принципа — дали тестовое ТЗ. Не сложное, с обычным CRUD. Сделал даже больше, добавил паттерн. Отказали без объяснения причин. Вакансия, на которую я претендовал — открыта по сей день (дело было около 3 месяцев назад). Делайте выводы...
Итог: опять потраченное время впустую. Лучше бы я доделывал свой пет-проект или учил что-то новое. Например, Unity3D. Что-то последнее время подсел на него :))))
ПС. Я web-dev.

Справедливо для девелоперів. Дизайнерам всерівно треба тестове

Справедливо для девелоперів. Дизайнерам всерівно треба тестове

Интересно почитать почему (без сарказма). Я-то думал что дизайнер куда более творческая работа. А значит «вдохновение» которое было во время тестового может пропасть когда надо будет рисовать «100500 логотип носочной фабрики». Еще я думал что дизайнеру важно иметь портфолио, а зачем нужно тестовое если есть портфолио?
В дизайне есть свои «фундаментальные знания», но почему их нельзя проверить на собеседование.

дизайнер куда более творческая работа.

ніт.

В дизайне есть свои «фундаментальные знания», но почему их нельзя проверить на собеседование.

ЗЫ: ну дык тестовым или портфолио и проверяют же ж. Просто последнее у дизайнера чаще есть а у программера соотв. нет. По чисто техническим причинам.

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

к.м.к. в этом ключевое отличие дизайнера от программиста у дизайнера портфолио это просто часть процесса это естественно и не противоречит ничему у программиста «портфолио» это скорее... либо никак либо «левак».

смотря как оформить

Якщо в тебе натхнення таке нестабільне, то ти такий собі дизайнер:) Та є і не тільки графічні дизайнери що малюють логотипи чи ілюстрації , а і UX, UI, Architect’и всякі, у яких більш аналітична робота. Там дається тестове з умовою пояснення своїх рішень. Довіряти чи не довіряти — діло кожного, але портфоліо + тестове це явно краще, аніж дивитись просто портфоліо, бо, як було сказано, портфоліо можна зробити нечесним шляхом(не обов`язково копіюючи чиїсь роботи, короче дизайнери зрозуміють). Та і людина ж розуміє що їй доведеться якось працювати, отже і не бачить сенсу обманювати з тестовим.

але портфоліо + тестове це явно краще, аніж дивитись просто портфоліо

В том то и проблема что не понятно почему лучше. Какую доп информацию вы получаете с ДЗ? То что вы написали про «більш аналітична робота» вполне можно выяснить на собеседовании (особенно при наличии портфолио). Люди, которые дают ДЗ, очень часто не видят разницу между больше и лучше.

як було сказано, портфоліо можна зробити нечесним шляхом(

dou.ua/...​-for-job-seekers/#1469582

Якщо в тебе натхнення таке нестабільне, то ти такий собі дизайнер:)

Но вы то его наняли, ибо во время выполнения ДЗ у него было «вдхновение» :)

а шо по портфолио не понять нужен тебе такой дизайнер или нет?

А ви впевнені, що це портфоліо саме цього дизайнеру?

это уже какие-то пограничные случаи да и даже если вдруг есть сомнения можно попробовать поискать через images.google.com или поспрашивать более детально про дизайн чтобы убедиться

Запитувати детально про дизайн? Щось новеньке...

от куда идеи, что хотел заказчик, почему именно так сделал. Если сам делал то ответит. Вот и все

Якщо людина пішла на відверту брехню, ви думаєте складно буде вигадати ще трошки?

если вам сложно определить что человек врет, собеседования — это не ваше

Ви просто не зустрічали гарних брехунів.

Ви просто не зустрічали гарних брехунів.

А зачем тогда давать тестовое? Человек, который намутил портфолио, не сможет намутить ваше тестовое?

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

Как-то странно всех подозревать в обмане

Еще такой вопрос: а оплачивается ли тестовое задание. Когда я пришел в одну компанию, в качестве тестового задания мне дали доработать сайт для конкретного клиента (работы там было часа на 4). По завершении мне оплатили работу и предложили работать с ними дальше. Но там специфика такова, что каждый работник получает оговоренную сумму за проект, нет зарплаты как таковой. Что называется, идеальная подработка.

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

Понятно, что классическое тестовое задание (напиши некую фигню, чтобы работала и отвечала некоторым требованиям по качеству кода) не оплачивается. Но часто бывает и так, когда под видом тестового задания просят выполнить реальную работу. Некоторые платят за нее, некоторые говорят «это было тестовое задание, вы не справились| справились, но не приняты по другим причинам», потом продают результат клиентам.

Ваше мнение?

Еще такой вопрос: а оплачивается ли тестовое задание.

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

Во, кейс 100%-но тему (кстати, с упоминанием этой статьи)
https://******.it/2018/12/05/loopme-hiring/
(ссылка была зацензурирована автоматически, ну в общем там первая звездочка — е, вторая — б)

да, знакомый тоже подавался в эту контору без опыта angular, но с наличием опыта в других фреймворках. дали тестовое и пристебались, если не ошибаюсь, к типизации и к отсутсвию rxjs. я еще подумал: «ну, офигеть»

Дуже дивно читати коменти про не потрібне тестове завдання. Це, мабуть, через викоивлений ринок розробників і, в основному, компанії галерного типу. Хоча, в кожного свій підхід і тестове завдання дійсно дієве вже після інтро та технічного інтервю в нашому випадку. Хоча і тут бувають виключення, якщо людина контрибютить в open-source, наприклад, або має активний аккаунт на GitHub.
Для противників тестового завдання — якщо колись вас запросять на співбесіди в компанії типу Ebay, Xing чи інші продукти, то тестове завдання це буде лише один з пяти етапів і після кожного з них вас можуть відсіяти одним листом;)

компанії типу Ebay, Xing

А в Африці... а в Африці... ну ви тільки уявіть, в Африці маленькі афро-африканці голодують 😢

Це передбачувано, що тут неможливо вести конструктивну дискусію.
Не хвилюйтесь так і тримайте весла міцніше:)

Це передбачувано, що тут неможливо вести конструктивну дискусію.

О каком конструктиве может идти речь если в одну из перечисленных вами компаний можно (было) попасть без ДЗ?
Кстати, несколько лет назад похожая ситуация была со всеми гигантами: людям, которые были в локациях (странанх) где были оффисы Условного Гиганта, даже не предлагали выполнять тестовое, а вот если вы из какого-то там Неизвестностана, то вот вам покодить.

Навряд чи їм давали «покодить» просто так. Спробуйте задуматись чому.
І як виявляється їх таки беруть на роботу після цього dou.ua/...​estern-product-companies

Навряд чи їм давали «покодить» просто так. Спробуйте задуматись чому.

Конечно же не просто так. Я даже дал ответ в статье почему ДЗ очень эффективно для всяких гуглов (конкретно в Гугле вроде бы не дают/не давали).
Кстати, про попытки задуматься: может попробуете подумать почему ДЗ дают не всегда?

Тут спарва не в рівні компанії, хоча це теж дуже суб’єктивне поняття. Справа в тому як бачить компанію кандидат. Якщо він вважає її такою котра йому підходить то він повиннен бути готовим, при потребі, пройти той рекрутмент процес котрий там є. В кожної компанії вибудувані свої процеси і, в більшості випадків, це не просто так.

або має активний аккаунт на GitHub

Это не такое уж и исключение

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

далее, возможно это только у меня так, но я если активно ищу работу, то назначаю до 10 собеседовний в неделю чтобы через неделю-два у меня уже были все фидбеки, а не собирать офферы месяцами и тянуть время пока ответит более желанная контора, если я буду делать тестовые задания, то, во-первых, не хватит времени в сутках на 1-2 тестовых, 8 часов на текущей работе и хотя бы сон :) во-вторых, даже 10 тестовых по 4 часа это типа рабочая неделя, не сильно ли жирно?)

=> соглашусь на тестовое только в супер исключтельной ситуации, пока что такая ситуация была ровно один раз, да и то тестовое было на час: в готовую инфраструктуру очередной круд добавить

P.S.: оффер я тогда не получил, а с проекта всех уволили в течении полугода. и это хороший повод задуматься: умный ли поступок даже в исключительной ситуации соглашаться тратить время вникуда на тестовое задание

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

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

Тестовое задание только за тестовую зарплату.

Итого по разным статьям про ущербность технических собесов я понял следующее:

Тестовые задания давать не стоит — не показательно
Задачи на логику и сообразительность давать не стоит — это же не IQ тест
Теорию спрашивать не стоит — человек в первую очередь пишет код, а не философствует
Вопросы по знанию библиотек/фреймворков давать не стоит — фреймворки не показатель
Вопросы по языку давать не стоит — умный кодер может всего не знать, но разберется. Так что незнание аспектов языка не показатель.

Че ж тогда на тех собесах делать?

Та давайте що хочете та вважаєте за потрібне. Не стримуйте себе. Кандидатам також корисно якомога раніше визначитися, з ким варто мати справу, а з ким — ні. Що, як не задачки про гноміків-геїв у бруклінському газенвагені, дозволяє впевнено та швидко це зробити? :)

Чула від багатьох кандидатів на різноманітні позиції на протязі декількох років про неефективність будь-яких інтерв’ю/ беззмістовність English Check-ів/ образливість тестового завдання як такого.
Тож мені також цікаво, послухаю, що ж його робити :)

Для начала узнать на каких технологиях работал разработчик, сколько у него было проектов на технологии, которую вы будете использовать. Любое тестовое может только определить знает ли разработчик азы языка, но Мидла от Джуна вы не отличите. О Сеньоре речь вообще не идёт, тупые тестовые уровень не покажут. Если вы пытаетесь взять человека на незнакомые технологии будьте готовы что вместо сеньора получите Джуна с большим опытом в ненужных вам технологиях.

Представьте ситуацию: к вам в компанию присылает резюме разработчик уровня Senior с опытом 8+ лет. В резюме десяток проектов с веером технологий. Разработчик из другого города или даже страны

Вот и как мне проверить что то что написано в резюме правда кроме как дать задание?

с опытом 8+ лет. В резюме десяток проектов с веером технологий. Разработчик из другого города или даже страны
Вот и как мне проверить что то что написано в резюме правда кроме как дать задание?

1) Правильно поставить вопрос. Правда или лож в резюме не очень связаны с подходит человек или нет.
2) Провести интервью. В 2018-м году есть милион способов удаленно проводить собеседования.

Но куда проще снять с себя отвественность и кинуть ДЗ, хотя если он проскочит ДЗ потом все равно прийдется за ним таски переделывать :)

Почему правда или ложь не связаны с подходит или нет? Если врет — не подходит ) Если правду написал, я ее прочитал и заинтересован в таком работнике — подходит.

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

— Посмотреть в гитхаб разработчика
— Попросить ссылку на пет проекты

И раскажу вам про секретный способ. О нем мало кто знает, но я вам все-таки выдам. Только вы никому про этот способ не рассказывайте — провести собеседование!

А чем это собеседование будет отличаться от ДЗ?

В смысле? Вы что не можете человека по теории погонять? Спросить какую роль он играл в тех проектах в которых участвовал? Уточнить как и где он применял технологии, которые указаны в резюме?

На эти вопросы за пару походов по собесам я вам придумаю вагон красивых историй и ответов.
Когда я вижу 8+ лет опыта на 3 языках программирования и весь список базвордов у меня возникает очень резонный вопрос: а не набивает ли чувак себе цену?
Это конечно можно проверить техническими вопросами за 3-4 часа. Но у меня есть отличное ДЗ на теже 3-4 часа которое показывает глубину знаний программиста даже в случае если он с ним не справится.

Но у меня есть отличное ДЗ на теже 3-4

Да, собственно, вопрос исключительно в том, будет ли этот условный сениор свои 3-4 часа тратить на этот конвейер :)
За всех не хочу говорить, но по мне так это возможно в двух случаях:
1. Сениору очень нужна хоть какая-то работа (что само по себе намекает, если, конечно, на дворе нет кризиса доткомов).
2. Сениору очень нравится эта вакансия (ну или т.з. на столько оригинально, что его хочется сделать)

Но разве это не комфортней чем теже 3-4 часа разговаривать по скайпу?

Как сказать :)
Если бы можно было быть абсолютно уверенным в том, что результаты твоего т.з. рассмотрят со всей тщательностью — то, может быть, и комфортнее.
А так по default’у у меня лично создается впечатление, что меня хотят прогнать через конвейер — экономя свое время за счет моего.

(В случае же интервью по скайпу-таки весьма вероятно, что коли уж и собеседователь — особенно если он не один — тратит на меня свое время, то намерения, наверное, серьезные).

теже 3-4 часа разговаривать по скайпу?

об чём!!!???

Думаю, тут ещё могут быть варианты типа:
— Сениору очень сильно хочется срочно эмигрировать по любой причине (в случае вакансии с релокацией).
— Сениору хочется хоть куда-то свалить с текущей позиции (не сложилось что-то), а сбережений нет, т.к. приходится например платить ипотеку или ещё какие долги.
— Сениору пофигу, ну тестовое и тестовое. :)

— Сениору очень сильно хочется срочно эмигрировать
— Сениору хочется хоть куда-то свалить с текущей позиции

Это фактически

Сениору очень нужна хоть какая-то работа

(как вариант — хоть какая-то за бугром).

— Сениору пофигу, ну тестовое и тестовое. :)

Вот, честно говоря, таких сениоров не встречал. Может, среди 23-летних такие и есть (ну, семьи нет = время есть), но в той же Германии сениор обычно постарше и временем своим весьма дорожит.

Вопрос:

Вот и как мне проверить что то что написано в резюме правда кроме как дать задание?

Ответ:

Это конечно можно проверить техническими вопросами за 3-4 часа.
Это конечно можно проверить техническими вопросами за 3-4 часа.

3-4 часа? «проверить 8+ лет опыта»? зачем? почему не 3-4 недели? месяца? на худой конец 3-4 года?

Что можно «спрашивать за опыт» в течние 3-4 часа? какими «техническими вопросами»?

Полагаю они НУ ОЧЕНЬ сильно не доверяют соискателям

Или скорее себе... ))

бездуховность! (((

Речь идет о собеседовании по скайпу, меня только по БД гоняли часа полтора как-то.

Якщо ви тестуєте глибину знань сіньйора, то ви тестуєте мідла з амбіціями сіньйора, а не самого сіньйора.

Пояснення дуже просте. Сіньйор зазвичай перестає оперувати дрібничками та кінцевою реалізацією, він оперує абстракціями більш високого рівня. Це значить, що дрібниці можуть просто забуватися через їх величезну кількість, мозок просто перестає запам’ятовувати деталі, які можна легко відновити за допомогою специфікації та гугла.

Розуміння принципів та вміння переходити на вищі абстракції — ось про що треба спілкуватися із сіньором. А це доволі легко перевірити, задавши навіть нетехнічні запитання (не про люки)

как мне проверить что то что написано в резюме правда кроме как дать задание?

А як перевірити, що написане в ДЗ — правда?
А раптом чувак для виконання найняв 5-баксову абізянку на ВебЛанці?
А може за нього завдання робили дівчина/хлопець/брат/сестра/сусіди?

Дайте вгадаю: доколупатися до деталей реалізації?

Власне, ви мені нагадали ще одну вагому причину, з якої тестові варто посилати на всі чотири сторони. Одне діло, коли з гівном намагаються змішати одразу під час інтерв’ю, попередньо не зазіхаючи на 3-4 години особистого часу, інше — коли по результатам виконання тестового лізуть зі шкіри, щоб «підловити»... наприклад, на незнанні директиви вебпаку на 100500му рядку сгенерованого CLI’шкою конфігу )

Ну тут просто — сделанное абизяной задание мне не понравится )

Мне кажется вы просто не видели хороших ДЗ. Я вот во многом согласен с автором статьи и с вами, и это все применимо к огромному количеству глупых ДЗ типа «напишите рест апи».
Нормальное же ДЗ дает множество способов проверить кандидата без доколупываний к конфигу вебпака.

Нормальное же ДЗ дает множество способов проверить кандидата без доколупываний к конфигу вебпака

Все о таких читали, но никто их не видел )

спросить что-то из опыта что джун не нагуглит

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

Например nodejs / backend

как деплоил на прод, что-нибудь из best practices, оптимизации производительности или кеширования. Я не nodejs специалист, но спрашивал бы что-то что постигается уже на продвинутом использовании технологий по собственному опыту уже. Лучше всего кейсы где есть несколько вариантов решений все верные и будут работать но одни будут более правильные и отказоустойчивые, другие нет

ИМХО, мидл в этих вопросах не будет как-то отличатся от сеньора.

спрашивайте тогда вопросы специфические для вашего представления о сеньоре. Эти должности очень эфемерны.

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

Які особливості nodejs роблять цю платформу кращими та гіршими за браузер?
Які варіанти кластерізації можливі за допомогою nodejs?
Як побудувати ідеальний роутінг?

Если сам сеньор, то это любой открытый вопрос.
Если нет, то вопросом не вычислишь.

Вопрос следуте ставить шире не «как?» но «могу ли я вообще?» вот тогда многое становится уже много интересатее и интересатее.

Ты же ж в нём как раз пишешь «превозмогая боль» )) а вообще да есть такое я тут научился функции в браузере «фигурного заглядывания в исходный код» использую её для выколупывания картинок и видео которых прямо по кнопке сохранения скрыто закрыто и таки да там внутре такое ну такое... ))

ЗЫ: с другой стороны там «у светных облачных падаванов» (к) (тм) похоже опять стало не хватать производственных ресурсов и они обратились к старому доброму проверенному методу «а давайте напишем всё на си++!» (к) (тм) вот смотри что удумали Introducing the C++ Lambda Runtime [AWS Compute Blog] enjoy! ))

Ты же ж в нём как раз пишешь «превозмогая боль»

Как клиенту пофиг, не сам же интерпретирую этот ваш JS :)
а вообще, если бы это была рассылка, было бы не принципиально хуже.
Тем более что тут картинки не вставляются.

Про волшебное словосочетание «Испытательный срок» не слышали?

Если синьор, с большой долей вероятности, не будет заморачиваться с поиском решения в интернете и просить товарищей сделать тестовое, то вот с джуниорами все может оказаться (и на практике оказывалось) не так радужно. И тут ДЗ может сыграть с вами злую шутку, поскольку на момент собеседования у интервьюера может сложиться излишне позитивное впечатление о кандидате, так и кандидату проще «сдавать зачет», когда он знает подмножество тем.

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

Из собственного опыта: тестовое задание хорошо, когда ты джун и когда у тебя нет своих проектов или кого-либо серьёзного коммерческого опыта. Тогда можно написать простенькую задачку (4-8 часов), чтоб продемонстрировать, как ты пишешь код.
Меня так взяли джуном на одну из моих первых работ.
На собеседовании немало спрашивали именно по тестовому: почему я выбрал в таком-то месте ту или иную структуру данных, решил использовать или или иной алгоритм. Если бы я писал код не сам, это бы сразу же всплыло, а так — было о чём поговорить на собеседовании, помимо теории.
И это на тот момент было вполне адекватно.
И да, на работу взяли. Проработал там достаточно долго. Не жалуюсь.

Но на следующее место работы шёл уже без тестового.

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

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

Чтобы понять, насколько применимо ДЗ для поиска специалистов, попробуем ответить на 2 вопроса:
Какие выводы можно сделать из невыполненного задания?
Какие выводы можно сделать из выполненного задания?
Идеальное тестовое задание — это испытательный срок (ИС).
Какие выводы можно сделать из невыполненного задания?
Какие выводы можно сделать из выполненного задания?

=>

Идеальное тестовое задание — это испытательный срок (ИС).

==

Какие выводы можно сделать из пройденного испытательного срока?
Какие выводы можно сделать из непройденного испытательного срока?

Обычно ИС случается так «оп-па тут у нас чувак у него срок истёк что будем делать? ну а как вообще чувак хороший чувак? а х.з. я же ж и не видел его я занят был я думал Боб им занимается... не ну вроде хороший чувак я помню на митингах он был вроде ни в чём отрицательном не замечен надо брать!» (к)

Ну такое.

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

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

Это ни в коем случае не отменяет того, что на вкус и цвет все фломастеры разные.

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

ты не поверишь но ты только что описал реальное в 146% случаев положение вещей ))

или надо дропать.

это всё только в теории на практике это 146% сильно сложнее сделать и даже более того.

ни в коем случае не отменяет того

вот именно что ))

Богдане, а можете поділитися статою:

Скільки тестових ви зробили (якщо робили), або від скількох відмовилися, наскільки ця практика досі розповсюджена з вашого досвіду

Чи ви самі колись давали робити тестове кандидатам?

Скільки людей ви винайняли (під цим мається наувазі що ваше рішення було вирішальним)?

реализовать что простое из STL (vector, string, matrix и т.п.)

ты сам-то внутренности-то самого «простого stl» давно открывал-то? ))

если тебе всего-то нужно повторить интерфейс этих классов с большего.

Забей чувак ты не шаришь в том что пишешь )) я тебе уже написал что там одних только функций в «повторить интерфейсе» десятки это не считая «сопутствующих классов» но да я твою точку зрения как раз хорошо понял и ты её ещё раз и повторил так что всё ок ))

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

Для какого «такого задания»? )) про это «ничего всё это не нужно» в «таком задании» ничего не было сказано ))

ЗЫ: я например думаю что достаточно будет резко ограничить «как в stl» и написать в «задании» более конкретно скажем «1 (один) конструктор по-умолчанию и 1 (один) метод emplace_back» и собственно всё уже этого 1 (одного) задания хватит как раз и на «полтора часа тестового задания» и на «а поговорить?»

А то что вы выдаёте за «тестовое задание» это ерунда почему это конкретно ерунда и почему это будет ещё и в уже реальной работе я уже написал.

ЗЫ: ок «почему в реальной работе» таки не написал написал только что 146% таки будет.

ЗЫ: впрочем «почему» таки тоже написал ок ))

Разумно только после успешного собеседования попросить человека реализовать что простое из STL

Що мені заважає подивитися сорци STL і накопіпастити звідти? Маю наувазі не все підряд, а якісь базові структури.

если чел сможет взять класс из STL и скопипастить оттудова 1 (один) метод я думаю он вполне годен работать и как «тестовое задание посмотреть как чел может работать с си++» (к) (тм) это вполне торт.

Это нафиг никому не упала и один метод нафиг не упал.

)) ты сам-то пробовал? с настоящего stl не с «велосипеда очередного стандарта 1898-го года» ))

ЗЫ: кстати а ты знаешь а ведь это хорошая идея! ведь _реальная_ работа как раз и состоит почти 100% в том чтобы «взять и дописать 1 (один) метод» и тут как раз будет проверка и того и другого чистый профитЪ!

Не ссорьтесь, камрады, тем более STL это уже не в моде, теперь boost рулит. ;)
Кста, меня как-то спросили, как реализовать смарт поинтер (помню, что в целом ответил, но на каком-то моменте застрял). При этом пользуюсь ими на автомате boost::shared_ptr<нечтоФинансовое> — это нашеФсё в QuantLib’е — собственно, из-за этого (ну еще из-за unittest suite) они тянут прицепом boost

Ой, да ладно, за час-полтора в спокойной обстановке

Не, у меня было на ходу — на ухе телефон с характэрным ындыйскым акцентом, на экране — онлайн IDE.

Кста, насчет «STL не в моде» беру слова обратно, оказывается теперь вот как в QuantLib (а раньше был только boost)
#if defined(QL_USE_STD_SHARED_PTR)
using std::shared_ptr;
using std::weak_ptr;
using std::make_shared;
using std::static_pointer_cast;
using std::dynamic_pointer_cast;
#else
using boost::shared_ptr;
using boost::weak_ptr;
using boost::make_shared;
using boost::static_pointer_cast;
using boost::dynamic_pointer_cast;
#endif

Скільки тестових ви зробили (якщо робили), або від скількох відмовилися

Делал где-то около 5, отказался где-то от 10+. Тут надо понимать что в 10+ входят как посмотрел — не интересно, так и даже не смотрел.

наскільки ця практика досі розповсюджена з вашого досвіду

Вот тут ужас: не «досі», а «стала». За этот год предлагали сделать тестовое где-то 6 раз, 4 после отказа сказали что ок и мы продолжили общение, 2 уговаривали «у нас корпоративный стандарт».

Чи ви самі колись давали робити тестове кандидатам?

Я такого не помню.

Скільки людей ви винайняли (під цим мається наувазі що ваше рішення було вирішальним)?

Мнение тех специалиста всегда консультативно, решает нанимающий менеджер. Если вы в общем про проведение интервью, то где-то 5 нанятых из где-то 20-30 интервью.

За этот год предлагали сделать тестовое где-то 6 раз, 4 после отказа сказали что ок и мы продолжили общение, 2 уговаривали «у нас корпоративный стандарт».

А що пропонували зробити? Блін, круто, мені чомусь так не щастило, я б подивився на ті тестові інтересу заради.

Давайте пишіть про свій досвід собєсів, а то що я тут один віддуваюсь )))

Ну от я, наприклад, колекціоную саме ті, від яких відмовлявся.

От одне таке на „кілька годин” (ні, в CV в мене жодного слова не було про блокчейн, та й вакансія зовсім не про те).

To get started, read these two articles for building „the tiniest blockchain”:
— Part 1: ​bit.ly/2AUFic6
— Part 2: ​bit.ly/2AWktNu

Your task is to make your own implementation of „the tiniest blockchain” in ES2017 with Node.js distributed in a docker image.

You should build two things:
1. Basic version of the blockchain, as described in the above articles
2. Frontend wallet application (not described in article), that allows a person to track account balance, transfer coins to another account, and show transactions history.

You will be evaluated by your use of classes, async, test coverage (Istanbul + eslint), use of linter (or eslint or other for ES2017), use of OpenAPI Specifications (Swagger), and how the application looks and feels. Choose any database you prefer.

You can use third-party libraries and frameworks to simplify your work.

When posting the code to Github, keep in mind we prefer some commits history in the repo vs single commit. Tests are welcomed and encouraged.

Reply back to the email for this assignment with TWO LINKS:
(1) Link to GitHub Repo (we prefer multiple commits vs a single commit)
(2) Link to Docker image via hub.docker.com

От ще такий креатив за авторством однієї із сумнозвісних кумарних галєр — drive.google.com/...​rOfzKsBs/view?usp=sharing

Не пам’ятаю тільки, звідкіля воно в мене, адже те що їх хоч із тестовим, хоч без, треба обходити десятою дорогою, я знаю давно. Можливо, самі замість «здрасьтє» скинули, можливо, хто із знайомих поділився.

Окремо доставляють моменти накшталт:

These​ ​are​ ​not​ ​a​ ​requirement​ ​but​ ​it​ ​will​ ​be​ ​a​ ​bonus​ ​for​ ​us.
​In​ ​addition​ ​to​ ​requirements​ ​you​ ​can​ ​implement​ ​anything​ ​you​ ​want​ ​using​ ​the API​ ​if​ ​you​ ​want​ ​to​ ​demonstrate​ ​more​ ​skills

Як тут не згадати стрічку Office Space, зокрема сценку www.youtube.com/watch?v=F7SNEdjftno

А от тестове, яке вдалося „проскочити”. Але від того не легше, бо далі, вже при спілкуванні питали один в один те саме, підводячи до Єдино Правильного Рішення (тм) (сумнівного, до речі)

Власне, тому варіант „відмовитися від тестового, але продовжити спілкування” також вважаю не дуже оптимальним; по-перше, вам тіпо роблять „адалженіє”, по-друге, будуть порівнювати з тими, хто кляте тестове все ж таки зробив. Тому, зрештою, краще пошукати контори/проекти без подібних заморочок.

Task:
We have a grid 40000×40000 with cells that contain checkbox and input fields. A user should see a limited number of cells (as many as screen size allows) and have the ability to scroll visible rectangle area to any point of the grid to see data at that point.

— Data should be loaded dynamically (emulate that with a method that generates data with a delay of 0.5 sec)
— If a checkbox is selected, it should disable input field.
— Input field should allow only digits to be typed.
— When you change checkbox or input fields, save button should appear. When a user clicks on it, all modified data should appear in the console
— Should have rulers at the top and left to identify cell coordinates

Requirements​ :
— Vue + Vuex
— User should see the result as soon as possible after scrolling
— Code must be well documented
— Pure HTML/CSS (Bootstrap, etc are prohibited)
— No performance issues and smooth interaction
— Application must be allocated on Github (please provide the link)
— (optional, as a bonus) Covered by tests (you can choose instruments by yourself)

А я без опыта в Ву решил сделать это задание:
— я больше недели его делал
— торопили с результатом
— результат, github.com/4f/vue_huge_table
— больше двух недель не было ответа
— ответ:

Работоспособность матрицы:
1. Не родной скролл
2. Странное поведение матрицы если кликать в одно и тоже место на скролле
3. Есть ошибка `Cannot read prooperty ’next’ of null` при скролле
Код:
1. Eslint ошибки при запуске проекта
2. Я бы поменял структуру changedValues, много лишних действий при его структуре получается (removeChangedValue, setChangedValue)
3. Плохо читабельный код
4. Почему не юзался lodash ?!, можно было убрать много некрасивого кода

А мене подібні задачки взагалі бавлять.
Із контексту зрозуміло, що питання нагальне для проекту, але в той же час зрозуміло, що до якогось певного вирішення вони там вже дійшли.
Проте, в роботі над проектом подібні рішення народжуються еволюційно, під задачу, під умови, та під бізнес вимоги щодо інтерфейсу зокрема. Ну тобто, можливо, вони не один спрінт ламали над цим голову, пробуючи різні підходи, а потім, більш-менш уладнавши це питання, тиць-п_ць, вирішили включили його в задачку для кандидатів, обираючи тих, хто сходу зможе запропонувати рішення, краще за існуюче, і вважаючи всіх інших недостойними )

От в мене на інтерв’ю і спитали, — як зробити сітку дофіга-на-довіга клітин?
Задачу я попередньо бачив, але оскільки, начебто, вдалося проскочити, то і розмірковувати про неї не став. Почувши питання, одразу подумав, що непогано б помацати, як ті 40К на 40К працюють без бубна, а тоді вже про щось говорити, та озвучив думку про те, що задача не з числа пересічних, і навіть усілякі там Фейсбуки та Мешебли при завантаженні умовно «безкінечної» стрічки новин не заморочуються над тим, як воно в кого працюватиме вже після другого десятку порцій контенту; зі мною чемно не погодилися (посягнув на «святе», мабуть), хоча згодом я для себе переконався в тому, що був правий, і той же ФБ тупо вішає все до бісової матері вже після другої сотні блоків у стрічці.
Далі кажу щось накшталт того, що якби те робити на якому-небудь Реакті (також заздалегіть попереджав, що досвіду з Вушкою не маю), то хоч там й віртуальний ДОМ бла-бла-бла, але тим не менш, щонаймегше від навішування одночасно такої кількості хендлерів на інпути я б утримався, тим паче, боронь б-же, байнд-інлайном в render’і(); якби ж те робити на якому-небудь Ангулярі, то краще від гріха подалі перемкнути ChangeDetectionStrategy на щось відмінне від дефолтного.
Але на той час я не підозрював, наскільки вбивча для браузера ТАКА кількість хай хоч і простих елементів.
Далі почали самовдоволено підводити до ідеї про виключення «зайвого» хламу із ДОМу. Я тіпо як погодився, але зауважив, що якщо вони пропонують оперувати одразу масивами HTMLElement’ів, які випадають з поля зору (а мені здалося, що так), то за їх потенційної розмірності, та ще якщо апендити взад-вперед у підконтрольний фреймворку контейнер, зрештою, все одно може вийти глючне казна-що.
Здається, якось на тому і розійшлися.

Згодом я трохи потикав, здебільшого, щоб для себе переконатися, how much is «much». Паралельно з тим укріпився в думці про те, що уж чим, а ДОМ елементами я б туди-сюди точно не став перекидатися. Відрендерити сітку під розмірність екрану та підвантажувати контент із невеликим запасом вліво-вправо, щоб хоч при плавному скролі не було затримок із рендером — так, в самий раз. Використати кастомний скрол — також так, хоча б через те, що у браузерному при такій розмірності повзунок став би лень видимим, та й підганяти/розраховувати розмір блоку-заглушки суто для того, щоб отримати натівний скрол з усіма його недоліками (для цього кейсу) — те ще задоволення.

Але, як бачу з наданого вам фідбеку, добре, що і не брався, щонайменше на кастомному скролі зафукали б )

P.S. Мені такі інтерв’ю чомусь нагадують анекдот про Вовочку:

— Мама, мама, а мы сегодна плавать ходили!
— Хорошо, сынок!
— А меня самая большая пися в третьем классе!
— А это, сынок, наверное, потому, что тебе уже 17 лет!

P.P.S. А, так, ще був «дзвіночок» до тех. співбесіди. Проскакувало щось про «ТАКІ гроші» та «додаткову лідську відповідальність».
Гроші я запросив не те щоб прям ТАКІ, тим паче, що мова про прямого замовника під продукт, а не про галєру, для яких в наших реаліях мій рейт загалом цілком підйомний, хоч їм і треба при цьому ще й собі відгризать якусь маржу.
Висновок? До «дзвіночків», все ж таки, треба дослухатися.

У меня тоже был звоночек, — при собеседовании они упоминали, что такого рода задачу их разработчики не смогли решить для АнгулярЖС.
Но я и не сильно то верил в успех (вакансии), — мне казалось, что сделать эту задачу будет не сложно (но столкнулся с массой неочевидных из документации к Ву проблем) и повод для ознакомления с Ву.

Почему не юзался lodash ?!, можно было убрать много некрасивого кода

И вот прям так и было написано, с вопросительным и восклицательным знаками?

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

Просто удивило. Такие претензии сотруднику можно высказать мягче. А человеку который на тебя еще не работает можно бы и не высказывать вообще.

Сколько людей, столько и мнений и еще больше действий/реакций.

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

Полностью согласен с автором. ТЗ полная хрень. Тоже пару раз попадал на эту удочку, когда был менее опытным. Тратишь уйму времени, а на тебя просто забивают, ибо к времени, когда ты сделал ТЗ, они уже наняли другого человека, или ещё чего то произошло. Максимум, что можно делать — это прийти на собеседование с ноутом и созданным проектом (либы и все остальное подключено) и попросить человека реализовать пару классом и тестов. Причем вообще не важно будет ли оно работать, главное пообщаться с человеком и увидеть ход его мыслей. Это обычно занимает до 20 минут.
Мое мнение такое: если к тебе не стоит очередь из сотен или тысяч кандидатов — то иди ты лесом со своим тестовым заданием. Если нанимают мидоа или сениора — то чаще всего это нужно именно компании, а не разработчику. А то очень умиляет тебя уболтают пойти на собеседование, а потом начинают спрашивать почему вы хотите у нас работать и предлагают за просто так потратить кучу своего личного времени на ТЗ.
А кучу людей можно отсеивать телефонным звонком минут на 10-15. Идиотов или просто людей которые сильно не тянут на вакансию отметить так очень легко. А преглашать в офис уже после короткого общения.

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

От досі не в’їду питання, чого ви хочете у нас працювати. Та робота мені потрібна, нічого я не знаю про ваш компанію, шоб хотіти до вас. І тут не важливо чи тебе запросили чи там знайшов вакансію. І навіть досвідчені HR умудряються його задавати.

Этот вопрос пришел из компаний с корпоративной лестницей. Корпоративная лестница очень жесткая штука, но в теории позволяет достичь позиций исходя из результативности. Правильно этот вопрос звучит «вы понимаете куда пришли?», но задать его в лоб нетактично. Для не корпоративного сектора этот вопрос не применим, но кто у нас учит айчаров?

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

Несколько сотен резюме на одну вакансию, специалиста уровня мидл+
Каждое интервью — это минус по два часа рабочего времени для двух лидов.

Допустим что теперь компании станут проводить интервью:
Это по минус 4 часа рабочего времени лида на соискателя. В деньгах уже набегает приличная сумма даже на сотню резюме.

Вот и выходит что тестовое — один из немногих вариантов отсева немотивированных соискателей без затрат со стороны компании.

Такое наивное мнение :) почти любая компания готова бонусы по 1-3к в добавок давать за любой найм. Все окупится с первой, максимум со второй (если компания совсем нафакапила), зп нанятого

тестовое — один из немногих вариантов отсева немотивированных соискателей без затрат со стороны компании

Ну зовсім безпалівний такий тоненький натяк на те, що ніхто ті тестові навіть і не дивиться )

Чи мова про автовідсів тих, хто взагалі не стане робити? Хай навійть й так. Але не в мотивації ж річ, а в тому, хто кому більше потрібен. І тут в дію вступає закон бутерброда, хай йому ґрець: найняти хочуть ооось того чувака, який непогано себе почуває на галєрі через дорогу, а на кляті об’ємні тестові набігають часто-густо самі лузери, які в силу якихось причин на час пошуку ВЖЕ сидять без роботи та як наслідок, мають забагато вільного часу; і тих потім ХРюша зрізає питаннями накшталт, — «ой, а що це у вас за пробіли в CV?», «а чому звалили з попереднього місця, не знайшовши нове?» і т.д.

С затратами со стороны соискателей.

написать аналог класса std::vector.
...
Парень, что код смотрел только уточнил, почему VC6.0 я юзал. Я объяснил.

т.е. даже .emplace(...) надо понимать реализовать не получилось а ну ок ))

Я же ж так тебе прямо и сказал все эти «нписать аналог класса из STL» это всё туфта полная именно в такой постановке задачи вот открываем всё тот же ж std::vector современной его реализации... смотри ка! а ведь там уже лёгким движением руки (к) (тм) уже минимум 2 (два) класса это сам vector а к нему ещё и #внезапно allocator но это только начало истории потому как вдруг оказывается что там ещё и iterator и reverse_iterator и надо понимать что к ним ещё и const их версии что бы б они ни обозначали но давай посчитаем хотя бы б по методам...

... считаем... да... и если начать с конструктора то в 11-й версии их уже 9 (девять) штук разных вариантов одних только конструкторов итого сколько там на самом деле всех остальных функций членов включая все их модификации считать?

Итого все время у меня заняло 1.5 часа беседы и 1.5 часа на код вечером.

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

Потому что «тестовое задание написать аналог класса из STL» (к) (тм) прямо свидетельствует об том что задающий крайне слабо понимает себе а) суть тестового б) зачем оно вообще в) реальный объём того что он спрашивает г) и далее уже пошли слествия в виде того что точно так же ж он с вероятностью 146% «понимает» и сам проект и всю остальную работу.

Хорошо это или плохо уже другой вопрос и как с этим жить тоже но вот конкретный фактор служит конкретным показателем как факт.

ЗЫ: более интересным вариантом «вопроса ответа тестового задания» было бы б «написать класс аналог из STL» (к) (тм) только при этом прямо спросить «как оцениваешь сложность? сколько у тебя уйдёт? сможешь определить объём некоего MVP который ты по этому заданию готов уложить в рамки тестового?» и вот тогда когда человек _реально_ оценивает сколько он _реально_ может сделать за 1,5-2 часа и насколько это _реально_ покрывает то «оригинальную постановку задания» вот тогда «можно и поговорить» а если человек вдруг соглашается за полтора часа «написать класс аналог из STL» (к) (тм) ... то это реально стрёмно хотя и да реально суровая реальность ))

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

Они хотели посмотреть, как я пишу на С++ и не более.

могли бы б и винду предложить написать или там какой-нибудь фейсбук на худой конец ))

пришлось работать с кодом, где Скотт Майерс лично руку приложил.

а ну тогда конечно ок ))

)) что ты имеешь в виду «работать в продуктовых конторах»? вот... ну я не знаю... фхтагн как там его — это «продуктовая» или «аутсорс»? чем они по-твоему отличаются?

Вот скажем «продуктовая» как проходит мой средний рабочий день с утра проснулся сделал всё то что не относится по работе и примерно вовремя вышел с дома благо мне пешком даже удобно и спокойно дотопал до офиса где прошёл систему контроля пропуска и зашёл на своё место в опенспейсе правда «кубиками» вещи бросил и пошёл на кухню сварить кофе хотя тут по разному бывает сразу с утра почту почитал а бывает что прямо перед выходом в офис чтобы по дороге подумать (а ещё я диктофон использую чтобы надиктовывать прямо на ходу записьки и не забывать по приходу) кофе попил пока попил народ подсобрался уже и какой-нибудь стендап нарисовывается стали все выступили и разошлись по местам покодить и так до обеда в обед встали пошли в столовку покушали организованно из столовки организованно разошлись я обычно трачу время на чтобы прогулять пешком коллеги шпилятся в настенный футбол либо бывает разъезжаются по делам дети там всякие и что-то такое семейное после обеда обратно все сошлись ещё немного успели покодить и провести пару митингов разной степени полезности периодически ещё отвечать на электронную почту а в последних 2-3 года к ней ещё и активно добавились «непочтовые сервисы» вечером расходиться начинают с 4-х по местному времени к 6 вечера офис уже практически 100% пустой кстати очень удобное время на реально поработать дорога домой занимает ровно то же ж время ровно тем же ж пешком с другой стороны рядом с офисом есть супермаркет но обычно туда удобно заезжать на машине а с парковками в офисе бывают вопросы так что лучше сделать это отдельно в нерабочий день.

И так день за днём напиши мне пож. в каком именно месте по твоему мнению в этих днях «продуктовая» отличается от «аутсорс»?

ЗЫ: видимо половина наёмной рабсилы класса «гребец программист обыкновенный» в штатах «сдана по найму» т.е. «нанимает» какой-то там Шива Сан где-нибудь в Джерси у него кабинет в котором ты никогда и не был а офис компании уже работы где-нибудь в Огайо и сидишь ты непосредственно там и хотя как бы б прямо к делу это не относиться но вот как там понять и провести черту «продукт аутсорс» уже совсем непонятно.

ваша Галя балована )) я предпочитал всегда наличные (здесь в противовес акциям и прочим «обещаниям светлого будущего»).

я так не могу мне интересно деньги ((

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

1. Не нужно давать реализовывать мини проект. На это тратится кучу времени и полный скилл не покажешь.

2. Понравилась практика у западных коллег по цеху, когда тебе даётся ссылочка на хаккер ранк и ты в любой день в течении часа выполняешь. И тут 2 варианта:
а) алгоритмы, если ты просто на SE идёшь
б) 5-8 заданий. 4 тестовых на выбор варианта, 1-2 с открытой частью (Например, описать чем процесс от потока отличается, один класс библиотеки от другого или любой углублённый вопрос по вашей специальности) и 1-2 задания дописать класс, код, алго, рефакторинг, паттерн, тест на использование какой-либо технологии и т.д. и т.п.

Как итог: кандидат тратит не более 1 часа. А вы отфильтровываете людей.

Как итог: кандидат тратит не более 1 часа. А вы отфильтровываете людей.

Это работает на специфических рынках т.н. «рынок самозванцев» (к) (тм) где каждый из 100500 «условных индусов» (к) (тм) пишет в своём резюме условный стек из 100500 условных технологий и «локальному рекрутеру» на всё радостно и уверенно отвечает «да господина!» (к) (тм) даже если при этом он и не индус ))

ЗЫ: это кстати реальность американского рынка насчёт европейских не скажу.

Например, описать чем процесс от потока отличается

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

ЗЫ: кстати дельфи оказывается весьма популярен на нём написаны тонны какого-то легаси которое теперь ни выбросить ни переписать ну просто потому что изначально платформа расчитана на... ))

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

Главный вопрос. Что такое качественный код? Все о нем всегда говорят, но никто его в живую никогда не видел. Все прямо из области веры и религии. «Качественный код» — это такая жуткая субъективщина из-за которой сломаны уже тысячи копий и загублены сотни душ. Даю живой пример. Есть бизнесмен, у которого в подчинении работает два профессиональных специалиста. Между ними при разработке проекта назрел конфликт. Один доказывает, что нужно проект делать так, а другой свою версию выдает. Босс решает одного из них уволить, так как по другому руководство решать проблемы не умеет. Внимание вопрос, как босс будет проводить анализ, кто прав, а кто нет, кого он в итоге уволит? Даю сразу ответ, оставит не того, кто прав (хотя это выяснить невозможно в силу того, что задачи в ИТ успешно решаются разными способами), а того, кому больше доверяет (еще одна тупая субъективщина, основанная на химических процессах в голове).

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

Многие не могут понять, что сам код, да и программирование в целом — это не ЦЕЛЬ!!!, а средство достижения определенной цели. А спроси у любого прогера, что это за цели, так большинство будут глаза пучить и искренне не понимать, почему цель не написание кода или даже самого проекта. Из-за этого и рождается миллион статей о собеседованиях, о тестовых заданиях и т.д. Так как в корне проблемы лежит непонимание того, что программист — это всего лишь маленький винтик большого механизма, который является всего-навсего объектом бизнеса/процесса, а не его субъектом. А винтики принято менять, при чем совсем с ними не считаясь. Но чрезмерно раздутое ЧСВ многих отечественных программистов не дает им возможность посмотреть на себя со стороны и честно самому себе ответить, что он, как самостоятельная единица на фиг никому не нужен, так как таких, как он, до фига и больше в глазах бизнеса. И только единицы могут в одно лицо создать серьезные проекты, сами их профинансировать, раскрутить и начать зарабатывать.

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

А если попытаться все таки взглянуть на проблему шире, чем код/монитор и т.д. Каждый день на Доу подобные статьи пачками появляться. Почему? Они решают реальные проблемы или может они развлекательного жанра? В чем суть и смысл копошиться каждый день в одном и том же? Или всех устраивает всего один уровень развития?

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

На счет умственного развития программистов и всяких менеджеров — проработав 10 лет со всякими менеджерами и зная порядка 20-30 разных айтишников, могу сказать что ты сильно заблуждаешься. Как и многие которые работают в айти — вы даже не представляете какой трэш творится даже в крупных компаниях, люди просто не работают.

это такая жуткая субъективщина

Нет, вполне себе объективщина.

Раніше мені здавалося, що тестове це хороша ідея, але потім одразу 3 ситуації підряд змінили мою думку — для кандидата це часто просто марна трата часу. Одна контора шукала собі автоматизатора, сказали що співбесілда, лише після тестового. Сказали, що тести можна на будь-чому. Витративши кілька годин свого часу на тестове, потім на співбесіді почула, що для роботи потрібні інструменти з якими я ніколи не працювала (і в резюме це вказано, і тестове виконане з іншими фреймворками), і у вакансії не пише точних інструментів. Одним словом їм взагалі потрібна інша людина і це можна було зрозуміти з 15 хвилинної співбесіди і зберегти кілька годин мого вихідного дня.

Потім одразу ж після них ще одна компанія попросила тестове — теж потратила кілька годин життя, а потім мені написали що співбесіди не буде, бо вони вирішили закрити вакансію внутрішнім ресурсом. Ви, курва, не могли про це подумати може чуть раніше?

Останньою каплею в морі була компанія котра просила протестити один АПІ, написати тест кейси. Це буквально 1-2 години роботи на все про все, і ми навіть далі просунулися до співбесід з замовником, а далі вони просто пропали на 2 місяці і об’явилися знову. Сказали шо так вийшло що всі раптово пішли якось у відпустки і навіть не було мені кому написати листа і відповісти, давайте спочатку почнемо наші спібесіди, просто щоб освіжити пам’ять. Я погодилася (дуже цікавий був проект), а вони знову пропали:)

Одним словом, зачасту кандидат витрачає свій час на речі, котрі нікому не потрібні в результаті. Тестове завдання непоганий інструмент але тільки в руках професіоналів, котрі спочатку говорять з людиною, розуміють її потреби і свої потреби (для цього треба насправді 10 хвилин часу, потім, після тестового можна продовжити), а потім вже дивляться на практичні навики., і завдання відображає реальну потребу проекту. Правда, тестове завдання прямо в офісі під час співбесіди, як пропонує автор, як на мене найгріший варіант — люди часто занадто переживають на співбесіді, додає невпевненості і те, що ти ніби трохи «нижчий» за статусом, від тих, хто співбесідує (особливо на початку кар’єри) і ти почуваєшся, як на екзамені.

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

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

Конечно кто-то больше кто-то меньше, но судить об этом по интернету довольно необъективно.

Я вообще тоже против аналогий, я лишь хочу сказать что никто не будет хвастаться что ему дали хорошее ДЗ. Вот жаловаться — это пожалуйста. Все время так: хорошие отзывы — 20%, плохие — 80.

Ну обсуждаем мы конкретно вот этот случай, и я бы не хотел обобщать на весь топик. В конкретно этом случае претензия не к ДЗ, а к HR/Менеджменту.

Ну, в конкретно этих трех случаях менеджмент поступил плохо независимо от того было ли ДЗ или нет.
Про плохую квалификацию HR в большинстве компаний легенды ходят от доу до ***го айти.
Так что из этих двух стульев я выбираю плохой менеджмент :)

Так, тестове завдання це лише інструмент, як і багато інших. Просто не всі вміють ним користуватися і не розуміють до кінця наслідки такого невмілого користування. Я просто більше не хочу випробовувати роботодавців, типу, може цей хоч вміє правильно будувати процес, бо ж ніхто час мені не поверне. Тому в майбутньому я просто буду наполягати на невеликій співбесіді до тестового, якшо тестове буде обов’язковим. Якшо будуть відмовляти то і я буду відмовлятися.

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

Поддерживаю автора: тестовые задания — зло. Во всём, кроме одного случая. Допустим, к тебе на работу хочет человек без опыта. Не важно, вообще или в технологии, что тебе нужна. Оплачивать ему обучение, чтобы он две недели почитал книжку и сказал:"мне не интересно"? Нет, сэр. Прочти книжку в свободное время и сделай тестовый проект, покажи что ты можешь. Зачем? Но это же ты хочешь у меня работать!

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

Складывается впечатление что автор против ДЗ потому что потом сталкивается с трудностями найти человека который бы качественно проверил результат и дал качественный фидбэк. Любишь задания давать — люби и проверять!

Ніколи не забуду тестове завдання на ABTO. Видали мені на листочку чи то 6 чи то 8 задач, які треба було вирішити на листку, здається за 1,5 год. Задачі для мене виглядали скоріше як задачі з прикладної математики або щось в тому дусі (при тому у вакансії не було й натяку про те, що на даній позиції мене може чекати щось подібне). Але прочитавши умови стало зрозуміло, що загалом все можна вирішити, якщо трохи піднапрягти мозок і зосередитись на їх вирішенням. Проте з останнім виникли проблеми — розмістили мене для виконання тестового завдання на кухні... В обідіній час, коли поруч розмовляли працівники, розігрівалась їжа в мікрохивльовці, кипів чайник ну і так далі. Очевидно зробити всі задачі в мене не вийшло — здав листок із 80% виконаних завдань. Після того мені так і не передзвонювали — і слава богу.

Жодно разу ще виконання (ідеально чи так собі) тестового завдання не принесло мені офер. Саме тому, останнім часом, позиції з тестовим завданням розглядаю в останню чергу

а мені 3 рази з 5-х принесли офер. До того ж тестове завдання — це особистий челендж, та підвищення кваліфікації. Так що я ніколи не відмовляюсь.

Еще ни разу успешное выполнение мной тестового ДЗ не принесло компании нового специалиста в лице меня.

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

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

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

Если предельно упростить — программиста нанимают чтобы он писал код.

Программиста нанимают, чтобы решать поставленные задачи.

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

Можно совершить зеркальную ошибку — нанять человека с синдромом «горе от ума», который прекрасно пройдёт тестовые задания, но на реальной задаче он будет как якорь вместе с парашутом у автомобиля.

Ну вот кого нанимаете, то вам и пишут

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

В-общем, если хотите нанимать хороших специалистов, ТЗ это маст.
Rule of thumb — 1-3 часа, только онлайн.

Не траплялося ще жодного позитивного досвіду ТЗ, якщо ми саме про ТЗ, а не про задачі пів години — годину.

1. Одна задрипана місцева контора в яку відправив резюме, бо з двома роками досвіду (на трьох різних роботах) в кризу не сильно то й брали кудись. ТЗ було доволі простим, юнаківським, на базовому рівні алгоритмів та STL. — Не взяли. Сказали, що в мене там меморі ліки. Наскільки я розумію, хто перевіряв просто не в темі був, що таке розумні вказівники, побачив new, не побачив delete і виніс свій вердикт. Потім було соромно, що я взагалі в таке місце резюме відправляв.

2. Десь в той же період після напруженої двогодинної співбесіди, де, начебто, мною були в цілому задоволені, бо говорили ми доволі довго й гаряче, отримав задання для розв’язання в їх офісі, на кілька годин. Щось там типу вибрати, переслати й програти файл. Нічого складного, але треба розбиратись, бо з мультимедієй на вінді я тоді стикався, але дотично. З нічного потягу Київ—Харків, після напруженої співбесіди і обіду я сів за комп’ютер в їх офісі і зрозумів, що вже висотаний як лимон і вже нічого більше сьогодні не зроблю. Взагалі, мені пропонували робити завдання на наступний день, але я не хотів залишатися ночувати і вирішив робити одразу. Люди ці були розчаровані, я теж. Чудовий приклад lose-lose.

З того часу ніякі ТЗ я не брав. Коли траплялося, я пропонував рекрутерам «перетелефонувати пізніше» й залишав вакансії з ТЗ наостанок. І якось так траплялося, що до них вже справа не доходила.

В одном из похожих топиков я описал свой недавний, субъективно положительный опыт с ТЗ:

Самое адекватное ТЗ, которое мне предлагалось сделать, было у одной довольно известной компании в Лондоне. Тебе дают один файл с одним классом на ~200 строк кода, который читает и пишет в CSV файл. Задача — написать для него код ревью и отрефакторить код. В этом классе нарушена практически каждая буква из SOLID, есть проблемы с CQS в интерфейсе, код не DRY и отсутствует какая бы то ни была обработка ошибок и покрытие тестами. Задание делается за полдня, но при этом дает возможность продемонстрировать теоретические знания через код ревью, которое ты напишешь и практические навыки написания надежного ООП кода.
Вот такое тестовое мне было приятно сделать и получить адекватный фидбек от людей с 20+ лет опыта в индустрии.
А за задания в стиле «а ну, замути нам iOS приложение на 2 экрана, которое будет скачивать картинки из твиттера и показывать в табличке» я сразу шлю на йух.

После ТЗ было onsite интервью, на котором непосредственно обсуждались проведенные мной код ревью и рефакторинги. Потом говорили про тестирование, лучшие практики, архитектуры и системный дизайн в общем и про применение оных на моих проектах в частности. Никаких фреймворков, библиотек или внутренностей языков программирования не спрашивали, кроме тех случаев, когда я сам считал важным подчеркнуть знание какой-то специфики в рамках рассказа о своих проектах.
В общем и целом, я считаю, что имел возможность всесторонне продемонстрировать свои компетенции и опыт, а компания — их оценить.
Сработает ли такой же подход с другими кандидадами и украинскими компаниями — думаю, 50 на 50.

Ради этого даже зашел на доу. Всплыли воспоминания, октябрь 2016, очередная «молодая и перспективная» позвала на собеседование. Приехал к ним в офис, полтавский шлях 4 (Харьков если что), здание СпецВузАвтоматики, подымаюсь на третий этаж. Чтобы вы понимали всю комичность ситуации, один кабинет, в нем один светильник, 3 самых дешевых офисных стола и 3 человек за ними со своими ноутбуками, все это гордо именуется IT-компания. Время уже за 20+. Говорим по поводу работы, ну как всегда, чем занимался, какие технологии.Потом мне говорят: «будешь делать тестовое?», ответный вопрос: «сейчас?», мне говорят: «ну да», и в голове мысли — а за что бороться? где цель ? ради чего? — ради того чтобы работать с 9 утра и до 21 вечера и при этом 3 мудака будут мне рассказывать что я им еще спасибо говорить должен,мол с улицы забрали ? сказал твердое НЕТ, обосновывая тем что уже поздно и я устал, на что услышал «нам такие не нужны». Закрывая дверь сказал на прощение : «пока пацаны» и в ответ «и тебе удачи». Короче, господа «очередные майкрасофт», прежде чем давать тестовое задание посмотрите вокруг, а стоит ли ваша контора того, чтобы люди тратили на вас свое время.

Алекс, я не уверен что подобная эмоция правильна. Абсолютно верно — вы поступили правильно, но и «пацаны» тоже, молодая айти компания, правильно сделали что не стали покупать столы и по еплу на каждый из них а сосредоточились на работе. И вы правы — вам такое не интересно, и они правы — им нужен человек что будет работать. Либо тут что-то третье, о чем в комментарии не сказали.

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

А ещё есть психологические компенсаторные потребности и социальная леность, даже в команде с четырёх человек... особенно если у них не получается в «единорогов с радугой».

Тут надо понимать что есть сугубо психологический подтекст при публикации подобных вакансий, чаще всего связанный с отсутствием квалифицированных кадров и «грибным менеджментом».

К сожалению, такие товарищи просто не ценят ни своё ни чужое время, а экстенсивными путями все задачи не решить...

Я вам скажу по опыту нашей школы, в команде из 20 человек, специалисты чаще не лучше, но им очень мешает статус мидла увидеть и признать некомпетентность. Часто и архитекторы не лучше.

Продолжаю настаивать на своей мысли о том, что:
1. Тестовое задание уместно только ПОСЛЕ интервью и достижения предварительного согласия сторон работать друг с другом.
2. Тестовое задание тестирует только один скилл — навыки практического кодирования.

Более чем согласен с 1 пунктом. Как то находился в поисках новой работы и около двух фирм, в которые я направил резюме сразу прислали мне ТЗ, которые я естетвенно не делал. Зачем мне тратить личное время, чтоб потом на собеседовании выяснить, что эта фирма не подходит мне по тем лии иным причинам?!

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

а есть практика платных тестовых заданий?

Да, называется «испытательный срок».

Бачив як мінімум на двох канторах

Всегда требовал и давал тестовое, так можно определить подход к реализации задачи и скорость отстрела и сложности задания.

Будет тестовое задание полезно или наоборот навредит зависит от самого задания и в каких случаях оно применяется.
Мысли вслух:
Оплачивайте выполненные задания и сразу их качество возрастет.
Как правило хватает заданий на выполнение которых уходит до получаса. Знания нанотехнолой не увидите, но увидите умеет ли кандидат хотя бы читать ТЗ и задавать по нему правильные вопросы.
Задание по программированию на листике — чушь и бред.
Когда-то и сам ходил на собеседования, на которых при виде тестовых заданий работодатель посылался в лес прямым текстом. Например, когда на вакансию бекэнд девелопера дали на листике наверстать какую-то форму вместе с css...

Повністю згодна. Також писала про це в своїй статті (розділ «Какое дать тестовое задание?»)
dou.ua/...​es/tech-writer-interview

Дали тестовое задание. Почему-то захотели опеределённую БД. Пол дня провозился с установкой БД, конфигами и коннектом к ней. Дальше уже ничего не хотелось делать и оставшуюся часть сделал тяп-ляп, не взяли=)

А разве кто-то запускает и проверяет работоспособность тестовых заданий? )
Разве что если это алгоритмы какие.
Интересна объектная модель, в целом идея реализации, стиль кода.
Запускается оно или нет — без разницы, не production ready решение же требуется.

Без понятия. Но в требованиях была указана БД. Пусть бегают ищут кого-то другого)

100500% Пусть бегают....
Особенно те, кто готов вваливать деньги в поиски, вместо того чтобы взять, путь даже заведомо слабенького, кандидата и дать ему фору чтобы он вник в проект и если надо подтянулся до уровня более опытных коллег.

А разве кто-то запускает и проверяет работоспособность тестовых заданий?

Почему нет?

Запускается оно или нет — без разницы, не production ready решение же требуется.

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

Потому что лень и нафиг никому не упало.

ты не поверишь но на реальной работе у них будет та же ж история я как-то полгода «консультировал проект» в которому люди сидели и писали код который даже не запускали даже на компиляцию (ну просто потому что для этого все части нужно было сперва сложить в какую-то структуру приложения или makefile который уже можно было бы б сделать make) и только через полгода когда мне сдали нервы видеть код который даже не компилируется (окей май бэд что я не подумал и не сделал это сразу) т.е. он физически не сможет скомпилировать потому что _это_ видно уже по коду и только тогда я таки сделал тот самый makefile и запустил первую компиляцию и вычитал и вычистил все текущие ошибки и расписал всем что и как и на нескольких «митингах» «довёл до сведения» что теперь уже всё есть и давайте перед тем как коммитить таки проверять что хотя бы компилируется и ты не поверишь стало как...

... и ушло ещё около 3-х месяцев когда люди таки начали это делать )) да вот 3 (три) месяца всё равно сидели и «писали код» который даже не запускали на компиляцию.

Так что ты со своими «написать аналог stl за 21 день» (к) (тм) совершенно прав )) всё так и есть!

Ну, я смотрел только на код, приемлем он для меня или нет. Насколько ужасен. Если более ни менее, то джуна нанимали.

По опыту это очень интересная и очень сложная история если кратко то была (почему была по идее и есть ещё) одна контора которая была столь крута на рынке си++ киева что все стремились туда попасть хотя бы б даже на собеседование и у них первыми я увидел (нет меня не взяли хехехе) очень интересный подход к «тестированию на понимание задания» с «моралью» которого я стал всё чаще сталкиваться уже сейчас и если кратко то не важно насколько ужастен код джуна миддла синьора и даже архитектора но _крайне_ важно насколько он _понял_ задание а не «выдумал своё» и сделал конкретно _то_ что и было сказано в «задании» потому что вот эту задачу решить как оказалось 146% советских программистов чисто технически неспособны ))

В целом, согласен со статьей. Более того (когда есть возможность привередничать (а её нет только в кризис)), я ожидаю, что потенциальный работодатель хотя бы бегло ознакомится с моими статьями, книгами, track record’ом и блог-постами (при этом я — в контексте вакансии — заботливо отбираю для рекрутера две-три вещи из обширного множество своих трудов, и поясняю, какое отношение они имеют к тому или иному требованию в вакансии).
Если работодатель интереса к этим вещам не проявляет — значит, это конвейер (и вполне вероятно, что ищут не лучшего, а самого дешевого).

Да, когда в Германии (заново) начинал карьеру, то тестовое задание-таки делал. Но это было на весь день, в офисе фирмы, и по закону они должны были бы мне этот рабочий день оплатить, даже если бы не взяли на работу. Конкретно, имплементировал преобразование Бокса-Мюллера, делающее из равномерно распределенных случайных величин нормально распределенные величины, и тестировал насколько на этой задаче плюсы быстрее явы... эх, молодость! :)

А еще недавно делал (т.к. самому было интересно) — решить одну алгоритмическую задачку с использованием тех методов, что недавно были добавлены STL’ый map. Но там, сцуко, еще ограничение по времени было — а как говаривал академик Петровский — я тугодум, одинаково медленно решаю задачи любой сложности (и потому берусь за самые трудные). В общем, время вышло, но я прислал им математическую схему решения и сказал, что готов дописать и дослать и код, если им это интересно. Но им это было неинтересно.

Можно, но не нужно, коль скоро Бокс-Мюллер дает точно то, что надо.
(ну разве что он относительно медленный — но и это уже тогда не было проблемой — ибо линейно параллелится).
А так симуляции-расчеты разные бывают, так что лучше быть уверенным, что метод не даст тебе какой-нибудь систематической ошибки и/или недостаточной точности.
В книге Марчука по численным методам описан реальный случай, как проверяли одну модель на точность, а в тесте было PI = 3.14; вот и тест и не проходился.

Мне кажется автор слишком категоричен. ДЗ не серебряная пуля, а инструмент.
Порой — весьма полезный.
Небольшое тестовое задание (на 2-3 часа), в котором просят реализовать алгоритм очень экономит время.
Оно позволяет четко понять ряд проф. моментов, на основании которых можно более конкретно разговаривать с человеком. И ничего там нет механического, надо просто потратить время на составление ДЗ, чтобы это было не «сделать CRUD сервис» а что-то типа задачи с CodeWars

2-3 часа у скольки человек, у 10? И какой осадок останется у 9 человек, которые тоже выдадут рабочее решение?

Не понял Ваш вопрос. Объясните будьте так добры.

Візьмуть одного, дев’ять — марно витратять час, та продовжать пошук, знову ж таки натикаючись на «ефективних наймачів», яким 2-3 години чужого життя нічого не варті.

Люди потратят зря время только в том случае, если не получат обратной связи по своему ДЗ. На каком основании Вы решили, что все так делают, я ума не приложу.
Видимо Вы слишком много дел имеете с недостойными людьми.

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

яким 2-3 години чужого життя нічого не варті.

ничем не обоснованны.

А если эти 10 человек хорошо напишут задание, наймут ли их всех при условии, если вакансия всего одна? Так или иначе, вне зависимости от успешности, 9 из 10 зря потратят время. И не 1 раз, а раза 3-4, если то же самое повторится на других собеседованиях. Благо, не повторится, и 9 из 10 быстрее примут офер без ТЗ, а на доказательство профпригодности есть испытательный срок (а также github, портфолио, отзывы, у кого что есть, да и просто банальное проявление адекватности и здравого смысла в ответах на технические вопросы).

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

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

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

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

День активного планирования и организации? Скорее всего кандидат будет заниматься заданием после работы или на выходных, достаточно ткнуть в день когда вечер или выходной день не заняты, откуда день планирования? Интернет у 99% людей есть дома

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

Ну ок, человек расставляет приоритеты и выбирает удобное для него время в соответствии с этими приоритетами. Понятно что придётся оторваться от пива и потратить время на тз/собеседование/подготовку, мой поинт в том, что планирование этого куска времени не займёт целый день

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

Так или иначе, но тут трата времени и внимание с обоих сторон

Одной стороне трата времени компенсируется зарплатой, а другая семью тестовыми заданиями накормит

Смотрите, я кажется начинаю понимать о чем Вы.
Тут есть много вариантов:
1) Платные. Вариант хороший, может быть скоро внедрим.
2) По сейчас — человек, который выполнит задание, с ним поговорят и подойдет по деньгам, ему морочить голову не будут. Мы же не в Amazon и Google.

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

Как быть с остальными пишущими ТЗ? Или вы прям по одному человеку отбираете, даете задание и ждете результата пройдет/не пройдет? Это очень круто если так можно, но по-моему часто делают не так — ведут переговоры одновременно с несколькими кандидатами и потом выбирают.

Люди потратят зря время только в том случае, если не получат обратной связи по своему ДЗ

По-перше, якщо мова йде не про найм джунів, то ви, можливо, переоцінюєте важливість вашого фідбеку для кандидатів.
По-друге, чим коротше завдання, тим статистично менша відмінність між кожною із десяти імплементацій. Як саме, без лицемірства та бла-бла-бла, і щоб при цьому фідбек був ще й змістовним та корисним, відшити 9 із 10 кандидатів із практично однаковими тестовими?

«Ладно, он не совсем плотник, он продавец машин. Однако он продал много коричневых машин и работал с отделкой из орехового дерева.» ©

відшити 9 із 10 кандидатів

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

По-перше, якщо мова не про найм джунів, то ви, мижливо, переоцінюєте важливість вашого фідбеку для кандидатів.

Возможно. В моем проф. уровне дыр также хватает.

9 із 10 кандидатів із практично однаковими тестовими?

Ну если Вы не тратите время на подготовку ДЗ, то и получите стандартные варианты.
Выделите время на подготовку задания и Вы не будете получить одинаковое.
Полно заданий из алгоритмики.
Чтобы понять о чем я говорю, сходите на CodeWars,
возьмите задачи и Вы сильно увидитесь, для тех, что требуют 2-3 часа вариантов решений немало и они сильно отличаются.

зачем мне говорить со столькими людьми

Диверсифікація? А якщо ви кандидату зрештою виявитеся нецікавими? А якщо кандидат просто бродить по ринку, збираючи контр-оффери? Та й більшість зможе виділити три години не раніше вечору найближчої п’ятниці. При всьому цьому, не занадто ризиково опрацьовувати кандидатів в однопотоковому режимі?
Тобто, я розумію, що це як раз по-людськи, але в єдинорогів та рожевих фей якось давно не вірю.

Если человек выполнил ДЗ, с ним нормально поговорили

Чи у вас тестове ДО співбесіди? )

Полно заданий из алгоритмики.

Повно, так. Але це взагалі тема окремої розмови, — що саме тими завданнями насправді перевіряється, та куди присунуть ту «алгоритмику», коли 95% проектів — люте формошльопство.

Люди потратят зря время только в том случае, если не получат обратной связи по своему ДЗ.

Согласен!

2-3 години чужого життя нічого не варті
На каком основании Вы решили, что все так делают , я ума не приложу.

Адресовалось это утверждение не мне...
Но я, c Вашего позволения, вставлю свои 5 копеек — на основании личного 5 летнего опыта общения с HR... Ни одного технического фидбека по ДЗ или хотя бы ссылки на решение которое, победило в призрачном конкурсе (я бы уж как-то и сам проанализировал свои ошибки)!

Видимо Вы слишком много дел имеете с недостойными людьми.

Видимо... да.
Кому-то не повезло...
Но это и со мной тоже происходит!
Видимо этих, как Вы сказали «недостойных» людей ооочень много.... , а меня ооочень мало и лично я давно перестал верить в чудеса.

Це ви ніколи не були на стороні наймача. Зараз на вакансію інтерна приходить сотня резюме. Ми їх фізично не можемо всіх запросити на співбесіду, та це й неефективно. Тому даємо тестове завдання і по ньому вже вирішуємо, кого запросити, а кого ні.

Мне даже страшно такое представить. Но тут есть очень важный момент, кто принимает решение? Я принципиально не против ДЗ, но если после этого выбирает PM, то я бы сразу отказался бы от этой непреятной мисии. Мне кажется, проверять, подходит ли кандидат по «гороскопу» нужно до ДЗ. А ДЗ должно быть с подготовленными тестами и с ссылкою на победившее ДЗ.

подходит ли кандидат по «гороскопу»

16-17 лет назад собственник одного интернет-провайдера согласовал меня на первый мой проект, после того как уточнил дату рождения и что-то долго смотрел в Зодиакальном круге. Во время было )

чётки при этом перебирал? если без чёток то норм ))

По крайне мере в жертву разработчиков не приносил в случае затягивания эстимейтов )

Если у человека есть эти 2-3 часа для каждого, кто откликнулся на его резюме.

но он ведь хочет получить честь работать в нашей компании? ))

Я помню первое ДЗ — сделать почтовый сервер. Меня взяли и первой же задачей было перевести сервер в прод.

Я надеюсь, ты просто сконфигурировал sendmail? Или какой-то простой почтовик?

Постфикс, довекот и белку
Плюс плагины

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

человек пытается сделать реальные задания

погано масштабується

Це погано працює у малій компанії, де намагаються найняти багато людей одразу.

А так дуже добре масштабується. Ось тільки процес в інтерв’ю не має відрізнятися від звичайного.

Підписатись на коментарі