Pull to refresh

С корабля на бал

Reading time 3 min
Views 1.5K
image

По статистике, мы нанимаем одного из 10-20 обратившихся кандидатов на должность веб-разработчика. При таком потоке необходимо быстро распознавать подходящие кандидатуры. Разного рода синтетические тесты при отборе сотрудников я не люблю – бессмысленая трата времени. Лучший способ проверить – сразу кинуть в бой.

— Привет, я крутой веб-разработчик, вот мое реюзме!
— Привет, спасибо, резюме не надо, давай аккаунт на github, бери тикет No.123 и вперед! Слишком крутой для тебя? Ну выбери сам, какой тебе больше нравится, из того что есть. Другой работы нет.

Минимум затрат личного времени, максимум объективности.

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

Мы делаем это так.


  1. Новобранцу выдается доступ к системе контроля версия (git). Он создает свою ветку проекта и работает только в ней. git (в отличии от svn) позволяет быстро и оперативно работать с различными ветками (бранчами) и мержить только необходимые изменения. Здесь нам на встречу приходит github.com и 25$ за организационный аккаунт не жалко. По окончанию выполнения задачи, новобранец делает обычный pull-request, дальше код просматривает проект-мастер, если его устраивает, то мержит эти изменения с master-веткой проекта. Естественно никаких паролей, кодов и ключей в репозитории не лежит, только программный код. Доступа к серверу тоже нет, деплоит проект (выкладывает и на тестовый (stage) и на продакшен сервер) пару раз в неделю проект-мастер.
  2. Девелоперская база.На продакшен-сервере происходит ежедневный бакап базы. На основе бакапа маленький скриптик создает девелоперскую копию базы. Она идентична продакшену, но в ней затерта вся “чувствительная информация” (пароли, имена, емайлы, хеши и др.). Свежая ежедневная девелоперская база абсолютно безопасна и всегда доступна всем разработчиков на скачивание по определенной ссылке. Таким образом, девелопер запускает проект в условиях максимально приближенных к боевым, без риска утечки информации третьим лицам.
  3. Вопросы. У разработчика конечно-же возникают вопросы по проекту. Но, во-первых, на большую часть из них он может ответить сам посмотрев код проекта (тест на умение читать чужой код). Во-вторых, все переговоры разработчиков по проекту проходят по жестко установленным каналам связи с сохраняемой историей переписки. Это может быть какой-нибудь basecamp, но, обычно, достаточно группового чата в skype и обсуждения ввиде комментариев по каждой задаче в тикет-трекере. Подключив новобранца к чату мы отдаем ему доступ ко всей информации по проекту, которой обладаем сами. Ну если что-то не понял, спрашивай в том-же чате.


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

Плюсы такой модели:

  1. Максимально снижены риски. Никаких доступов на сервера разработчики не получают вообще (исключая github). Если вы боитесь что новобранец украдет ваш код и запустит такой-же свой проект, то вы заблуждаетесь. Если код простой и его просто запустить – то тут и воровать ничего не надо, его проще переписать заново, а если сложный и большой, то чтобы запустить такой проект нужно больше чем ворованный репозиторий (как минимум база пользователей). Кроме того, удачный проект это далеко не код+база… если и это вас не убедило и вы, все-таки, боитесь за свой код, то он наверняка он уже настолько большой, что его пора разбить на отдельные модули и репозитории, тогда можно выдавать каждому разработчику доступ к определенному коду.
  2. Высокая скороcть подключения и испытания нового разработчика. Никаких HR-овских заморочек. Получили письмо от искателя? Выдали доступ к git-у, ссылку на db, номер задачи и вперед, через день спросили результат и посмотрели в github процесс его разработки.
  3. Хороший учет требования разработчика. Не забываем также что у разработчика тоже есть свои запросы и требования к проекту, в нашем случае он сразу видит с чем будет работать, насколько ему понятен код, насколько он понимает принципы функционирования проекта вообще, хочет ли работать с людьми, которые писали этот код и вели такую переписку и т.п.


Очень интересно как происходит процесс отбора и включения новых разработчиков в других командах?
Tags:
Hubs:
+85
Comments 213
Comments Comments 213

Articles