За статистикою, ми наймаємо одного з 10-20 кандидатів на посаду веб-розробника. При такому потоці необхідно швидко розпізнавати відповідні кандидатури. Різного роду синтетичні тести при відборі співробітників я не люблю - безглузда трата часу. Найкращий спосіб перевірити - відразу кинути в бій.
- Привіт, я крутий веб-розробник, ось моє реюзмі!
- Привіт, спасибі, резюме не треба, давай аккаунт на github, бери тікет No.123 і вперед! Занадто крутий для тебе? Ну вибери сам, який тобі більше подобається, з того що є. Іншої роботи немає.
Мінімум витрат особистого часу, максимум об'єктивності.
Для цього необхідно швидко підключати новобранця до коду проекту. При цьому виключаючи можливість негативного впливу новачка на весь проект і мінімізуючи ризик витоку інформації.
Ми робимо це так.
- Новобранцю видається доступ до системи контролю версія (git). Він створює свою гілку проекту і працює тільки в ній. git (на відміну від svn) дозволяє швидко і оперативно працювати з різними гілками (бранчами) і мержити тільки необхідні зміни. Тут нам на зустріч приходить github.com і 25 $ за організаційний акаунт не шкода. По закінченню виконання завдання, новобранець робить звичайний pull-request, далі код переглядає проект-майстер, якщо його влаштовує, то мержить ці зміни з master-гілкою проекту. Природно ніяких паролів, кодів і ключів у сховищі не лежить, тільки програмний код. Доступу до сервера теж немає, деплоїт проект (викладає і на тестовий (stage) і на продакшен сервер) пару разів на тиждень проект-майстер.
- Девелоперська база. На продакшен-сервері відбувається щоденний бакап бази. На основі бакапа маленький скриптик створює девелоперську копію бази. Вона ідентична продакшену, але в ній затерта вся «чутлива інформація» (паролі, імена, емайли, хеші та ін.). Свіжа щоденна девелоперська база абсолютно безпечна і завжди доступна всім розробникам на скачування за певним посиланням. Таким чином, девелопер запускає проект в умовах максимально наближених до бойових, без ризику витоку інформації третім особам.
- Питання. У розробника звичайно-ж виникають питання щодо проекту. Але, по-перше, на більшу частину з них він може відповісти сам подивившись код проекту (тест на вміння читати чужий код). По-друге, всі переговори розробників щодо проекту проходять по жорстко встановлених каналах зв'язку із збереженою історією листування. Це може бути якийсь basecamp, але, зазвичай, досить групового чату в skype і обговорення введення коментарів по кожній задачі в тікет-трекері. Підключивши новобранця до чату ми віддаємо йому доступ до всієї інформації за проектом, якою володіємо самі. Ну якщо щось не зрозумів, питай в тому-ж чаті.
Як правило цього достатньо щоб новобранець зміг самостійно запустити проект у себе на локальній машині. А це теж важливий тест, часто саме на ньому відбір і закінчується.
Плюси такої моделі:
- Максимально знижені ризики. Ніяких доступів на сервери розробники не отримують взагалі (виключаючи github). Якщо ви боїтеся що новобранець вкраде ваш код і запустить такий-же свій проект, то ви помиляєтеся. Якщо код простий і його просто запустити - то тут і красти нічого не треба, його простіше переписати заново, а якщо складний і великий, то щоб запустити такий проект потрібно більше ніж крадений репозиторій (як мінімум база користувачів). Крім того, вдалий проект це далеко не код + база... якщо і це вас не переконало і ви, все-таки, боїтеся за свій код, то він напевно він вже настільки великий, що його пора розбити на окремі модулі і репозиторії, тоді можна видавати кожному розробнику доступ до певного коду.
- Висока швидкість підключення і випробування нового розробника. Ніяких HR-івських заморочок. Отримали лист від шукача? Видали доступ до git-у, посилання на db, номер завдання і вперед, через день запитали результат і подивилися в github процес його розробки.
- Хороший облік вимоги розробника. Не забуваємо також що у розробника теж є свої запити і вимоги до проекту, в нашому випадку він відразу бачить з чим буде працювати, наскільки йому зрозумілий код, наскільки він розуміє принципи функціонування проекту взагалі, чи хоче працювати з людьми, які писали цей код і вели таке листування і т. п.
Дуже цікаво як відбувається процес відбору і включення нових розробників в інших командах?
