Питання на співбесіді в Amazon
Автор: Aaron Cao · Оновлено

Співбесіди в Amazon побудовані навколо її 16 Leadership Principles. Майже кожне питання поведінкове, задається як "розкажіть про випадок, коли ви...", і відповідь дається у форматі STAR з конкретними цифрами. Технічні ролі додають раунди кодування та проєктування систем, які все одно оцінюють Leadership Principles поряд із кодом.
Що насправді запитують 16 Leadership Principles?
Ви прочитали список Leadership Principles, і, ймовірно, він прозвучав як плакат на стіні. Цей розділ пояснює, що інтерв'юери насправді роблять з ними, і це набагато конкретніше, ніж здається з формулювання. Кожному інтерв'юеру у вашому циклі призначають підмножину принципів, і він має вийти з кімнати з письмовим доказом, що ви їх продемонстрували.
Саме через це призначення один і той самий цикл може здаватися повторюваним. Один інтерв'юер шукає Customer Obsession і Ownership, інший — Dive Deep і Bias for Action, тож у вас просять іншу історію про загалом схожу територію. Підготуйте набір із шести-восьми окремих історій замість однієї улюбленої і знайте, яким принципам може слугувати кожна історія.
- Customer Obsession. Рішення, яке ви ухвалили, відштовхуючись від клієнта, а не від дорожньої карти.
- Ownership. Щось поза межами вашого посадового опису, що ви взяли на себе, бо воно було зламане.
- Dive Deep. Проблема, у якій ви пішли до сирих даних і знайшли те, що приховувало резюме.
- Have Backbone; Disagree and Commit. Випадок, коли ви заперечили, програли, а потім усе одно виконали.
Які поведінкові питання трапляються найчастіше?
Формулювання залежить від інтерв'юера, але форми повторюються в різних циклах і на різних рівнях.
- Розкажіть про випадок, коли ви взяли на себе щось значуще поза межами своєї зони відповідальності.
- Опишіть випадок, коли ви не погоджувалися зі своїм керівником або колегою. Що ви зробили?
- Розкажіть про найскладнішу проблему, над якою ви працювали. Як ви знайшли першопричину?
- Наведіть приклад випадку, коли вам довелося ухвалити рішення за неповних даних.
- Розкажіть про випадок, коли ви зазнали невдачі або пропустили дедлайн. Що змінилося потім?
- Опишіть випадок, коли ви спростили процес або скоротили витрати, не зашкодивши якості.
Очікуйте більше уточнювальних питань, ніж самих питань. Після вашої історії інтерв'юери запитують, у чому полягав саме ваш внесок, якими були цифри до і після, що б ви зробили інакше і що сказали б про це ваші колеги по команді. Історія, яка не витримує чотирьох уточнювальних питань, звучить як позичена.
Як побудувати відповідь, яка витримає прискіпливі розпитування?
Використовуйте STAR, але розподіляйте вагу так, як це робить Amazon: коротка ситуація, одне речення завдання, більшість часу на дії від першої особи, і результат із цифрою в ньому. "Ми покращили затримку" не спрацьовує. "Я скоротив затримку p99 з 800ms до 210ms, додавши read-through кеш, який витримав трафік Prime" спрацьовує.
Уявіть аналітикиню ланцюга постачання, яка проходить співбесіду на посаду senior. Вона розповідає історію про виправлення прогнозування, і її по черзі запитують, якою була саме її зміна моделі, чому вона обрала цей підхід замість двох альтернатив, якою була частка помилок раніше і що зламалося першим, коли обсяг потроївся. У неї були цифри, тож історія витримала. У її другій історії цифр не було, і інтерв'юер перейшов далі менш ніж за хвилину.
Репетиція цього вголос — це та частина, яку пропускає більшість кандидатів. Ви можете потренувати тиск уточнювальних питань проти AI-інтерв'юера на сторінці /mock-interview, де й виявляється різниця між написаною історією та розказаною.
Де живий асистент вписується в цикл Amazon?
Під час усного відеораунду SubcueAI розшифровує питання інтерв'юера і показує на вашому боці запропоновану структуру — або в оверлеї на робочому столі на macOS і Windows, або в бічній панелі розширення браузера Chromium. Жоден бот-учасник не приєднується до дзвінка, і нічого не вбудовується на сторінку зустрічі. Для поведінкових раундів корисний результат — це нагадування про те, яка з ваших власних історій підходить до принципу, що перевіряється, а не готовий сценарій; цифри все одно мають бути вашими.
Є два чесні обмеження. Якщо технічний раунд переходить на платформу кодування з моніторингом екрана або проктерингом, жива допомога виходить за межі можливого, і такий раунд варто розглядати виключно як перевірку власних навичок. Якщо вас попросять поділитися екраном, усе на вашому екрані стає видимим. Більше про те, як великі роботодавці структурують свої цикли, є в розділі про співбесіди в компаніях, а набори питань за конкретними ролями зібрані в банках питань.