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

Недавно мы в 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 есть сильные и перспективные молодые программисты и есть будущее для роста нашей компании.

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