Насколько сложно собеседование в Amazon?

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

Amazon использует структурированный процесс собеседований. Интервьюерам назначают конкретные Leadership Principles для проверки, они делают подробные записи во время разговора, и эти записи затем сравнивают на дебрифе. Отсюда вытекают два следствия. История, которая звучала неплохо в комнате, на бумаге выглядит слабой, если в ней нет решения и результата, а одна и та же история, рассказанная с разными деталями на двух этапах, сразу видна при сравнении записей.

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

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

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

Обычно вы не знаете, кто именно этот интервьюер, и это не важно. Отвечайте на каждом этапе так, будто позже это прочитает незнакомец, потому что так и будет.

Разделите работу. Техническая половина — привычная часть: структуры данных, алгоритмы, а для мидла и выше — проектирование систем. Большинство провалившихся кандидатов проваливаются не здесь.

Поведенческой половине нужно от восьми до двенадцати историй, распределённых по Leadership Principles, каждая — с ситуацией, тем, что решили лично вы, и измеримым результатом. Один проект может дать две или три истории с разных ракурсов. Записывайте результат в виде цифры, если она есть, потому что уточняющий вопрос обычно требует именно её.

Затем отрепетируйте их вслух. Бэкенд-инженер с девятилетним опытом написала отличные заметки и всё равно застряла на первой тренировке, потому что читать историю и рассказывать её под уточняющими вопросами — разные навыки. Две недели устной практики на /mock-interview изменили подачу сильнее, чем ещё месяц чтения. Пошаговая картина всего процесса — на /answers/topic/company-interviews.

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

• Истории без решения. Описание того, что сделала команда, а не того, что выбрали лично вы. В записях в итоге не остаётся доказательств, привязанных к вашему имени.
• Нет результата. История, которая заканчивается запуском проекта, без единого слова о том, сработал ли он.
• Заканчивается материал. Использование одного и того же проекта на четырёх этапах — это видно на дебрифе, даже если ни один отдельный интервьюер этого не заметил.
• Молчаливое решение задачи. Работа над задачей по коду без озвучивания хода мыслей, из-за чего интервьюеру нечего записать.

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