Инженер выложил расшифровку неудачного телефонного собеседования в Google

Разработчик Пьер Готье собеседовался на позицию технического директора в Google. На работу его не взяли, но он не постеснялся выложить расшифровку вопросов и ответов из собеседования с кадровиком компании. Он решил написать об этом, поскольку, по его словам, рекрутер не хотел или не мог по незнанию обсуждать верные ответы, а ожидал ответов «по учебнику». Один из комментариев, которые цитирует Пьер: «Это не тот ответ, который указан у меня на бумажке».

Самой публикации уже несколько месяцев, но недавно пост Пьера заметило сообщество Hacker News, где сообщение вызвало бурную дискуссию и заодно положило сервер с блогом. Одни участники обсуждения обвиняли Пьера в том, что ни разу не встречали подобных вопросов на собеседовании в компании, другие подтверждали его данные. Так что пост можно расценивать и как беспристрастное свидетельство, и как месть обиженного соискателя. Публикуем перевод самого поста.

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

Чтобы прояснить контекст: я начал заниматься программированием 37 лет назад, когда мне было 11, и никогда не останавливался с тех пор (карьеру Пьера можно проследить в LinkedIn — ред.). В 24 года меня назначили R&D-директором в TWD, я разрабатывал наиболее ответственные части проектов — все они сейчас являются коммерческими. Среди них глобальная WAN-сеть, (распределенная C/VHDL L2 VPN), которая базируется на kernel-bypass IP-стеке и разработанном нами методе постквантового шифрования; 200-килобайтный сервер приложений с поддержкой 17 языков программирования и др.

Представитель Google указал, что требуются как менеджерские навыки, так и навыки современного программирования (редкое сочетание). Я занимался первым около 20 лет, а последним — около 40 лет подряд — этого оказалось недостаточно: я не смог дать правильных ответов. Возможно, в Google и в самом деле слишком высокая планка, а возможно, их HR-специалистам не хватает тех умений, которые они призваны оценивать?

Давайте же выясним.

Тест Google на позицию технического директора

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

1. Вопрос: Какая функция противоположна malloc() в C?

Я: free().

Интервьюер: Верно.

Мысли про себя: В такие редкие моменты, наверное, нужно гордиться своими 35 годами опыта программирования на 40-летнем С.

2. Вопрос: Какая функция в Unix позволяет сокету получать соединения?

Я: listen().

Интервьюер: Верно.

Мысли про себя: Неужели это квалифицирует меня как гуру по сетям?

3. Вопрос: Сколько байтов нужно для хранения MAC-адреса?

Я: 6.

Интервьюер: Верно.

Мысли про себя: Думаю, я только что заслужил значок знатока Ethernet.

4. Вопрос: Отсортируйте по временным затратам следующие задачи: чтение регистра ЦП, поиск на диске, переключение контекста, чтение системной памяти.

Я: Чтение регистра ЦП, чтение системной памяти, переключение контекста, поиск на диске.

Интервьюер: Верно.

Мысли про себя: Такое рассказывают на первом курсе любого IT-вуза.

5. Вопрос: Что такое индексный дескриптор Linux?

Я: Уникальный идентификатор файла для любой данной файловой системы.

Интервьюер: Неверно, это метаданные файла.

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

Интервьюер: Неправильно, не «атрибуты», а «метаданные».

Мысли про себя: «Метаданные» звучит более информативно, чем «атрибуты», вы серьезно?

6. Вопрос: Какая функция в Linux возвращает индексный дескриптор по пути файла?

Я: Я писал кастомизированный LIBC для нашего сервера приложений G-WAN, но не помню ни одной syscall, возвращающей индексный дескриптор.

Интервьюер: stat()

Я: stat(), fstat(), lstat() и fstatat() все возвращают код ошибки. Они заполняют stat-структуру, которая содержит атрибуты файла (мы обсуждали их ранее), а не только индексный дескриптор.

Интервьюер: Это не ответ, дескриптор содержит все метаданные.

Мысли про себя: Возможно, Google секретно купил лицензию на одиозного чат-бота от Microsoft? (от редакции: разработчик имеет в виду бота Тэй, созданного Microsoft для имитации общения дружелюбной девочки-подростка в соцсетях. Эксперимент закончился плохо: бот, выпущенный в Twitter, довольно скоро стал расистом и поклонником Гитлера).

7. Вопрос: Как называется KILL-сигнал?

Я: SIGKILL, #define для которого установлено как 9.

Интервьюер: Нет, правильный ответ TERMINATE.

Я: SIGKILL со значением 15 отличается от сигнала KILL со значением 9.

Интервьюер: Это не тот ответ, который указан у меня на бумажке.

Мысли про себя: Вот что случается, когда чат-боты открывают для себя легкие наркотики.

8. Вопрос: Почему Quicksort — это лучший метод сортировки?

Я: Это не так, он не всегда подходит.

Интервьюер: Но у Quicksort лучшие оценки Big-O.

Я: Big-O игнорирует задержки хранения данных, топологию, объемы, доступную память, даже вычислительную сложность для каждой команды ЦП в данной процедуре. Вместо этого он просто считает количество алгоритмических операций! Big-O может быть ценным указателем для разработки алгоритмов, но решение с лучшей производительностью и масштабируемостью зависит от ограничений, связанных с каждой конкретной задачей и окружением.

Интервьюер: Неверно, вы должны были назвать мне оценку Quicksort в Big-O.

Мысли про себя: Когда же власти наконец признают влияние табачного скандала на психическое здоровье общества? Ядро Linux (которое испольует сам Google) выбрало Heapsort, а не Quicksort, поскольку первый экономнее использует память и более предсказуем по времени исполнения.

9. Вопрос: Есть массив из 10 000 16-битных значений, как эффективнее всего сосчитать биты?

Я: Нужно сдвинуть биты на всех 64-битных словах, по методу Кернигана.

Интервьюер: Нет.

Я:  Есть и более быстрые методы обработки 64-битных слов с масками, но я не смогу объяснить это по телефону, чтобы ответить, мне нужно будет писать код.

Интервьюер: Правильный ответ — использовать таблицу перекодировки и затем сосчитать результат.

Я: Для какого ЦП? Почему бы не сравнить результаты моего кода с вашими в каком-то стандартном тесте?

Интервьюер: Смысл теста не в этом.

Я: А в чем?

Интервьюер: Мне нужно убедиться, что вы знаете правильные ответы.

Мысли про себя: И сколько же будет продолжаться это дерьмо? 8-битная таблица перекодировки может обрабатывать байты один за другим, в то время, метод на основе 64-битной маски обрабатывает 8-битные слова одновременно (и кроме того, современные ЦП позволяют вам обрабатывать 128-битные слова с 10-кратной скоростью, если вам не нужно думать о портировании). 64-битная таблица недоступна для современных компьютеров, так что нет сомнений, что из предложенного работает быстрее.

10. Вопрос: Какой тип пакетов, которыми обмениваются при установлении соединения по TCP?

Я: В 16-ричной системе: 0x02, 0x12, 0x10, что буквально обозначает «синхронизировать» и «подтвердить».

Интервьюер: Неверно. Это SYN, SYN-ACK и ACK. Если Google столкнется с проблемами, вы должны это знать, чтобы диагностировать их. На этом моменте мы прекращаем интервью, поскольку очевидно, что у вас нет нужных умений, чтобы писать или проверять сетевые приложения. Вам необходимо выучить вызовы функций в Linux, как работает стек в TCP/IP и что означает Big-O, если вы надумаете подаваться еще раз. Удачи и до свидания.

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

С другой стороны, мои результаты в тесте — 4 из 10, что лучше, чем мой самый лучший Google-пейджранк!

Подсказка: Нанимать людей, которые знают то, чего не знаете вы, лучше, чем нанимать людей, которые знают то, что знают все.

Обновление: ночью 13 октября 2016 года (спустя почти 7 месяцев после публикации оригинального поста) мы получили отчеты о том, что сервер, на котором хостится блог, был недоступен несколько часов. Многие письма отсылали нас к дискуссии на Hacker News, где люди, заявляющие, что работают в Google, отрицали, что компания использует подобные вопросы. Другие же подтверждали, что слышали от Google те же вопросы на собеседовании…

Я не запрашивал у Google этого интервью. Вместе с тем, после случая с Hacker News я получил несколько интересных предложений о работе, а также — резюме от кандидатов, желающих работать в TWD. Это доказательство того, что многие понимают реалии мира, в котором живут. Большое спасибо за отзывы, поддержку и возрождение моей веры в следующее поколение программистов.

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