Пример отличного кандидата Джейсон Арбон

Пример отличного кандидата

Джейсон Арбон

Одного нашего кандидата (который, кстати, уже великолепно справляется с работой в Google) спросили, как бы он организовал тестирование граничных условий для версии этой функции с 64-разрядными целыми числами. Он быстро догадался, что задача физически неразрешима из-за ограничений по времени и объемам данных. Но из любопытства, подогретого нетривиальностью задачи, прикинул, как можно хотя бы разместить большие объемы данных для таких тестов. В качестве входных данных он взял веб-индекс Google.

Как же он проверил свое решение? Кандидат предложил использовать параллельную реализацию и посмотреть, дадут ли обе реализации одинаковый результат. Он предложил применить метод статического выборочного контроля: знаем ли мы, какова предполагаемая частота появления буквы «А» на веб-страницах? Если нам известно количество проиндексированных страниц, мы можем сравнить результат вычислений программы с результатом, полученным теоретическим путем. Это подход к тестированию в духе Google. Хотя мы не стали реализовывать эти гигантские тесты, сама возможность таких решений наталкивает на интересные идеи для реальной работы.

Еще один параметр, который мы проверяем на собеседовании, — «гугловость», то есть соответствие нашей культуре. Насколько кандидат технически любознателен? Может ли он интегрировать в свое решение новые идеи? Как он справляется с неоднозначностью? Знакомы ли ему академические методы проверки качества, например доказательства теорем? Разбирается ли он в метриках качества или автоматизации в других областях, например в самолетостроении?

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

Важное замечание: если человек, проходящий интервью на должность разработчика в тестировании, оказался не таким уж сильным программистом, из него может получиться хороший инженер по тестированию. Некоторые из наших лучших инженеров по тестированию изначально пробовались на должность разработчика в тестировании.

Интересно, что мы часто упускаем хороших кандидатов, потому что за время собеседования они склоняются в сторону чистого программирования или, наоборот, зацикливаются на тестировании. Мы хотим, чтобы кандидатов собеседовали специалисты разных должностей, которым потом придется с ними работать, потому что роль разработчика в тестировании — это сплав двух ролей, и иногда ее сложно правильно оценить на собеседовании. Нужно быть уверенным в том, что плохие оценки выставлены людьми, понимающими такую двуликость хорошего кандидата.

Пат Коупленд во введении говорит, что по поводу найма разработчика в тестировании было и есть много полярных мнений. Если он хорошо программирует, может быть, поручать ему писать фичи? Ведь хороших разработчиков тоже сложно найти. А может, им стоит сосредоточиться только на тестировании, если они легко с этим справляются? Истина, как обычно, лежит где-то посередине.

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