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

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

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

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

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

— Подумают о безопасности:

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

— Если учитывать параметр длины строки, можно убедиться, что код не выходит за конец строки. Хорошо бы проверить значение параметра длины для надежности. Строки, завершаемые null-символом, — лучшие друзья хакера.

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

— Должна ли эта проверка выполняться в конструкции try-catch? Если вызывающий код не ожидает исключений, вероятно, ему следует вернуть код ошибки. Если существуют коды ошибок, насколько четко они определены и задокументированы?

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

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

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

На самом деле любой инженер, прошедший вводный курс программирования, сможет написать код для решения этой задачи. А вот вопросы и подход к решению отличают лучших кандидатов. Мы стараемся создать комфортную обстановку на собеседовании, чтобы кандидат не стеснялся задавать вопросы. Если он молчит, то мы можем легонько подтолкнуть его к разговору, чтобы понять, не вызвано ли стремление поскорее погрузиться в код атмосферой интервью. Сотрудники Google должны уметь задавать любые вопросы, лишь бы это помогло решению задачи.

Было бы скучно перебирать сотни правильных реализаций и распространенные ошибки — все-таки книга не о программировании и не о проведении собеседований. Поэтому мы покажем только одну простую и очевидную реализацию. Заметим, что кандидаты обычно используют язык, который знают лучше всего, например Java или Python. При этом стоит задать дополнительные вопросы, чтобы убедиться, что они правильно понимают специфические детали языка: как язык работает с памятью и типами данных, особенности компиляции и выполнения.

int64 Acount( const char* s) {

if (!s) return 0;

int64 count = 0;

while (*s++) {

if (*s == 'a') count++;

}

return count;

}

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

Еще раз. Достойный кандидат на роль разработчика в тестировании:

— Решает эту задачу без особых проблем. Он пишет код с первого раза, не путается в базовом синтаксисе и не смешивает конструкции из разных языков.

— Правильно понимает работу указателей и не засоряет память.

— Реализует проверку входных данных, чтобы избежать проблем, связанных с null-указателями, или может объяснить, почему он этого не делает.

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

— Исправляет мелкие недочеты в коде, если вы на них укажете.

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