Джеймс Уиттакер - Как тестируют в Google

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

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

Вот пример простой задачи для разработчиков в тестировании. Представьте, что сегодня ваш первый рабочий день и вас попросили реализовать функцию acount(void* s), которая возвращает число букв «A» в строке.

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

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

У разработчика в тестировании обычно ограничено время. Мы хотим, чтобы кандидат остановился и нашел самый эффективный способ решения задачи или улучшил существующее решение. Хороший разработчик в тестировании найдет плохо определенные функции API и по ходу тестирования превратит их в нечто красивое.

Достойный кандидат потратит несколько минут на анализ спецификации, задавая вопросы и записывая утверждения.

— Какая кодировка используется во входной строке: ASCII, UTF-8 или что-то еще?

— Имя функции слабое. Не стоит ли использовать стиль CamelCase [27] CamelCase — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово пишется с заглавной буквы. Стиль получил cвое название из-за того, что заглавные буквы внутри слова напоминают горбы верблюда. и сделать его более содержательным? Или здесь действуют другие стандарты выбора имен?

— Какой тип должна возвращать функция? Наверное, интервьюер забыл, поэтому я добавлю int в начало прототипа функции.

— Конструкция void* опасна. Лучше использовать подходящий тип, например char*, чтобы не пострадать от проверки типов при компиляции.

— Что понимается под буквой «A»? Нижний регистр тоже считается?

— Нет ли такой функции в стандартной библиотеке? (Тут мы ответим, что в интересах собеседования ему нужно представить, что он первым реализует эту функцию.)

Лучшие кандидаты пойдут еще дальше.

— Подумают о масштабе. Возможно, для возвращаемого значения лучше использовать int64, потому что Google часто имеет дело с большими объемами данных.

— Подумают о повторном использовании: почему эта функция подсчитывает только буквы «A»? Вероятно, ее стоит параметризовать, чтобы подсчитывать произвольные символы. Это лучше, чем определять разные функции для разных символов.

— Подумают о безопасности: эти указатели получены из надежного источника?

Наконец, самые лучшие кандидаты:

— Подумают о масштабе:

— Будет ли эта функция выполняться как часть вычислений MapReduce [28] MapReduce — технология распределенных вычислений, при которой вычислительная задача разбивается на небольшие части, которые затем собираются вместе. См. http://en.wikipedia.org/wiki/MapReduce. для сегментированных [29] Сегментация (sharding) — разновидность распределения базы данных. Горизонтальная сегментация позволяет проектировать базы данных: строки таблицы базы данных хранятся по отдельности (в отличие от вертикального разбиения по столбцам). См. http://en.wikipedia.org/wiki/Shard_(database_architecture) данных? Возможно, это самая частая форма вызова такой функции. Есть ли проблемы, которые стоит учитывать в этом сценарии? Надо продумать правильность и быстродействие этой функции при ее выполнении для каждой страницы в интернете.