Проблемы объёмных тестовых заданий при выборе работы

    Глядя в историю выполнения мной тестовых заданий, видятся закономерности, о которых хотелось бы предупредить коллег, потому что такие случаи встречаются регулярно и, скорее всего, независимо от специализации разработок. Например, к таким выводам я пришёл, имея на счету более десятка выполненных в разные годы заданий объёмом 2-5 рабочих дней каждое. А выводы — настолько парадоксальные, что, думаю, вызовут споры и удивление у тех, кто этого не прошёл. Сформулирую основной вывод для начала, а затем покажу обоснования на примерах из практики.

    Вывод: (софизм) тестовое задание объёмом более дня с основной целью (поступления на работу) выполнять невыгодно.

    На рынке вакансий иногда (5-10% случаев) бывают предложения от компаний сделать «домашнее» тестовое задание. Обычно оно занимает не менее нескольких часов: простые задания стараются не давать. Оказывается, большое значение имеет для соискателя, когда, в какой фазе общения это задание предлагают и какого оно объёма. Далеко не всегда означает, что задание разумно или выгодно выполнять. Очень часто задания содержат недоработки в постановке, а их выполнение оказывается менее выгодным, чем стратегия неотрывного поиска работы среди компаний, которые не предлагают тестов или предлагают менее сложные и более быстрые тесты (например, непосредственно на собеседовании или по Скайпу в онлайне).

    В процессе нескольких лет работы на веб-фронтенде периодически встречались задания, которые не всегда было выгодно выполнять. Даже скажу так: ни одного случая найма с тестовым заданием не было успешным ни для какой стороны — ни для меня, ни для работодателя. В то же время, приём на работу, построенный на несколько иных принципах, был успешен. Итого, в выполнении заданий я привык видеть не те цели, которые, по идее в них видит другая сторона, работодатель. По сути, они не выполняют своей основной функции. Основная функция заданий (объёмом 8 часов и более) в большинстве случаев не работает.

    1) не гарантируют оправдания потраченного времени даже в случае безошибочного выполнения;
    2) создают непропорционально большие усилия по пути к данной вакансии;
    3) возможны проявления безответственности с позиции работодателя: неинформирование от HR о результатах теста.

    И поскольку число вакансий с заданиями — не более 10% от общего числа, имеет смысл даже стратегия невыполнения их! Однако, я к этому не призываю: иногда задания выполнять стоит из «любви к искусству», но при этом (парадокс!) можно не рассчитывать на успешный приём, т.е. делать их следует не ради приёма на работу.

    Расшифровка софизма


    Посмотрим на пару таких красивых примеров, которые выполнялись в разные годы и уже с пониманием этого парадокса. Т.е. я выполнял эти конкретные задания уже не для приёма на работу, а со 2-й или 3-й целями: для создания портфолио себе и для написания полезных для себя утилит. Почему опыт выполнения заданий привёл к таким выводам — поговорим в процессе рассмотрения.

    Опыт ограничивается сферой разработок для Javascript/CSS/HTML, но думаю, что выводы будут верны и для других сфер разработки и программирования.

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

    Парадокс длинных заданий был замечен довольно давно: все вакансии, где задания были, оказывались не моими, независимо от успешности их выполнения (вернее нет, одна компания такая была, но я там на задание потратил раза в 4 больше времени, чем надо, поскольку в CSS есть понятие браузерной совместимости, и нужно много тестов для качественного результата). В итоге, думаю, не потому, что я выполнял их относительно плохо, а некто «успешный» выполнял каждый раз очередное задание «хорошо». Причины глубже — в психологии, в системе, в искусстве составлять задания.

    Где-то в 2011 году на одном из собеседований мы не сошлись с работодателем во взглядах на ставку (это уже после собеседования, во время обсуждения вопроса о размере оклада), и он в присутствии HR из сторонней организации принял неожиданное решение: сформулировать тестовое задание и оплатить его. Объём — примерно на 3 дня. Написали договор, я начал делать, даже сделал. Получился такой красивый виджет с графиками, точно по заданию и скриншоту образца. Но, как это не удивительно, и тут образовались подводные камни психологии.

    Задача — виджет с графиками



    Ссылка на демо.
    В формулировке задачи требовалась поддержка различных браузеров. А скруглённые уголки красивого виджета никак не поддерживались, как известно, браузерами IE6-8. А библиотеку PIE использовать было нельзя — она сильно нагружает движок.

    На этом и сыграл хитрый работодатель. Точнее, даже не он, а курировавший меня работник — уж не знаю, зачем лично ему нужно было превращать договор в заведомо невыгодный. Вспомнили совместимость браузеров и строчку в договоре «Виджет должен работать одинаково во всех браузерах.» Она формально означала, что для поддержки скруглённых углов у IE6-8 (2011 год, он был ещё жив!) мне нужно увеличить объем работ примерно на 40%, сделать нарезку картинок по всем скруглённым углам и сделать ещё на 2 дня заведомо черновой работы, которая уж точно никому не была нужна, только потребителю виджета (PIE использовать нельзя). Она ничего не показала бы из умений, и предполагала, что виджет будет действительно нужен заказчику, а переносить эту часть работы в штатную работу (после приёма) он не хотел.

    Вспомним момент, что окончательная сумма оффера была до сих пор неизвестна, поэтому, даже сделав бы работу, я мог не получить удовлетворительного предложения. Решение сложилось само собой. Даже пообещав доделать работу, я не мог найти оснований её доделывать. Уже через 2 дня появилось предложение о работе от крупной компании после 1 собеседования и без тестовых заданий, и на 3-й день я в ней работал. Оканчивать официально оформленное тестовое задание, теряя почти вдвое в его уровне зарплаты, не было никакого смысла. В то же время, заказчик получил бесплатно сделанную часть тестового задания и мог быть этим доволен, а я получил тестовую страницу, которую могу показывать как пример из своих работ. Пусть это — потраченное время, но по его результатам имелись:

    1) оформленная тестовая страница с 3 экземплярами виджетов и настройками параметров;
    2) опыт применения наследования DOM-объектов и шаблонизатора HTML;
    3) использование библиотеки для построения графиков;
    4) пример работы с JSON и XML в качестве входных данных.

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

    1) не заинтересовало материально на выполнение;
    2) трактовка договора заказчиком перевело его в разряд материально невыгодных;
    3) отвлекало от основной задачи — поиска и устройства на работу;
    4) выполнялось в условиях неопределённости условий последующего предложения (оффера).

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

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

    Если задания направлены на самообразование соискателя и решают полезную для разработчика задачу, то выполнить такое задание иногда можно рассматривать как «дело чести» и как путь собственного развития. Можно без колебаний выполнить задание, если позволяет время, а задание исходит из среды авторитетной организации, побеседовать с представителями которой будет полезно в любом случае. Так было в 2013-м году с mail.ru.

    Задачи — текстовые фильтры



    Ссылка на демо 1.
    Ссылка на демо 2 (подсветка слов).

    До первой встречи они прислали красиво сформулированное тестовое задание из 2 задач, время решения которых представлялось примерно на рабочий день или чуть больше. Было сразу понятно, какое могло быть её второе использование. Кроме примера своего кода для не совсем тривиальной задачи (двух), получился бы пример быстрого JS-фильтра над большими текстовыми массивами данных. Для иллюстрации скорости работы я генерировал случайный набор слов, примерно 100 тыс., а затем в нём отыскивались слова по вводимому пользователем образцу фрагмента слова. В первой задаче они подсвечивались, во второй — показывались только строки с найденными фрагментами. Из 1000 строк на экране мгновенно оставалось 5, 2 или нисколько, ноль строк.

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

    Задачи, которые неразумно выполнять



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

    Почему такие задачи неразумно выполнять? Обычно, это — задачи, которые требуют более 2 дней на решение (более 16 рабочих часов), для выполнения которых нет времени или при этом о работодателе я ничего не знаю. То есть, он даже мог не говорить о вилке зарплаты, об условиях работы, а сходу дать задание, которое часто называется «небольшим», но при этом «не на 5 минут». Уже по таким фразам можно понять что речь идёт о 2-5 днях неспешной работы. Очень часто такие задачи сопровождаются нечёткой постановкой, и можно на досуге поупражняться в поиске неопределённостей в постановке задачи. К примеру, ничего не говорится о поведении веб-формы в случае граничных условий (данных — ноль или очень много), не оговариваются условия валидации некоторых случаев заполнения форм, требуется «использовать Angular» там, где его не нужно по смыслу использовать (потому что перезагружаемая страница). В некоторых таких задачках угадывается, что задающий сам её ни разу не делал.

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

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

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

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


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

    В таких задачах огромный плюс в том, что соискатель видит, что собеседующему не всё равно, сколько он потратит времени. Собеседующий сам не будет тратить своего времени, если по ходу работы станут понятны недостаточные способности соискателя. Задачи могут решаться ускоренно, условно, или сменять одну другой. Говорят о 2-часовых подобных интервью по телефону, но у меня на практике встречалось такое 20-минутное интервью, которое затем продолжилось на очной встрече.

    Другой вариант приемлемого задания может быть, если оно предполагает трату времени порядка 2-5 часов. Может быть, с немедленным телефонным разговором по окончании. Для создания таких заданий нужно определённое искусство в выборе баланса сложности решения. Нельзя сделать задание слишком сложным. Нельзя придумать задачи с неочевидным решением — нужно даже подсказывать путь решения, потому что основная цель — проверить наличие знаний, а не потратить время соискателя. Примеры таких задач я сам старался создавать, будучи на месте работодателя, с той стороны вакансии. Что же бывает? Даже просто поставленные задания не все способны или имеют желание выполнить. И здесь есть ценз времени, которое соискатель готов потратить, и, возможно, нечётко сформулированные условия по выполнении этого задания.

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

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

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

    Only registered users can participate in poll. Log in, please.

    Какова ваша успешность (были приняты на работу) при прохождении длительных (более дня) тестовых заданий?

    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 44

      +3
      Прошу либо убрать статью из хаба «Ненормальное программирование», либо добавить в нее код
        –2
        Код есть по ссылкам, вполне нормальный и переиспользуемый, но сделан был в не вполне обычных условиях постановки задач.
          +3
          Код по ссылкам видел, но, на мой взгляд, статья сильно выбивается из тематики хаба
            +1
            Впрочем, перечитал сейчас последние статьи в хабе, возражение снимается
        +25
        Сначала работодатели неадекватными требованиями отсеивают адекватных кандидатов, а потом жалуются на тех кто к ним приходит.

        Работодатели! Если на вас слетаются мухи, а не рабочие пчелы, то это не потому что пчел нет, а потому что гм… вы не пахните как цветок.
          +2
          Абсолютно!!!
          +1
          Если разобраться, то всё все равно зависит от претендента на вакансию. В подтверждение расскажу одну историю.

          Как-то в споре по поводу тестовых заданий я дал такое решение:
          «Задайте следующие вопросы:
          — Где и как нужно задавать кодировку проекта?
          — Как производить отладку скриптов (как выполнить трассировку)?
          — Как логировать ошибки базы?
          — Как фильтровать поступающие данные?
          — Как отправлять и обрабатывать Ajax-запросы?
          — Как правильно отдавать ответ на POST-запрос?
          Если ответит на все, то не школьник. Либо очень умный школьник, которого не грех нанять.»

          Реакция на такое решение была в стиле «закидаем помидорами этого неверного», но никто достоинстве ответы не давал. Меня этот момент заинтересовал (а я очень дотошный и любопытный) и я разослал этот «тестик» своим знакомых по специальности. Некоторые меня сразу послали. Два человека дали аргументированные ответы в течении часа, большинство провозилось полдня и больше. Один целых два дня готовил ответы и, отдавая их, меня послал. То есть в ходе эксперимента выявился разброс по времени выполнения.

          Так вот, некоторые вещи знающий специалист может выполнить быстро, а незнающий долго. Если бы автор статьи когда-либо до тестового задания делал подобные вещи, то скорее всего тестовое задание у него заняло бы очень мало времени.
            +2
            Могу в личку скинуть описания реально объёмных задач из раздела «которые неразумно выполнять». Моя оценка для одной такой — 1.5 дня для челоека в теме и 5 для просто знающего. Ну так всё равно неразумно выполнять, не встречавшись ни разу с работодателем, который такое скидывает при первом знакомстве по почте: ). Требовались не общие ответы, как у Вас, а реально работающий скрипт.
              –1
              Я, если честно, не встречал заданий на 1,5 дня работы, но объёмными заданиями на полдня сталкивался (даже при помощи их устраивался на работу). И по рассказам начальника были люди, которые выполняли эти задания за 2-3 дня.

              Хотя надо поправить — тут всё зависит как и от претендента, так и от адекватности работодателя. Вспомнил, был у меня один неадекватный, который хотел сделать таблицу из иерархической базы данных.
                +2
                Как-то на вакансию разработчика Java (веб проект) мне дали задание реализовать мини приложение и там примерно 3 листа описания, про то какие EJB и как использовать, тамкже там была реализация клиентской части, ajax и тд.
                Круто конечно что они охватили все, но так или иначе от меня это потребует
                1) установки и настройки ПО (бд, сервер)
                2) создание бд
                3) написание серверного кода
                4) верстка (хоть и минимальная)
                5) js
                отладка всего этого.

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

                +3
                Первый и последний вопросы вообще не понятны. Да и остальные неоднозначны. Подразумевая веб-разработку на PHP:
                — что за кодировка имеется в виду?
                — куча способов. Что, кстати, под скриптом имеете в виду? Код на PHP? В каком окружении? Как вызывается?
                — на каком уровне?
                — куда и откуда поступающие, для кого или чего фильтровать и с какой целью?
                — сформировать тело запроса, создать колбэки, отправить. Когда вызовутся колбэки проанализировать статус и обработать полученный XML (если он получен) согласно требованиям. Что-то мне подсказівает, что такой ответ не устроит.
                — с чьей точки зрения правильно? RFC по HTTP? Какому, кстати, 1 или 1.1 — несколько логика отличается в разных ситуациях. Или вы под «правильно» имеете в виду «удобно для пользователя браузера, и пофиг что браузеры поголовно неправильно обрабатывают 301 статус ответа»?
                  –4
                  Если Вам так интересно, то ответы предполагаются в виде кода (достаточно нескольких строк) и аргументации, если нужно. Подразумевается PHP + Apache + mySql. По вопросам:
                  — Где и как нужно устанавливать кодировку (PHP + mySQL + Apache)
                  — Приведите один из способов трассировки PHP с примером настройки.
                  — Логировать ошибки базы на уровне PHP.
                  — Данные поступающие от пользователя.
                  — С Ajax и POST просто пример кода.

                  Замечу, что я просто привёл пример теста выдранного из контеста.
                    +4
                    Где и как нужно устанавливать кодировку

                    Кодировки чего? Отдаваемых страниц? Обработки данных внутри обработчиков запросов? Данных хранящихся в базе/файлах?
                    Данные поступающие от пользователя.

                    Видимо очень сильная связь с контекстом, в котором заданы правила фильтрации.
                    С Ajax и POST просто пример кода

                    C аякс ладно, если вы хотите посто убедиться что сосикатель знает как отправить запрос и обработать. А вот с пост всё равно непонятно, что значит «правильно» — за 10+ лет разработки в вебе на пхп в основном у меня толком ничего с этим не ассоциируется, не могут вспомнить какие-то особые правила их обработки. Скорее особые правила у GET и HEAD — они не должны вносить изменения в запрашиваемый ресурс.
                      –7
                      Кодировки чего? Отдаваемых страниц? Обработки данных внутри обработчиков запросов? Данных хранящихся в базе/файлах?
                      Кодировки всего перечисленного. Я в скобочках всё перечислил — думал, что Вы поймёте.
                      за 10+ лет разработки в вебе на пхп в основном у меня толком ничего с этим не ассоциируется, не могут вспомнить какие-то особые правила их обработки
                      Это вопрос на вшивость. Не знаю как Вы, но я до сих пор встречаю людей использующих «профессиональную» вставку или десятки echo.

                      И пожалуйста, старайтесь использовать знаки препинания — по три раза перечитывать ваши комментарии нужно, чтобы понять. Без обид.
                        +1
                        Про POST я ожидал каких-то особенностей HTTP, может коды ответов, кэширование… а вы про echo. Что ещё за «профессиональная» вставка или десятки echo?
                          0
                          «Профессиональная» вставка — это когда html-код смешивается с php-кодом. В незапамятные времена это было признаком профессионализма, но как показала практика этот способ очень неудобен для разбора кода. Некоторые новички для обучения используют древние книги, где сохранились эти предрасудки.

                          С echo всё проще. Эта команда выводит строку. Если точнее сказать, то добавляет её в ответный пакет. Эта процедура хоть и быстрая, но неоптимизируемая (т.е. опкэшер её скорость не увеличит). Отсюда логично следует вывод, что желательно использовать echo как можно меньше в коде (в принципе достаточно одного раза). Новички же, которые ни разу не делали трассировку и не понимают принципов работы опкэшера, этой особенностью пренебрегают и их код состоит из десятков/сотен echo.
                            0
                            Хм, а как одним разом обойтись? Подозреваю, вы скажете про буфер вывода… ладно, но как это с POST связано? По моему, вас неспроста посылали))
                              0
                              C POST это связано посложнее. При работе с FullAjax, если передавать многострочные команды, то JS будет их обрабатывать построчно (имеется в виду выполнение будет происходить с перерывами).
                        0
                        Про кодировку же можно в общем ответить: как её установить на клиенте, как на сервере и, самое главное, зачем и почему её нужно там устанавливать. Другие вопросы тоже, на мой взгляд, простые. Даже для меня, хотя веб-разработка была в моей жизни достаточно давно.
                  +3
                  Для себя решил, что тестовые задания должны быть либо короткие (15 минут), либо интересные.
                  Однажды взял тестовое задание на пару дней, но с условием, что мне отпишут что сделано хорошо и что сделано плохо. На работу меня не взяли, но я остался очень доволен, т.к. разобрался с интересными стандартами и получил очень качественный feedback.
                    +3
                    Задание на пять рабочих дней – это самая настоящая работа, она должна оплачиваться. (В некоторых фирмах так и делают.)
                      +6
                      Для тестовых заданий стараюсь выбрать технологии, с которыми я еще не успел поработать. Например, в последний раз попросили сделать блог с мгновенными обновлениями (кто-то написал пост и он сразу у всех читателей появляется в ленте).
                      Выбрал метеор, о котором я раньше лишь смотрел пару скринкастов, потратил несколько часов на изучение его API и минут 40 на само задание (с метеором оказалось крайне просто всё сделать). Предложение не сделали, зато теперь я имею хорошее представление еще об одном инструменте и могу его использовать в работе.

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

                        В обоих случаях длинные тестовые задания (и их выполнение) допустимы. Хотя тоже не очень правильны.
                          +1
                          Не хватает варианта ответа «Начинал выполнять, но забивал» :)

                          А вообще, были длительные (неоплачиваемые), но с хорошим шансом получить предложение — уже после нескольких собеседований. Один раз взяли по результатам, раз пять нет, но с предоставлением критики кода. Основная проблема — недопонимание ТЗ: там где нужен был быстрый прототип, лишь показывающий что я с технологией знаком или способен быстро разобраться, делал законченное решение и наоборот. В паре случаев подразумевалось неявно, что я всё брошу и буду заниматься заданием, а «на том конце провода» с секундомером сидели.

                          Вообще наиболее часто делал тестовые задания, отправля письмо типа «У вас в вакансии в требованиях указана технология X — мне пока не доводилось с ней работать, но уверен, что быстро изучу основы — вышлите, пожалуйста, тестовое задание, с которым специалист справится за несколько часов». Высылали где-то в процентах 30 случаев.

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

                          С точки зрения закона излишнее уточнение, имхо, в большинстве случаев. Исключительніе права на программу для ЭВМ остаются у разработчика, если нет никакого договора.
                            +2
                            Как вариант взаимно приемлемого диалога, есть такой, как выполнение заданий в онлайне через Скайп/джаббер, с немедленным комментированием хода мысли.


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

                            1) отсеются те, кто сильно нервничает под давлением, являясь в обычном режиме качественным работником
                            2) можно взять того, который умеет качественно работать только если на него давят. Иначе филонит.

                            Так что моё мнение: решение в реальном времени — не самый лучший способ.
                              +2
                              когда я находился в поиске работы, объемные тестовые задания на ранних этапах общения вызывали скорее раздражение, чем желание их делать.
                              Сейчас сам ищу себе работников и выработал следующую тактику:
                              -задание должно быть небольшим (макс. 6 часов рабочего времени)
                              -задание имеет смысл давать, только если в портфолио человека нет чего-либо подобного
                              -задание имеет смысл давать уже на более поздних этапах собеседования
                              -так как задание по итогу может не отображать всего того, что необходимо знать и уметь работнику, оно не должно являться основополагающим при принятии решения
                                0
                                Сделал тестовое задание примерно на 8 часов работы (приложение для твиттера под на андроид на 3 экрана), вылизал, отправил. Через пару дней HR таки ответила, что тот, кто мог бы его проверить — в данный момент в отпуске( Было обидно.
                                  +1
                                  Недавно искал работу и в одной компании на высланное резюме сразу дали тестовое задание объемом дня 1,5 точно и просто сказали «делай до такого-то дня». На другой — дали задание, попутно позвали к себе, объяснили ошибки, помогли исправит (причём тратили своё время) и в итоге я с ними работаю. Да, у второй компании не так много людей и нет потока кандидатов, но само отношение сразу привлекает, хочется делать это задание, хочется работать у них.
                                    –4
                                    Напишу в защиту больших тестовых заданий в некоторых случаях. Поставьте себя на место работодателя, который ищет человека на позицию какого-нибудь senior developer. Что покажет задачка на пару часов? Что разработчик может делать задачку на пару часов? А вот хоть как полно действительное владение всем, что в резюме, покажет тест на пару недель с учётом режима «делаю по вечерам после текущей работы». Так вскрываются и проблемы с самостоятельностью, и с умением уточнять ТЗ, и с поддержкой связи (никому не нужен senior, молча уходящий в offline берлогу на длительный срок), и с умением длительно держать темп разработки, и прочее.

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

                                    Ну и да, такое задание дают уже в финале собеседований, когда понятно, что кандидат хороший и бегло порешал junior задачки.
                                      +3
                                      Как по мне, если целево идёшь в определённую контору на определённую позицию с хорошим окладом, можно и понапрягаться.

                                      Ну разве что действительно есть есть мечта или четкие планы попасть куда-то конкретно, тогда — может быть. Но обычно то идут не в конкретную фирму, а выбирают из нескольких подобных.
                                        +1
                                        Смотря где и смотря кто. Утрирую: вакансия C++ senior в каком-нибудь Intel и вакансия C++ senior в десятке гаражных конторок (которые тоже могут интересными, конечно) — разные вакансии. Выбор между подобными обычно совершается во втором случае и да, там зачастую пофиг.
                                        +3
                                        Основную проблему вызываю такие задачи на первом этапе общения, когда это просто твой «допуск» к настоящему собеседованию, так хотят отсеять на их взгляд не компетентных людей, не тратя время своих сотрудников. Считаю подход такой ошибочным.
                                          +1
                                          Если большой тест дают на первом этапе, нужно сразу уходить, конечно, т.к. в 99% случаев это обман или непрофессионализм.
                                        +3
                                        В моей практике было несколько предложений выполнить тестовое задание. 2 раза соглашался: 1 раз от яндекса было задание в реал тайме за 4 решить задание (справился лишь частично, потом за дополнительное время доработал, но толку не было в итоге) и один раз от mail.ru, задание потребовало около 2 дней плотной работы, с учетом что никогда подобным не занимался. В обоих случаях это были задачи, которые открывали доступ к собеседованию, а не подтверждение каких-то навыков после общения. Оглядываясь назад, не жалею, что за них взялся, но там на руку работодателю играло имя, заставляя постараться. После в процессе активного поиска работы, некоторые совсем неизвестные работодатели присылали свои приглашения рассмотреть их вакансии, в случае согласия общение начиналось с тестовых заданий, со слов HR после позволят поговорить непосредственно с IT специалистами и узнать подробнее о вакансии, ну и пройти настоящее собеседование. Стоит ли говорить, что здесь мотивации на самом деле 0, когда параллельно проходит по 2-3 собеседования в день и перспективы совсем не ясны с этими тестовыми заданиями. В целом я считаю, что такой подход оправдан для компаний, которые имеют достаточно большой конкурс на вакансию, как средство на финальной стадии проверить практические навыки, для все остальных это просто добровольное снижение потока потенциальных кандидатов.
                                          0
                                          Скажите а как вы относитесь к тестам типа сервиса codility? Не находите ли вы что это тоже часто просто трата времени?
                                            0
                                            В прошлом году я прошел 3 из 20 обычных собеседований, а также 3 из 3 по тестовому заданию в размере одного дня. Одно задание не доделал, поскольку в нем было 4 из 4 пунктов не по профилю.
                                              +1
                                              Как только вижу в предложении слова «тестовое задание», сразу в спам добавляю и забываю о вакансии.
                                                +2
                                                Даже если это «если у вас нет образцов кода, то можем прислать тестовое задание»?
                                                0
                                                Единственный случай, когда когда согласился на выполнение задания был примерно такой: «вот тут 4 варианта тестовых заданий, 1-3 — решение в коде одно из трех ИЛИ достаточно описания решения задачи номер 4» — я не поленился, за пару минут накидал по несколько вариантов 1,2(просто по-ходу) без всяких гуглов, местами покритиковал, по третьему пункту честно сказал «я хз че вы там имели ввиду, но вероятно тоже простая штука, принципиальных сложностей не вижу», по четвертому пункту подробно расписал несколько вариантов решения, при том, что это вообще была чисто математическая задача уровня этак класса девятого. Так вот, в ответ начали мяться и заливать «мы ничего не поняли — а значит все неправильно, давайте код». Лол. Я им предложил оплатить мое время на выполнение любого задания в любом объеме — отказались. Само собой на этом мы и расстались. А вообще: сегодня есть большой выбор где и с кем работать, что конечно не может не радовать. Так что надеюсь, что многие работодатели таки обратят на это свое внимание и будут искать более эффективные методы работы(для обеих сторон) в области найма персонала.
                                                  –4
                                                  Опыт оплачиваемых тестовых заданий — из 1500 «ищущих работу» программистов, код прислали двое, и работающий патч сделал один. Тяжелые тестовые задания? Или все же (в среднем) ленивые соискатели?

                                                  Не работает ссылка по тексту. Вот задание: www.dataved.ru/2010/02/openmeetings-developers-landing-page.html
                                                    +6
                                                    О, внезапно. Может быть потому что текст на английском по линку? Может быть потому, что для показа «предложения» надо посчитать сумму от 1 до 99 (это 4950), которое я заметил только после того как докрутил страницу до конца и попытался понять «что это вообще тут за страница такая?». Может быть из-за того, что по факту это исправление багов в неизвестном для многих приложении? Может быть потому что оба линка на тестовые серверы мертвы?
                                                    Кроме того, чтобы разобраться в том, как поставить опенмитингс и настроить его для своих нужд требуется несколько дней — именно столько времени у меня на это ушло, когда нужен был сервер веб-конференций чуть больше года назад. Подскажу: в сети где-то был скрипт автоматической установки на один или два экрана.Так вот, он использует старые версии нужных опенмитингсу программ/библиотек и его тоже старую версию. Просто так подсунуть новую версию туда не получится, т.к. есть зависимости от версий используемых программ/библиотек и для установки новой версии опенгмитингса надо искать искать требуемые ему либы/программы и собирать их, а у них там свои зависимости. И это только установка его. Затем его надо настроить, понять что он из себя представляет, заюзать, и только потом уже имеет смысл лезть в багтрекер и пытаться что-то исправить. А еще опенмитингс в основном работает на флеш. Много ли желающих работать с флеш?
                                                    Возможно стоит пересмотреть тактику, стратегию и методы подбора персонала?
                                                    +1
                                                    Недавно делал отличное тестовое задание — маленькое SPA-приложение за 2 часа. Я после этого валерьянку пил, но меня взяли :)

                                                    Подробнее я тут описал (на английском): latviancoder.com/story/my-hardest-frontend-developer-interview
                                                      +3
                                                      Я однажды, на заре своей карьеры делал длинное тестовое задание, которое отняло у меня 3ое суток по 14 часов.
                                                      Тема была совершенно для меня новая — прикрутить дополнительные элементы к всплывающим меню во всех приложениях в винде. Пришлось курить мануалы и писать на С++, с которым я до этого только немного игрался.
                                                      Когда я принес работающее приложение, товарищи очень удивились — они не ожидали, что кто-то справится.
                                                      Но я бы сказал, что и интервьюеры были аховые (в плане опыта набора персонала), и сам я был еще очень зеленый (и сам долго еще делал грубые ошибки при интервьюировании, пока не набрался опыта).
                                                      Работу я получил, кстати, и не жалею — там было интересно. И задание это больше никто до конца не сделал… не нашлось таких… добровольцев-волонтеров :-)

                                                      Мое личное заключение — тестовые задания не практичны, ни для одной из сторон.

                                                      Вот в другом формате мы их используем — последнего нашего удаленного программера мы взяли после тестового задания, за которое мы сразу ему пообещали заплатить (естественно, после успешного интервью). Он нас приятно удивил качеством выполнения задания, мы его приняли, и очень довольны.
                                                        +1
                                                        Расскажу парочку своих историй. Пару лет назад нашел вакансию на программиста (удаленно) в компании Smart-Soft (те самые, которые Traffic Inspector разрабатывают). Сразу же дали тестовое задание. Если верно помню, нужно было написать монитор для просмотра загрузки прокси-сервера на определенном порту. Написал на Delphi, как и просили. Задание выполнил примерно часов за 9. Отправил. В ответ тишина по сей день. Писал даже с разных почт, с других имен.
                                                        Один раз хотел пойти в компанию-разработчика веб-сайтов. Тестовое задание, якобы оплачиваемое — написать сайт. Написал, в итоге — кинули.
                                                        Для себя сделал вывод, что нужно просто делать хорошее портфолио, и присылать не код, а видео-демонстрацию

                                                        Only users with full accounts can post comments. Log in, please.