Наскільки Складне Співбесідування в Amazon?

Якщо ви натренювали алгоритмічні задачі і все одно почуваєтеся непідготовленими, це відчуття правильне. Цей розділ пояснює, з чого складається додаткова складність, адже річ не в задачах, і розв'язання ще більшої їх кількості цього не виправить.

Amazon проводить структурований процес. Інтерв'юерам призначають конкретні Leadership Principles для перевірки, вони роблять детальні нотатки під час розмови, і ці нотатки порівнюють на подальшому дебрифі. Звідси два наслідки. Історія, яка звучала непогано в кімнаті, на папері виглядає слабкою, якщо в ній немає рішення й результату, а та сама історія, розказана двічі з різними деталями у двох раундах, одразу впадає в очі під час порівняння нотаток.

Інше джерело складності — поведінкова планка діє й у технічних раундах. Кандидат, який охайно розв'язує задачу з коду, але не може описати момент, коли не погодився з менеджером, провалив компонент, який суто технічна співбесіда ніколи б не виміряла.

Bar Raiser — це інтерв'юер поза командою найму, навчений для цієї ролі, чиє завдання — оцінити, чи піднімаєте ви середній рівень людей, які вже на цій позиції. Він не оцінює, чи потрібна команді ще одна людина цього кварталу, і може заблокувати найм, якого хоче менеджер з найму.

На практиці це означає, що людина, яка вирішує ваш результат, не зацікавлена в заповненні вакансії. Терміновість вам не допоможе, як і хороші стосунки з менеджером. Що справді допомагає — це доказ, який витримує перевірку, коли його записують і читає людина, яка ніколи вас не зустрічала.

Зазвичай ви не знаєте, хто саме цей інтерв'юер, і це не має значення. Відповідайте в кожному раунді так, ніби це пізніше прочитає незнайомець, бо так і є.

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

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

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

Чотири патерни пояснюють більшість випадків, і жоден з них не про інтелект.

• Історії без рішення. Опис того, що зробила команда, а не того, що обрали ви. Нотатки залишаються без доказу, прив'язаного до вашого імені.
• Немає результату. Історія, що закінчується моментом запуску проєкту, без жодного слова про те, чи спрацював він.
• Матеріал закінчується. Повторне використання того самого проєкту в чотирьох раундах, що видно на дебрифі, навіть якщо жоден окремий інтерв'юер цього не помітив.
• Мовчазне розв'язання задач. Проходження задачі з коду без озвучення міркувань, через що інтерв'юеру нічого записати.

Варто прямо сказати, що здібних інженерів тут відхиляють з причин, які не мають нічого спільного зі здібностями, включно з відповідністю команді та складом панелі того дня. Підготовка змінює шанси; вона їх не гарантує, і відмова — не вирок вашим здібностям.