Тази страхотна статия беше публикувана от нашия собствен Олексий Варяник на руски в PragmaticPerl, брой 23. Той навлиза в подробности за търсенето, тестването и наемането на разработчици на Perl и споделя малко практически опит в изграждането на първокласен Perl екип от нулата.

В много отношения тази публикация е отговор на тези две публикации: „Защо не можете да наемете страхотни разработчици на Perl“ и „Намиране на добър разработчик на Perl“ и няколко подобни теми в мрежата, относно това колко трудно е да се намерят разработчици на Perl.

Фонът

В началото набирането на персонал не беше голяма работа — HR бяха страхотни в намирането на разработчици на Perl, провеждахме интервюта и когато наистина харесахме кандидата, му/й предложихме работа.

Екипите се състоеха от back-end- (BE, Perl), front-end- (FE, JS) и QA инженери. Това е редът, в който искахме да наемем персонал. Въпреки това, колкото и да се опитвахме, процесът всъщност работеше в обратна посока.

Първи бяха QA момчетата, след това се появиха FE и едва след доста време, с огромни усилия, успяхме да привлечем BE момчетата. И проблемът с набирането на разработчици ставаше все по-труден.

Първата стъпка

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

Оттам започнаха да се случват интересните неща.

Бихте ли описали процеса на предаване на GET параметри? - Те се появяват в променлива $_GET.

Имаше няколко много сериозни разработчици с опит в разработката на C++ за персонализирана архитектура:

-Бихте ли обяснили какво е шаблон в C++? - Това е шаблон! - Е, добре, за какво се използва? -…

И имаше само добри програмисти:

-Можете ли да напишете функция, която е подала цяло число и връща 0, ако е четно, и 1, когато е нечетно. - Е, вероятно не съм вашият перфектен кандидат.

Чрез прилагането на „филтри“ като тестови задачи, технически въпроси от HR и други, успяхме да намалим потока от неквалифицирани. Успяхме също така да наемем страхотни хора в екипа, но начинът, който избрахме, просто не работи много добре. Отново беше време за промени.

Предисторията

През 2008 г. съседна компания нае екип от разработчици на Perl за голям проект. По принцип те се сблъскаха със същите проблеми. Те направиха мъдро нещо - наеха умни хора и след това ги научиха на Perl. Ние направихме същото и беше успех. Дори създадохме отделна компания, наречена WebbyLab.

Набирането на персонал

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

Ето ги и тях:

  1. Преглед на курса. Какво прави Perl. Настройка на средата;
  2. Въведение в Perl. Скаларни данни. Операции с числа;
  3. Масиви и хешове. За всеки. Специални променливи ($_).next, last, redo;
  4. Операции с низове. Регулярни изрази;
  5. Процедури и функции. Модули и пакети;
  6. Връзки и обекти;
  7. CGI;
  8. DBI.

Помолихме нашите собствени разработчици да разпределят темите помежду си и да подготвят доклади, максимум 90 минути всеки. Освен това те подготвиха тестове, но за това по-късно.

След това HR и PR се включиха и свършиха огромна работа с кандидатите. А те бяха много. Пускаме обява:

Време е да научите малко Perl. Казвате, че е старо? Всъщност никога не е било толкова далеч от това да е старо. И се търси!

Provectus обявява курс по Perl с възможност за по-нататъшна работа. Курсът включва лекции и практическа работа с акцент върху самообучението. Този подход позволява лесно да влезете в проекта, да се справите с всички трудни задачи и да вземете бързи решения. Курсът ще продължи 3 седмици, с 2 урока седмично. На най-добрите студенти ще бъде предложена позиция в екипа Live Nation/Ticketmaster на Provectus.

За предпочитане опит в компютърните науки/математика;

Аналитичен ум;

Способност за бързо научаване на нови неща;

Опит с всеки обектно-ориентиран език за програмиране;

Основни познания по Perl са плюс;

Опит с БД, за предпочитане MySQL;

Познания по алгоритми и приложна математика.

Курсът е безплатен!

Изпратихме около 100 автобиографии, сред които имаше професионалисти от всякакъв вид - от студенти, през опитни програмисти до учени и професори. Избрахме 54 души и им изпратихме покани за тест.

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

Първият тест

В цикъл от 1 до 71 върнете c * 10 за всяко c, което е кратно на 3, и c * 100 за всяко c, което е кратно на 7. Ако c не се дели на 3 и c е кратно на 7 — не отпечатвайте нищо. Изчислете и покажете сумата на двете върнати числа.

Този е лесен, предназначен по-скоро за мотивация, отколкото за истинско тестване. Зададохме въпроси, свързани с кодовия поток:

Какво се случва, ако размените местата на тези низове?

Моля, модифицирайте програмата, така че да връща c, в случай че не е кратно на 3 или 7. Избрахме ги с причина – да видим c % 21);

Как оптимизирате програмата? Променете го от цикъл 1–71 на просто събиране;

Втората задача беше малко по-трудна

„Напишете функция, която генерира пагинация. Параметри: a: броят на записите; b: броят на записите на една страница; c: начална страница. Страницирането трябва да изглежда като 1 2 [3] 4 5 … През цялото време се показват 5 страници и многоточие, а индикаторът на текущата страница се премества наляво или надясно. … 6 7 8 [9] 10›

Броят на записите е 0;

Началната страница е извън диапазона;

Броят на страниците е по-малък от 5 (елипсата трябва да изчезне и от двете страни)”.

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

Ето последната задача (добре, това всъщност са две задачи в една):

„Имате двоичен файл. Чрез представяне като последователност от ASCII символи, изчислете броя на буквите „z“ и „Y“ във файла. Изведете резултата в бази 2 до 16″.

Първоначално следвахме 2 цели в тази задача, но проверката й доведе до друга:

  • тестване на капацитета — дали кандидатът ще разбере как да промени програмата, ако двоичният файл е голям колкото терабайт;
  • проверка на действителното познаване на бази;
  • съответствие с изискванията. Това беше много по-предизвикателно, тъй като „Y“ и „y“ са различни, а „Бази 2 до 16″ включва 3, 4, 5 и т.н.

Началото

След доста време успяхме да съберем група от 21 (срещу първоначално планираните 10; някои бяха твърде добри, за да се сбогуват). Първата лекция беше въведение: просто се събрахме, за да се опознаем.

Учениците видяха своите учители, учителите изясниха двата ключови момента: първо — курсът е безплатен, второ — ще се преподава от програмисти, всъщност не всички професионални учители. Всеки, който не харесваше условията, можеше да отиде по всяко време, без никакви условия.

На всеки беше дадена виртуална машина VirtualBox (за намаляване на риска за архитектурата и околната среда) и набор от инструкции за настройване на нещо, кодиране, тестване, отстраняване на проблеми и т.н.

Домашна задача

Започна се.

След това бяхме предизвикани да наблюдаваме напредъка и да оценяваме резултатите от експеримента. Искахме знанията да се проверят на практика, поради което учителите трябваше да разработят 1-3 задачи по техните теми.

  • Напишете програма за намиране на квадратния корен на уравнението: ax2+bx+c=0
  • Смяна на основите от 10 на друга и обратно;
  • Изчислете срещанията на дума в текста;
  • Намиране на циклите в цикличната структура от данни;
  • Напишете много проста обвивка;
  • Умножение на две матрици;
  • Аналог на Data::Dumper
  • Пишете класове за данни и календар
  • SQL-изпълнител;
  • CGI-приложение

Към всяка задача написахме набор от тестове.

Въпрос 1: Проверка

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

VirtualBox има страхотен инструмент за моментни снимки. За всяко тестване връщаме машината в първоначалното й състояние и провеждаме тестовете.

Стартирането на 21 програми *N тестове би било трудно да се направи на ръка, поради което изработихме shell скриптове за тестване. Процесът на изпращане на задачите беше объркан в началото - но ние се справихме с него, като бърникахме друг скрипт. Позволява редактиране на заданието преди определено време и само веднъж - след него. Всички резултати бяха поставени в частен git.

Номиналните решения от учителите бяха поставени в същото хранилище. Скриптът, който трябва да се тества, получи името на първоначалния файл с данни. Тестовите данни бяха дефинирани в model/*/dat.

Статистика

Искахме да получим възможно най-много от него. Първият набор от данни, който измислихме, бяха резултатите от тестовете. Ето как изглеждаха:

Знаците “+” и “-” показват дали кандидатът е издържал или не изпита. „T“ означава, че тестът е изтекъл или алгоритъмът е зациклил. Тази статистика изглежда не е достатъчна, тъй като резултатите бяха качени в мрежата, можехме да изчислим времето, изразходвано за действителното решаване на проблема.

Тази информация може да се използва за определяне на победителя, в случай че двама или повече кандидати дадат еднаква оценка. В крайна сметка никога не сме имали нужда от него. Съперничеството се разгаряше. Получената таблица изглеждаше така:

Наименование

Колкото и да се опитвахме, накрая все още имаше много грешки, свързани с резултатите. За да накараме целия процес да се придържа към правилата, добавихме тази стъпка.

Както казах по-горе, източниците бяха качени в git, поради което решихме да използваме git hub + заявка за сливане за случаите на апелация. Бяха разрешени само тези, които не променят логиката на програмата.

Експертиза с ангажиране, натискане, искане за сливане беше приятен бонус.

Интервю

Решихме да проведем интервютата в низходящ ред според оценката на кандидатите. Случи се така, че трябваше да интервюираме само тези с оценка 5 или по-висока.

В резултат на това наехме 5 Junior BE и взехме 2 стажанти.

За момента на това писане имаме само 4 души, останали с нас.

Заключение

Всичко има две страни и точно затова ще прегледам изводите като списък с предимства и недостатъци.

  • Наехме СТРАХОТНИ младши разработчици. Допълнително образователен.
  • Имам страхотен опит при наемане.
  • Изградете екипен дух — след интензивно учене „професорите“ и студентите наистина съставиха страхотен екип.
  • Винаги има шанс веднага да получите разработчици от средно ниво. Може да е така при хора с първоначални умения.
  • Повишен имидж на компанията.
  • Доведе нови хора в общността на Perl.
  • Тази методология не може да ви осигури старши разработчици.
  • Отнема много време (въпреки че е добре обосновано). Определено вижте дали нашият експеримент е приложим за вашия конкретен случай.

И това е! Абонирайте се, за да сте в крак с най-новото. Оригиналната статия от Олексий Варяник (мениджър софтуерен инженеринг в Provectus) се появи за първи път на руски в PragmaticPerl, брой 23.

Първоначално публикувано в provectus.com.