Результаты эксперимента по конкурсному набору на работу студентов и молодых специалистов

Недавно мы в Codeminders проводили эксперимент по конкурсному набору молодых специалистов (интернов) и, как обещал, хочу поделиться результатами. Напомню, что мы искали кандидатов на 3 вакансии:

  1. Junior Web Developer
  2. Junior Research Developer
  3. Junior Unix Developer

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

Нам прислали 12 заявок — из них 8 на должность Research Developer и 4 на Web Developer. Один из кандидатов претендовал на обе эти позиции. На позицию Unix Developer не прислали ни одной.

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

Распределение заявок между первыми двумя вакансиями мне понятно. Research Developer ближе к тому, что ребята совсем недавно учили в вузах, и потому на нее заявок было больше. А вот куда на Украине подевались Unix-хакеры — для меня загадка.

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

  1. Если Вы посылаете решение задания, не стоит его «воровать» из Интернета. Мы тоже умеем пользоваться google. Мы специально подбирали такие задания, чтобы нельзя было найти полностью готовое решение на Интернете. С другой стороны, ничего плохого нет в использовании примеров кода, но не стоит это выдавать за свою работу. Достаточно было указать откуда брался код и каков ваш вклад в его доработку или модификацию.
    Кандидатов, приславших чужой код без указания авторства, мы исключили из рассмотрения в первую очередь.
  2. В задании был обязательный минимум и дополнительные пожелания, которые будут учитываться, если будут сделаны. Тут нужно понимать, что это тестовое задание и вам была предоставлена возможность показать себя. Некоторые сделали минимум. Некоторые сделали больше, чем максимум, и при прочих равных, это не могло не повлиять на выбор.
  3. Конечно, это тестовое задание, но цель кандидата — показать себя. Разумеется, для этих небольших тестовых программ можно было обойтись без документации, unit tests, Makefile-ов. Но люди, которые кроме кодов программ сделали и это, выглядели с нашей точки зрения более перспективными конкурсантами. Например, один из кандидатов на вакансию Research Developer написал довольно подробный дизайн-документ и сделал дизайн системы расширяемым, продемонстрировав знание UML, GoF Design Patterns. Понятно, что это в данном случае можно было бы этого и не делать, но зато мы смогли увидеть насколько он способен продемонстрировать архитектурный подход. Один из Web Developer-кандидатов также написал Unit Test-ы для своего JavaScript-кода.
  4. Для тех, кто подошел к задаче в минимальном ее виде (что тоже допустимо) неплохо было бы если не реализовать в полном объеме, то, по крайней мере, задокументировать свои допущения и упрощения. Это позволило бы нам увидеть, что хотя вы что-то не сделали или сделали не до конца, но, тем не менее, понимаете, где и как можно данное решение получить и улучшить. Некоторые кандидаты это сделали.
  5. Частью задачи для кандидатов на вакансию Research Interns было разобраться с незнакомым форматом файла. Хорошим тоном было бы задокументировать результаты вашего анализа формата. Это пригодилось бы вам и коллегам в будущем. Некоторые конкурсанты это сделали.

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

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

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

Вобщем, мы остались довольны результатами эксперимента. Мы взяли на работу двух молодых людей и надеемся, что не ошиблись в выборе. И, оставаясь на волне оптимизма, хочу сказать — мы еще раз убедились, что, несмотря на любые катаклизмы и кризисы, в украинском IT есть сильные и перспективные молодые программисты и есть будущее для роста нашей компании.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


25 комментариев

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

А отчего ж продолжение не последовало?

А вот куда на Украине подевались Unix-хакеры — для меня загадка.

Все просто юникс хакеры не станут претендовать на должность в которой есть слово джуниор

Задание по веб-разработке — совсем не джуниорское, хотя без сомнения интересное.

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

Как это соотносится с тем, подходят ли вам кандидаты?

Я бы оценивал в этом случае так:
1. Пусть часть кода скопирована из открытых источников, но в итоге получилось красивое решение (например, нет «мёртвых» веток кода, которые в оригинале предназначались для решения совсем другой задачи; не приклеено «богатое фичами», но избыточное для данной задачи решение) — хорошо

2. Код скопирован, дополнен костылями и приклеен соплями — плохо

Это напомнило мне одну историю, которая произошла на ACM ICPC-подобном турнире в Виннице. Одна задача получилась такая, что была возможность перебрать все варианты на месте, сгенерировать быстро работающий код и отослать уже его в качестве решения. Один из членов жюри посчитал такие решения мошенничеством и имел желание их «зарубить». Я же настаивал, что при таком раскладе именно так и следует решать: код проходит автоматические тесты с учётом временных ограничений — вот и славно. Если есть возможность написать так — то так и сделать, и это достоинство участника конкурса — умение распознать задачу, пространство решений которой можно перебрать «на месте» и применить такой нестандартный способ решения как генерация кода. Мы сошлись на том, что нужно просто рекомендовать авторам задач проверять свои задачи на существование подобных решений (и это не значит, что подобных задач вообще не должно быть — замысел автора может как раз и состоять в том, чтобы участники придумали такое решение).

Интересно бы услышать — а почему только для молодых по возрасту? Если старик «за 30 лет», решил переквалифицироваться и потому в указанных технологиях «молодой», но согласен на предлагаемую зарплатную вилку — то какие аргументы у вашей компании не допускать таких даже к выполнению задания? Есть негативный опыт? Или просто вся компания из персонала «до 30 лет» и будущему работнику и вам будет некомфортно?

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

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

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

Непонятно. Совсем недавно здесь был коментарий парня который справедливо возмущался насчет обещания компании опубликовать результаты конкурса и дать возможность обсудить их.

Так вот, непонятно куда этот коментарий делся. Если его намеренно удалили то это камень в огород DOU.

Ну и мое решение задачи для Web Developer — dl.dropbox.com/...ders/index.html

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

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

С радостью послушаю критику :)
Код можно посмотреть тут, а само приложение тут.

Может автор комментария сам его удалил?

Если удаляет кто-то из ДОУ, то комментарий обычно появляется здесь:

dou.ua/moderation

Извиняюсь, вполне вероятно что автор так и поступил.
Я не знал что коментарии можно редактировать/удалять, вернее не видел. Так как пункты «Редактировать» и «Удалить» появляются только после наведения курсора на сообщение.

Как один из ведущих разработчиков могу сказать — сам в свое время проходил не мало подобных «тестирований» и на мой взгляд сегодня — это один из наиболее эффективных методов отбора Junior перспективных разработчиков. Начальный энтузиазм позволяет максимально выложиться не особо тратя силы, с другой стороны полностью показывает и наиболее точно отображает перспективность кандидата и склад мышления, способность правильно понять поставленную задачу, спроектировать и реализовать ее решение. Тем более если ее решение фактически требует в десятки раз меньше времени. Можно спокойно и красиво ее решить параллельно с учебой в ВУЗе. Подобный подход много лет практикуется в одной из компаний в которой я работал параллельно с учебой. Этот подход позволяет ориентироваться в большей степени не на CV которого у начинающих специалистов просто нет а на фактический опыт и знания. Позволяет максимально оценить не ВУЗовские знания а мышление, ответственность, подход к предстоящей потенциальной работе как таковой. Я хотел бы от своего имени поблагодарить Codeminders за подобные начинания и как бывший студент хотел бы продолжения подобной практики. Это лучший способ найти своего первого работодателя и самое главное, для кандидата — профессионально расти, учиться и познавать что то новое. Важно чтобы сами задания были не из книг и\или интернета а реалистичные и интересные. Новое всегда привлекает человека стремящегося познавать. На данный момент вырости из Junior developer или из простого студента до специалиста (даже если Вы еще учитесь) довольно сложно поскольку все смотрят на CV (резюме) и не задумываются о перспективе и продвижении молодых специалистов. Хотелось бы сказать что подобные конкурсы стоит проводить чаще. Иногда студенты без резюме оказываются лучше и сильнее «спецов» с многолетним стажем работы (по себе знаю :) )

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

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

Точно. Unix только в заголовке. Ну да,строчкой ниже Linux — но может из-за этого «хакеры» и не повелись на задание? Ну корректней было написать, что ищется питонщик — авось бы кто и отозвался %)

ПС: можете попинать меня ногами, но юникс и линукс, хоть и родственники, даже достаточно близкие, но не одно и то же...Ведь и Mac OS, и Android — такие же их родственники %) (зарисовался я).

Ппс: еще смутило было задание про asf формат — я подумал было, ни хр... сорри..нифигасе задание для юниора. Пока не прочитал до конца и не понял, что никакого отношения к advanced streaming format формату это не имеет %)

Метод не оптимальный можна набрать на работу тугодумов. Лучше все делать тоже самое в риалтайме: — вот комп — вот задача — вот 4 часа времени на ее решение.

Тугодумов избегают те, кто берет не качеством, а скоростью.

Качество == const, а вот по времени тугодумы проигрывают. ;-)

Так я и не спорю. Сайты за один день — это всегда константно некачественная работа.

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

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

Очень хорошее начинание...

Хорошо бы..., чтобы оно переросло в практику и в Российских компаниях.

Прочитал с интересом, спасибо за колонку. Рад, что эксперимент завершился хорошо, думаю кто-то обязательно примет это к сведению. Да и вообще приятно читать позитивные материалы на ДОУ. :)

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