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

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

Junior Web Developer
Junior Research Developer
Junior Unix Developer

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

Нам прислали 12 заявок - з них 8 на посаду Research Developer і 4 на Web Developer. Один з кандидатів претендував на обидві ці позиції. На позицію Unix Developer не надіслали жодної.

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

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

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

Якщо Ви посилаєте рішення завдання, не варто його «красти» з Інтернету. Ми теж вміємо користуватися google. Ми спеціально підбирали такі завдання, щоб не можна було знайти повністю готове рішення на Інтернеті. З іншого боку, нічого поганого немає в використанні прикладів коду, але не варто це видавати за свою роботу. Досить було вказати звідки брався код і який ваш внесок у його доробку або модифікацію.
Кандидатів, що надіслали чужий код без вказівки авторства, ми виключили з розгляду в першу чергу.
У завданні був обов'язковий мінімум і додаткові побажання, які будуть враховуватися, якщо будуть зроблені. Тут потрібно розуміти, що це тестове завдання і вам була надана можливість показати себе. Деякі зробили мінімум. Деякі зробили більше, ніж максимум, і при інших рівних, це не могло не вплинути на вибір.
Звичайно, це тестове завдання, але мета кандидата - показати себе. Зрозуміло, для цих невеликих тестових програм можна було обійтися без документації, unit tests, Makefile-ів. Але люди, які окрім кодів програм зробили і це, виглядали з нашої точки зору більш перспективними конкурсантами. Наприклад, один з кандидатів на вакансію Research Developer написав досить детальний дизайн-документ і зробив дизайн системи розширюваним, продемонструвавши знання UML, GoF Design Patterns. Зрозуміло, що це в даному випадку можна було б цього й не робити, але зате ми змогли побачити наскільки він здатний продемонструвати архітектурний підхід. Один з Web Developer-кандидатів також написав Unit Test-и для свого JavaScript-коду.
Для тих, хто підійшов до завдання у мінімальному її вигляді (що теж припустимо) непогано було б якщо не реалізувати в повному обсязі, то, принаймні, задокументувати свої припущення та спрощення. Це дозволило б нам побачити, що хоча ви щось не зробили або зробили не до кінця, але, тим не менш, розумієте, де і як можна це рішення отримати і поліпшити. Деякі кандидати це зробили.
Частиною завдання для кандидатів на вакансію Research Interns було розібратися з незнайомою форматом файлу. Хорошим тоном було б задокументувати результати вашого аналізу формату. Це згодилося б вам і колегам в майбутньому. Деякі конкурсанти це зробили.

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

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

Механізм конкурсного відбору нам здався досить ефективним. Усім не пройшли за конкурсом кандидатам ми послали короткі зауваження на їх вирішення. Сподіваюся, в майбутньому, після того як вони трохи наберуться досвіду, вони зможуть успішно пройти інтерв'ю і знайти роботу у нас або в іншій компанії.

Вобщем, ми залишилися задоволені результатами експерименту. Ми взяли на роботу двох молодих людей і сподіваємося, що не помилилися у виборі. І, залишаючись на хвилі оптимізму, хочу сказати - ми ще раз переконалися, що, незважаючи на будь-які катаклізми й кризи, в українському IT є сильні і перспективні молоді програмісти і є майбутнє для зростання нашої компанії.

Опубліковано: 25/01/12 @ 08:42
Розділ Різне

SEO Блог

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

Рекомендуємо: