в Agile, Внутренняя кухня, О Компании

Тест-драйв вместо собеседования. Что это дает компании?

Продолжение. Первую часть читайте тут.

Недавно мы провели смелый эксперимент. 2 ноября к нам в SmartStepGroup на целый рабочий день вышел потенциальный кандидат. С 9 до 18, с перерывами на обед и чай\кофе\печеньки. Всё, как полагается.

Конечно же, потребовалась подготовка с нашей стороны. Пользовательскую историю для “новичка” мы выбрали с заказчиком заранее. Чтобы она была не слишком сложной, и кандидат не “закопался” в дебрях легаси, фабриках, конструкторах и хранимках, но и не слишком простой, чтобы оставался спортивный интерес закончить её за день. Кроме этого, было в этой истории и пара “открытых” вопросов для того, чтобы посмотреть, как человек себя ведет в условиях недостаточных требований.


Ну и, парная станция, была настроена, последняя версия кода на жестком диске уже ждала своего часа, проект билдился, тесты были зелены. Осталось только нажать F5 для запуска проекта.

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

Главная задача такого формата — оценить навыки потенциального сотрудника во время написания кода и реальной работы, а не решения всяких технических или аппаратных “затыков”.

Начали мы со знакомства с бэклогом, текущей архитектурой веб приложения (AngularJS, Bootstrap, ASP.Net WebAPI, Entity Framework) и согласования критериев приемки с владельцем продукта (product owner).

Затем, показали заказчику, как примерно может выглядеть интерфейс с захардкоженными данными. Ну и понеслась — парная сессия, мини-перерыв, парная сессия, обед, парная сессия, демо, исправление обратной связи…

После  согласования внешнего вида элементов на экране, стартовала первая парная сессия. Наш подопечный довольно быстро освоился в клиентском JS коде и смог определить, какие методы из публичного API придется затронуть и какие объекты поправить для передачи данных.

На следующей парной сессии состоялось знакомство с тестами и нашими подходами к их написанию. Довольно быстро удалось написать 3-4 новых теста, покрывающих основные приемочные критерии пользовательской истории. Пора было показывать первые результаты владельцу продукта.

Мини-демо прошло довольно быстро. Получили обратную связь о порядке сортировки элементов в выпадающем списке и поймали баг :). Оказалось, что при написании логики мы забыли исключить из выборки архивные записи.
Еще одна сессия, юнит тест, добавление логики и история готова к сдаче.

Всего за день удалось устроить 4 парных сессии, 2 мини-демо и провести кандидата через весь цикл — получение и уточнения требований от Заказачика — согласование приемочных критериев с тестировщиками и владельцем продукта — программирование с 2 потенциальными коллегами в паре и демонстрация готовой истории владельцу продукта.
Получилось даже взять немного технического долга для рефакторинга во время заключительной парной сессии.

Во время парных сессий я регулярно отмечал в листке свои наблюдения и те ситуации, которые было бы чрезвычайно трудно воспроизвести во время “классического” собеседования. Получилась довольно любопытная картина:

  • Насколько человек быстро вникает в домен, код чужого проекта, предметную область приложения. Какие вопросы задает?
  • Насколько компетентен в юнит тестировании. Как быстро понимает существующие тесты, и может ли самостоятельно добавить пару-тройку тестов на новую логику с использованием нашего DSL и билдеров.
  • Как решает реальные ООП проблемы — пробросить параметр в конструктор или добавить публичный setter, а может закрыть поле публичным методом в данном конкретном классе? Ну и куча мини-дизайн решений, которые программисту постоянно  приходится принимать — разбить ли этот класс на 2 сущности, кто будет заниматься трансляцией доменных объектов и т.д.
  • Видит ли дубликацию в коде. Как предлагает решить? Насколько безопасно проводит рефакторинг или просто предлагает переписать класс с нуля в стиле ковбоя с дикого запада 🙂
  • Насколько уверенно пользуется Google Chrome консолью. Как дебажит JS код, смотрит на верстку и быстро находит изменения в минифицированном коде.
  • Как быстро вникает в клиентскую JS стуруктуру. Например, понимает ли, зачем логика сортировки записей и запроса на ребинд модели вынесена в angular контроллер. Может ли предложить альтернативное решение.
  • Знает ли горячие клавиши ReSharper или студии, часто ли пользуется мышью, или все может делать клавиатурой. Например, создать новый класс, переименовать метод, инлайнить переменную или искать использования класса\ интерфейса и метода?
  • Понятно ли называет переменные, свойства и методы? Насколько эти названия согласовываются с бизнес смыслом доменной логики. Тут вам не просто SOLID и то, что методы должны быть 15 строк, а у класса 1 ответственность и прочие бла бла бла. Тут реальный класс, метод и клавиатура — делай и показывай — а не теоритезируй, что я бы сделал так или иначе.
  • Насколько компетентен в C#. Нет, серьезно, многое становится понятно об уровне кандидата. Какие коллекции предлагает использовать, может ли написать запрос на LINQ на группировку сущностей по ключевому полю, может ли из 2 списков собрать 1 по заранее определенному алгоритму и т.д.
  • Насколько комфортно человек общается с представителем заказчика, тестировщиками, какие вопросы задает и на что в первую очередь обращает внимание. Понимает ли ценность такого общения, или “война план покажет”?
  • Ну и самое главное для нас, как для работодателя — как быстро я смогу встроить данного конкретного кандидата в рабочий процесс?

Кроме того, с точки зрения непрерывного улучшения было полезно посмотреть на следующие вещи.

  • Можем ли мы рассказать об архитектуре и показать все компоненты приложения за 1 день? Или у нас что-то переусложнено, раз на рассказ уходит больше 1 дня?
  • Насколько понятен наш код, тесты человеку со стороны? Эдакий коридорный тест на реальном проекте.
  • Полезны ли наши артефакты — вики статьи, архитектурные диаграммы, инструкции, скрипты. Несут ли они ценность для нового человека? Можно ли их еще больше упростить?
  • Насколько просто процесс деплоя на тестовое окружение — может ли человек “со стороны” задеплоить последнюю версию для тестирования?

Это был наш первый эксперимент — и он удался. Мы посмотрели, на реальные навыки кандидата и получили кучу информации для принятия решения. Да и сам процесс был гораздо прикольнее и живее, чем на “классическом” интервью. Ну и то, что получили законченную историю и немного улучшили продукт добавляет оптимизма 🙂
По итогам дня, мы собрали с кандидата обратную связь — что понравилось?, а что можно улучшить? Оказалось, что и для потенциального кандидата новый формат несет много открытий. Но это уже тема для следующей статьи.

Оставайтесь на связи!

Написать Комментарий

Комментарии

Webmentions

  • Какое оборудование мы используем в работе? — Smart Step Group

    […] проводить собеседования, и что это дает кандидату и компании. Сегодня поговорим о том, на каком железе работают […]

  • Тест-драйв вместо собеседования. Что это дает кандидату? — Smart Step Group

    […] прошлой статье мы рассказали, что такой подход дает нам, как компании. […]