Уиттакер . - Как тестируют в Google

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

На заметку

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

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

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

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

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

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

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

— Имя функции слабое. Не стоит ли использовать стиль CamelCase27 и сделать его более содержательным? Или здесь действуют другие стандарты выбора имен?

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

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

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

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

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

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

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

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

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

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

— Будет ли эта функция выполняться как часть вычислений MapReduce28 для сегментированных29 данных? Возможно, это самая частая форма вызова такой функции. Есть ли проблемы, которые стоит учитывать в этом сценарии? Надо продумать правильность и быстродействие этой функции при ее выполнении для каждой страницы в интернете.

— Если функция вызывается для каждого запроса Google и только с бе­зопасными указателями, потому что указатели уже проверяются уровнем выше, возможно, следует перестать каждый раз проверять на null. Это сэкономит нам сотни миллионов циклов работы процессора и немного уменьшит задержку на пользовательской стороне. Как минимум, нужно вспомнить о возможных последствиях полной проверки параметров.

— Подумают об оптимизациях, основанных на инвариантах:

— Можно ли предполагать, что входные данные уже отсортированы? Если так, то функция может прекратить свою работу, обнаружив первую букву «B».

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