Amazonの面接はどれくらい難しい？
文責 Aaron Cao · 更新
難しさの正体はパズルの難易度ではなく構造にある。すべてのラウンドでスキルと同時にLeadership Principlesが評価され、回答は記録されて面接官同士で比較され、チーム外から来るBar Raiserがチームの望む採用をブロックできる。
本当に難しいのは何か?
アルゴリズム問題をひたすら解いてきたのに、まだ準備不足だと感じているなら、その直感は正しい。この節では、追加の難しさが何でできているのかを説明する。それは問題そのものではなく、問題をもっと解いても解決しない。
Amazonは構造化された面接プロセスを採用している。面接官には調べるべき特定のLeadership Principlesが割り当てられ、会話中に詳細なメモを取り、そのメモは後のデブリーフで突き合わされる。ここから二つの結果が生まれる。その場では悪くないと聞こえた話も、決断も結果もなければ紙の上では薄っぺらく読める。そして同じ話を二つのラウンドで違う細部とともに語ると、メモを突き合わせた瞬間にそれが露見する。
もう一つの難しさの原因は、行動面接のハードルが技術ラウンドにも適用されることだ。コーディング問題をきれいに解いても、マネージャーと意見が対立した経験を語れない候補者は、純粋な技術面接なら決して測らなかった要素で不合格になる。
Bar Raiserは何をしているのか?
Bar Raiserは採用チームの外から来る、この役割のために訓練された面接官で、その仕事はあなたがそのレベルの既存メンバーの平均を引き上げるかどうかを判断することだ。彼らはチームが今四半期に人手を必要としているかどうかを評価しているのではなく、採用マネージャーが望む採用をブロックすることもできる。
実際には、あなたの結果を決める人物がそのポジションを埋めることに何の利害も持たないということを意味する。緊急性はあなたの助けにならず、マネージャーとの相性も助けにならない。役に立つのは、書き留められ、あなたに会ったことのない誰かに読まれても崩れない証拠だ。
どの面接官がそうなのかは普通わからないし、それは重要ではない。すべてのラウンドを、後で見知らぬ人に読まれるつもりで答えるべきだ。実際にそうなるのだから。
現実的な準備量はどれくらいか?
作業を分けて考える。技術面は馴染みのある方だ:データ構造、アルゴリズム、そしてミッドレベル以上ではシステム設計。不合格になった候補者の多くは、ここで失敗したわけではない。
行動面接の方には、Leadership Principles全体にマッピングされた八から十二のエピソードが必要で、それぞれに状況、あなた自身が下した決断、そして測定可能な結果が含まれる。一つのプロジェクトから、異なる角度で二つか三つのエピソードを引き出せることもある。結果が数字で存在するなら必ず書き留めておくこと。フォローアップの質問はたいていまさにその数字を求めているからだ。
次に声に出して練習する。九年の経験を持つバックエンドエンジニアは優れたメモを書いていたが、最初の練習では詰まってしまった。話を読むことと、フォローアップの中で語ることは別のスキルだからだ。 /mock-interview での二週間の口頭練習は、もう一か月読み込むよりも話し方を大きく変えた。ループ全体を段階ごとに描いた全体像は /answers/topic/company-interviews にある。
候補者はどこでオファーを失うのか?
その大半は四つのパターンで説明でき、そのどれも知能とは関係がない。
- 決断のないエピソード。自分が何を選んだかではなく、チームが何をしたかを語ってしまう。メモには最終的にあなたの名前に結びつく証拠が何も残らない。
- 結果がない。プロジェクトが完了した時点で終わる話で、それがうまくいったかどうかには触れられていない。
- ネタ切れ。同じプロジェクトを四つのラウンドで使い回すと、一人ひとりの面接官には気づかれなくても、デブリーフでは見えてしまう。
- 無言の問題解決。思考過程を語らずにコーディング問題を進めてしまい、面接官には書き留めるものが何も残らない。
有能なエンジニアがここで、能力とは関係のない理由——チームとの相性やその日のパネル構成なども含めて——で不合格になることも、率直に言っておく価値がある。準備は確率を動かすが、それを確定させるわけではなく、不合格はあなたの能力に対する評決ではない。