Amazonのソフトウェアエンジニアの面接を受けて落ちた。学んだこと
カナダでレイオフされ、現在求職中である中、先日、ありがたいことにカナダでAmazonのSoftware Engineer 2 (SDE2)のポジションの選考プロセスをフルで経験する機会があった。結果は不採用だったが、貴重な経験であり、多くを学んだため、そのメモを残したい。
この記事の目的
この記事の主な目的は以下の二つである。
将来の自分のため。これを見直し、他の会社の選考プロセスに役立てるため。
他の人のため。同じように受ける人にとって、少しでも役立つ情報を提供すること。
この記事の内容としては、以下の項目を記載している。
インタビューの形式
実際のインタビューの様子と、それに対する感想。
インタビューで自分が良かった点(対策)と改善点。
Amazon特有の部分もあるが、大部分は他の中ー大企業にも共通すると思ってる。またBehavioral Questionsの部分とかは、Techの人関係なく、共通すると思ってる。
インタビューの流れ
具体的な振り返りをする前に、Amazonの選考プロセスがどんな流れか、どんなことをやるか簡単に説明したい。結構大企業だとどこも似たようなものだと思ってる。
簡単にいうと
書類選考
OA (Online Assessment)
Onsite (対面) インタビュー
になる。
書類選考
応募自体は他の企業と大きく変わらないが、Amazonは内部の人の情報によると、Requirements / Qualificationsの部分をかなり厳しく見られる。特に、Job descriptionに記載されている「学歴や○年以上の経験」を少しでも満たしていないと、選考の初期段階で弾かれると聞いている。なので2024年現在、「条件を満たしていなくてもとりあえず応募する」という手法は効果が薄い。幸運にも、今回リファラルを使える機会があったので、それを利用した。周りではリファラルを使っても次の選考に進めなかった人もいれば、リファラルなしで次の選考に進んだ友人もいた。リファラルは確かに有利だが、まずは要求されている条件をしっかり満たすことが重要だと感じた。
Online Assessment (OA) -> 受かった
次はオンラインアセスメント（OA）。簡単に言うと、メールで届いたリンクからアクセスし、時間内に問題を解く形式。対面でのインタビューはなし。所要時間は合計で約2時間ほど。構成は以下の通り。
LeetCode系のコーディング問題が2問。合計90分。
Work Simulation。
Work Style Assessment。
後半の2つは時間制限がなく、通常は合計で30分程度で解けるらしいが、僕は丁寧に取り組んだため、1時間ほどかけた。
LeetCode系の問題はMediumレベルが2問。UIやシステムは典型的なHacker Rank系のもの。各問題にテストケースが20個ほど用意されており、提出前にどれだけテストケースをパスできたか確認可能。僕の友人やネットの情報では、テストケースをすべてパスできなくても（TLEが理由）、次の選考に進んだ人がいるとのこと。最適解でなくても、諦めずにとりあえず提出することが重要。
２つ目のWork Simulationは https://www.jobtestprep.com/amazon-assessment-test をみたらわかりやすい。こういうメールが来たとき、どう対処/回答する？という選択肢式の問題になる。結構面白かった。SDEの場合は、どういうDB使ったらいい？みたいな選択肢もあり、結構AWSの資格と似てた。
３つ目のWork Style AssessmentはWork ethicの選択肢系の問題。
3つ目のWork Style Assessmentは、Work ethic（仕事に対する姿勢）に関する選択肢系の問題。正直、こういった問題でよく言われるのは以下のポイント。
中間の選択肢ではなく、はっきりとした選択肢を選ぶこと（右端か左端）。
回答を統一させること。同じような質問が言い方を変えて繰り返されるので、前回の回答と一貫性を持たせることが重要。
特にAmazonの場合、Leadership Principlesという理念があるので、それに沿った回答をすることが求められる。
正直に言うと、僕の回答はボロボロだったと思うが、最終的に合格したので、アルゴリズムの問題で2問ともすべてのテストケースをパスしたことが評価されたのかもしれない。
また、人によってはresumeが通過すると、このOAの前にAmazonのリクルーターから連絡が来る場合もある。僕の場合、なぜか連絡がなく、単純にOAの案内メールが届いただけだった。
Onsite (対面) インタビュー -> 受からなかった
次が最後のインタビュー。オンサイト（Onsite）と言われるが、実際にはすべてオンラインで行う。とはいえ、対面で行うインタビューと考えておくのが良いかもしれない。
インタビューは全部で4回あり、1回のインタビューは1時間。驚くことに、各インタビューではBehavioral questionとTech interviewを毎回同時に行う。これが非常にしんどい。構成は以下の通り。
Behavioral question 20-30分 + Data Structure and Algorithm 30-35分 : 2回
Behavioral question 20-30分 + High Level Design 30-35分: 1回
Behavioral question 20-30分 + Low Level Design 30-35分: 1回
見ての通り、他の企業と異なるのは、Behavioral questionが非常に長く、内容が重いこと。そのため、Tech interviewの時間が短くなっている。一般的なTech interviewでは45-50分ほど時間が確保されるが、Amazonではそれが短縮されているのが大きな違いだと感じた。
インタビューは1日にまとめて行うことも可能だし、2〜3日に分けて行うこともできる。友達は複数日に分ける選択肢が与えられなかったと言っていたので、これはリクルーターの裁量によるかもしれない。もし分けたい場合は、リクルーターに相談してみるのも一つの手だと思った。
Tech interviewで聞かれる内容自体は、比較的一般的なものが多いと感じた。特別にひねったものではない。ただし、後述するように、問題が意図的にかなりアバウトに作られているため、それを具体化する作業が負担になる。
用語説明
Data Structure and Algorithm (DSA)
DSAと略されることが多く、いわゆるLeetCode系の問題を指す。
High Level Design (HLD)
上位の設計、つまりSystem Design (SD) とも呼ばれる。サービスを作る際に、データベースやサーバーをどのように設計し、どう連携させるかを考えるもの。HLDやSDと略される。
Low Level Design (LLD)
HLDよりも具体性が増した設計。HLDがシステム全体を考慮するのに対して、LLDでは特定の部分に注目し、どのようにコードを書くかを考える。範囲は広く、Parking Lotの設計のようなオブジェクト指向設計 (Object-oriented design, OOD) を求められる問題や、APIのサーバーサイドの関数を定義する問題などが含まれる。
注意すべき点として、問題によっては、その設計の中でDSAの要素も求められることがある。例えば、ファイル検索システムの設計ではBFS（幅優先探索）を使用するなど。
またフロントエンドでよく見られるような「実際のAPIを使ってログイン機能を実装する」といったリアルコーディング＆ビルドほどの具体性はなく、あくまで設計の範囲内に留まることが多い。ややこしいので、企業がどのような問題を出すかを事前にリサーチすることが重要。
Leadership Principles (LP）
全社員が大切にすべき16項目の行動指針。採用選考をする際にも重視している。
さてここからは個人的な振り返りになる。実際どうなったか、それに対する今後どうしたらいいかをメモしていく。
振り返り / Behavioral Questions
何度も言うけど、本当に大変だった。特に以下の3点。
Leadership Principles (LP)に沿って回答しなければならない
LPの数が多い
回答を非常に深堀りされる
LPに沿って回答
ここがAmazonのインタビューで他の企業と大きく異なる部分。Amazonには「行動規範」としてLeadership Principles (LP) というものがあり、すべての従業員がこれらに沿ってリーダーシップを持って働くことが求められている。
特に厄介なのは、Behavioral QuestionsがすべてこのLPに基づいて行われ、候補者もそれを考慮して回答しなければならないこと。
例えば、以下のような質問をされたとする。
「Tell me about a time when you had to make a decision with little data or information.」
こんな質問をされたらそもそも「そんな経験ある…？」と戸惑うかもしれない。仮にあったとしても、「気合でデータを集めて成功させました！」「データが揃うまで粘って成功させました！」という答えは適切ではない。
この質問は、LPの中でも「Bias for Action」に該当し、背景には「ビジネスでは、不十分なデータや情報でも製品をリリースしなければならないことがよくある。その中で、どれだけ論理的な思考プロセスを持ち、リスクを計算・回避しつつ、素早く強い決断を下せるか」という能力を求められている。
したがって、適切な回答の方向性としては、「代わりに不完全ながら似たようなデータがすぐに手に入ると分かった。納期の遅れによるデメリットが大きく、新たに得られるデータで補完できることが判明したので、多少不完全でも速さを優先してリリースを決断した」のほうが良い。
これらの回答は適当に作り上げたもので、抽象的な部分もあるが、重要なのは、聞かれた質問の裏にあるLP、そしてその背後にある「何を求めているのか」を推測し、それに沿った自分の経験談をピックアップして回答することだと思う。
LPの数が多い
また、LPの数が非常に多い。現在、LPは16個も存在する。基本的にSoftware Development Engineer (SDE)に関連するのは12個程度で、4つは除外できるが、それでも数は多い。そして、各インタビューでは2つのLPに基づいた質問がされるため、4つのインタビューで合計8つのLPについて聞かれることになる。したがって、最低でも8つのエピソードを用意しておく必要がある。とはいえ、何が聞かれるか分からないので、結局12個のエピソードは準備することになる。
「エピソードを複数の回答に再利用すればいいのでは？」と思うかもしれないが、体験談は基本的に被らないようにするべき。例えば、1つ目のインタビューで「あるプロダクトのLogin画面の実装」というエピソードを話し、別のインタビューで同じ題材を使った場合、後日、面接官たちはみんなで内容を集めて採点するため、エピソードが被ると「この人、同じ経験ばかり話してる。経験が浅いのかな」と評価されるリスクがある。僕のリクルーターは、同じエピソードを使うのは被っても１回が限度だと言っていた。
さらに、Bias for Actionに関する質問だからといって、いつも同じ定番の質問が来るわけではなく、以下のように何個かの種類がある。
8～12個の経験談を用意し、質問された内容がどのLPに関連しているかを予測して、それに合ったエピソードを引き出す。そして、一度使った話は再利用しないという作業は、インタビューの前後やインタビュー中において非常に負担が大きかった。
程よい要約バランスが必要
肝心のエピソードについては、程よい具体性が求められる。抽象的な話は好まれない。基本的には、STARメソッド（Situation, Task, Action, Result）と呼ばれる方法で話を展開し、具体的な内容を伝えることが推奨されている。
しかし、僕の場合、相手が状況をきちんと理解できるようにと、各項目を丁寧に説明しすぎてしまい、話が非常に長くなってしまった。結果として、相手が退屈しているのが分かってしまったので、もう少し簡潔にまとめるべきだったと感じた。STARメソッドを用いる際でも、ある程度の要約が重要だと学んだ。
かなり深堀りされる
1回のインタビューでは、Behavioral Questionsに30分ほど時間を割くこともある。2つのLPに基づいて質問がされるため、1つの質問に対して10〜15分程度、深く掘り下げられる可能性がある。特に、インタビュアーがシニアやリードポジションの場合、この傾向が強い。
多くのエピソードを用意するあまり、1つ1つのエピソードが適当になったり、盛りすぎた場合、深堀りの際にボロが出てしまうことがあるので注意が必要だ。
では、どのように掘り下げられるのか。以下に、インタビュー全体を通じてよく聞かれた質問をリストアップしてみた。
明確で具体的な数字とデータの提供
例: 納期に関して「あと何週間後に納期があったのか」、「リリースを何週間（何日）早めることができたのか、または遅らせざるを得なかったのか」
機能改善に関して「その改善で何の速度が何ミリ秒改善したのか」、「開発プロセスが何分早くなったのか」など
エピソード内での候補者および周りの責任範囲、理由
STARメソッドにおけるT（Task）、A（Action）への深掘りに近い。
例: 「そのエピソードにおいて、あなたはどのようなポジションにいたのか（ManagerやLeader的な存在だったのか、中堅的なポジションだったのか）」
「あなたはなぜその行動を取ったのか？それはもっと高いポジションの人が行うべきではなかったのか？その時、あなたより高いポジションの人は何をしていたのか？」
改善案、代替案の考察（結果からの学び）
STARメソッドにおけるR（Result）への深掘り
例: 「あなたは●という行動を取ったが、▲という選択肢は考えたのか？なぜ●を選んだのか？」
「あなたは●という行動を▲の代わりに行ったが、どういう状況であれば▲の方が適切だと思うか？」
「同じ状況が再び起こった場合、同じ行動を取るか、それとも別の行動を取る可能性はあるか？」
これらの質問に備え、具体的なエピソードを用意し、数字やデータを含めて詳細に説明できるようにしておくことが重要だ。また、深堀りに耐えうるしっかりした内容を準備することが求められる。
WeとIの罠
Behavioral Questionsを振り返っていて、「エピソード内での候補者および周りの責任範囲、理由」関連でなぜつまずいていたのかがわかった。それは、WeからIへの変換である。面接でよく言われるのが「Weを使うな。自分がやったことをアピールするためにIを使え！」というものだ。これは正しいが、ここには罠がある。この変換は、自分が率先して行った成果については問題ない。むしろ、絶対にIを使うべきだ。しかし、チーム全体で協力して行ったことや、上の立場の人が関わっていないと成り立たないケース、例えば「無茶なビジネスサイドの要求をテックチーム全員で押し返した」といった場合、これを安易に「私(I)がビジネスサイドの要求を押し返した！」と言うと、「それってシニアやリードの仕事では？他の人たちは何をしていたの？あなたが本当に貢献した部分は何？」と突っ込まれる可能性がある。もちろんWeを使えと言っているわけではない。Iの言い方に気をつけ、突っ込まれたときにきちんと答えられるように準備しておくことが重要だと思った。
✨ 改善策 / 対策
✅ 相手の質問の本質（意図）を見抜く
今回、質問から対応するLPを推測し、それに対応するエピソードを選択する方法を取ったが、これは非常に大変である。なんなら一部の質問は複数のLPと重複している。最終的には、LPにこだわるよりも、質問の本質を理解し、相手が何を求めてその質問をしているのかを考え、それに対応するエピソードを用意する方が、シンプルでかつどの企業の面接にも役立つ本質的なアプローチだと思った。
Behavioral Questionsのほとんどは基本的に「困難に対してどう対処したか」を聞いていることが多く、質問ごとに「どんな困難」と「どう対処したか」の違いがあるだけである。その差分を見抜くことが重要だと思った。
✅ 回答はシンプルに、準備は入念に
回答はシンプルにまとめることが重要。要は「どんな困難に対して -> なぜ、どうやって対応して -> 結果どうだった」といったテンプレートで答えるのがベストであり、そのためなら回答の方法はSTARメソッドでも他の方法でもよい。
重要なのは返答の準備。なぜその行動を取ったのか、具体的なデータや数字、何を学んだのか、別解の考察（メリット・デメリット）など、しっかりと準備しておくことが必要。
そして、状況に応じて上記の要素を追加で入れる。ただし、最初からすべてを盛り込もうとすると、回答が長くなりがちで相手が飽きる可能性がある。やはり、最初は簡潔に回答し、質問されたら答えられるように準備しておくのが良いと感じた。このバランスは難しく、自分もまだ試行錯誤中。
✅ 会話に少し調味料を
今回、自分に非常に役立ったTIPsとして、会話に少し＋αを加えた回答で柔軟性を持たせることだった。いつも杓子定規に回答する必要はない。
例えば、「Tell me about a time when you had to make a decision with little data or information.」と聞かれた場合。よくやりがちなパターンとして、「やべぇ、そんな経験があった？」と思いつつ、何か答えないと…と焦ってしまい「はい、わたしは過去に…！」と勢いで話し始める展開。頭の中で整理がついていない状態なので、結果として何が言いたいのか分からない無駄に長い話になる。
そんなとき、いきなり回答せず、"hmm,… I wonder what 'little data' refers to in this context. Are we talking about business requirements or user action data? My I define it as business requirements?"とか、"I don't have an exact experience with that, but I do have a similar one where I had to make a decision within a short timeframe. If that's acceptable, I can share it with you."と、質問を明確にしようとしたり、最悪、自分が回答しやすい方向にすこし再定義していくのが有効だった。
こうすると時間を稼げるし、質問が明確になるし、かつ回答しやすい方向に持っていける。質問通りの経験がなくても、回答できる可能性が高まる。
また、経験談に対しても、完璧な成功談よりも、ちょっとしたつまずきや現実味を加えることで、興味を持ってもらいやすい。「最初は上手くいかなかったんですよね…」とか「それでも話は受け入れられなかったんですよね…w」とすること。親近感も湧きやすい。完全な成功談を求めているわけではない。だからこそ、「そこから何を学んだか、次同じ状況ならどうするか」という質問が後で来る。
ただこれも意識しすぎると回答が長くなりがちなので、バランスを気をつけて。
ここらへんのテクニックはほぼこの動画から学んだ。この動画はまじでbehaviral quesitons に関するコツを多く語ってるので、ぜひおすすめを。そして作成してくれたことに感謝したい。
https://youtu.be/CxqIbGnEjPg
✅ 自分のやったことを定期的に記録
今回の準備で最も苦労したのが、エピソードの洗い出し。エピソードはすぐに枯渇し、まず思い出せない。思い出せても、具体的なデータに関する数字や詳細な情報は忘れていることが多い。以前のレイオフの記事でも述べたが、定期的に自分のやったことを記録しておくことが重要。
例えば単純に、月1回でもエピソードを残しておけば、1年で12個のエピソードが蓄積される。なんならそのリストをそのままChatGPTなどに入力し、「○○の質問をされたとき、このリストの中から選んでSTARに沿った回答を作ってください」と頼めば、準備が非常に楽になる。
振り返り / DSA
Techサイドの振り返りに移る。実際のDSA（Data Structure and Algorithm）のインタビューは、LeetCodeの形式とはかなり異なり、十分なパフォーマンスを発揮できなかった理由の一つだ。
では実際どれくらい違いがあるのか？
例えば、LeetCodeで定番の問題であるTwoSumを例に挙げる。LeetCodeでは、問題文が簡潔で、ExampleやConstraints（条件）、Test環境まですべてが揃っている。
では、これがリアルインタビューだと以下のように提供される。
こういう問題文がテキストエディタに貼られるだけで終わり。Runやbuild、コード補完のIDE的なもは何もない。候補者はここから問題を明確にし、条件を考え、テストケースやfunctionを含め、入力と返り値を自分で定義しなければならない。例えば、答えのペアは一つだけか、複数になる可能性があるのか、結果をArrayで返すのか、HashMapで返すのか、そういった点を面接官と確認しながら決めていく。これをすべてテキストエディタだけで進める。この時点で、LeetCode系の問題よりも追加でやる作業があることがわかると思う。
その上でメインのアルゴリズムを考え、計算量を分析する。もちろんrun環境はないため、コードを書いてもその場で正確に動作するか判断しにくい。多少のsyntaxエラーは許容されるが、アルゴリズムが正しいかどうかを判定するのが難しく、実際にテストケースに対して期待する結果が得られるかは、自分で口頭で入力値がこれに対して、ここではこう変換されて…とデモをして確認することになる。
もちろん、すべての企業がこのスタイルではなく、微妙に違いはある。例えばAmazonでは完全に素のテキストエディタを使用する。YouTubeでも他の企業のインタビューを見ると、同様のスタイルをちょいちょい見かける。一方で最低限Runする環境はある、という企業もある。
アルゴリズムの説明に関しても、基本的にはテキストエディタのみで自身のコードの説明をすることが多い。今回は面接官がexcalidrawのようなサービスも使っていいよ、言われリンクを渡されたのでありがたかった。
これもやはり重要なのが、インタビュー前、開始時にどういう環境でコーディングインタビューをするのか、説明のためのツールは何が使えるのか積極的に確認することだ。
Amazonの場合、本当に素のテキストエディタ（note pad）のような環境と、2〜3文の問題文が渡されただだけだった。そのため、そこからすべて自分で定義し、説明する必要がある。Initiative（自発性）とコミュニケーション能力が非常に重要視される。
参考までに、以下の動画が実際のインタビューと近く、イメージがつきやすい。問題文は最初から抽象化されている方だが。
僕がやったミス
DSAについては自信があったのだが、正直、今回は大きなミスをしてしまった。アルゴリズム（手法）が本当に正しいか検証が不十分なまま実装に入ってしまい、終盤で間違いに気づき、修正する時間が全然なかったのだ。
LeetCodeなどをやっていると、思いついた解法をとりあえずサクッと実装し、runして正誤判定をする、という習慣がつきやすい。しかし、リアルインタビューでは実装前の解説や、実装自体も話しながら進めるため、時間がかなりかかる。その後の正誤判定も、runで一発で確認するのではなく、自分で一つ一つ「この入力値が来たら、ここでこうなって…」とデモしながら確認するため、さらに時間がかかる。このため、アルゴリズムが間違っている場合、それに気づくまでにかなりの時間を費やす可能性が高い。この点を考慮していなかった。
優しい面接官なら、早い段階で「このテストケースならどうなる？」といったヒントを出してくれ、間違いに気づかせてくれることもあるかもしれないが、僕の場合はそうではなかった。やはり、早めに自分で気づく必要があるのだと痛感した。
✨ 改善策 / 対策
✅ 正誤の確認を早めに
限られた時間を有効に使うには、やはり最低でも実装前に正しい方向性を見極めておくのが重要。まずはInterpretationの部分をしっかり行う。ここで問題の定義、何が求められているのか、何をやるべきか、という最初の方向性を間違わないようにはっきりさせる。その後、手法に対してPseudocodeやAnalysis（計算量の分析）を行う。
そして実装に入る前にテストケースを使って軽くデモして確かめる。ここで間違いに気づけば、実装パートでの時間の無駄を防ぐことができる。実装後にデモを行って大きな間違いに気づいてしまうと、修正の時間が足りなくなる。僕は覚えやすいように、この流れを勝手に「IPAD」と名付けた。
I: Interpretation
P: Pseudocode
A: Analysis
D: Demonstration
LeetCodeやOAでは結果で判断されるため、実装パートが一番重要になるが、対面のインタビューでは実装前の準備がある意味で最も重要になる。実装に時間が足りなくても、上記の要素をしっかり行っていれば、それが大きな加点につながることが多い。なお、AmazonではPseudocodeだけではなく、実際のコードを完了させることが求められたが…
振り返り / HLD
正直、問題のレベルや形式に関しては、既存のネットに載っているものとそれほど変わらなかった。圧倒的に時間が短いことを除いて。通常は45分ほどあるが、Amazonでは30分しかなかった。
今回HLDについてもかなり対策をしたが、結果としてまだ実力不足を感じた。対策したもの以外の質問をされると、途端に答えられなくなることがあった。これには三つの原因があった。
Contextの理解不足
柔軟性の不足
実務経験不足
Contextの理解不足
大前提として、その設計したいサービスがどんな流れで、どういう状況で、何の目的で誰に使われるのかを把握していなかった。
言い訳だが、前のインタビューが押していて、ただでさえ短い時間がさらに短縮されたこと、さらにHLDをいきなりやると言われたこと（メールの順番的にDSAが来ると思っていた）、そしてBehavioral Questionsが非常に重く、時間も脳内エネルギーも消耗していたのが原因だ。結果として、何が求められているのかが不透明なままになっていた。
よくあるSDの問題として「TwitterやDropboxを設計せよ」といった既存のサービスを題材にした問題であれば、このContextが自動的に補完されるため、見落としても進めてしまえる。しかしリアルインタビューでは会社のドメインに沿った特定の背景の問題が出る可能性がある。あるドメインにある機能を追加したい、など。今回はこのContextの把握をおろそかにしていた。
柔軟性の不足
完璧主義が災いし、「●がきたら■と答える」といったパターンやテンプレートに固執しすぎた。少しでも変化球が来ると、どうしたら良いのか焦り、答えに詰まることが多かった。
実装経験不足
APIのデザインでも、受け値や返り値の細かい部分で「なぜその形にしたのか」「なぜこちらではなくそちらを選んだのか」と突っ込まれると、APIの実装経験が浅いため、詰まることが多かった。
✨ 改善策 / 対策
✅ 設計するサービスのContextをはっきりさせる
誰が、なぜ、何をしたくて、どういう規模でそのサービスを作りたいのか、明確にする。前述のとおり、この部分をしっかり把握することで、実装した機能も「ユーザはまずこうするだろう、こうしたいだろう」といったベースに基づいて展開でき、機能の定義や細かい部分の要求、どのような状況下で負荷がかかりやすいかを想像しやすくなる。
当たり前の部分だが、SDを勉強していると多くの教材がInstagram、Uber、YouTubeなど既存のサービスを題材にしているため、この「Why this Service?」の部分を掘り下げることを見落としやすい。
✅ ボトルネックや重要なポイントを意識する
これもBehavioral Questionsと同じく、インタビューで聞かれる題材には、面接官が特に注目しているボトルネックや重要なポイントがある。例えば、Twitterの設計では「有名人に対するFeedの作成」といった部分が該当する。こうした意図を意識して答えられるようにすることが重要だと感じた。
✅ Server (Backend) の実装経験を増やす
現在の個人的な課題。これは自分を含め、多くの人が苦労している部分だと思う。特定の分野の経験を増やしたいが、その仕事をするにはその経験が必要というジレンマ。
振り返り / LLD
同様にContextの理解不足
LLDでも同様にContextの把握が不十分だった。どういうシチュエーションで、なぜそのサービスが必要なのかを曖昧にしか理解していなかった。「これを実装してね」と言われて焦り、何をしたいのかはなんとなくわかったものの、なぜそれをしたいのか、状況がよく把握できないまま進めてしまった。結果として、後半になるほど細かい部分での決断に迷うことが多かった。
LLDの定義は広い
Low Level Design (LLD) は、その定義が非常に広く、どういうことをやるのかがわかりにくい分野だと思う。実際、僕も受けるまで具体的に何を求められるのかが不明瞭で、結局会社によって異なる部分が大きい。
LLDを調べると、Parking LotやTic-Tac-Toeの設計、クラスの定義、UML、デザインパターンの使用などがよく挙げられている。しかしこれは厳密にいうと、Object-Oriented Design (OOD) であり、OOPを使った設計に当たる。僕が今回勘違いしていたのは、LLD == OODであり、OOPを使わなければならないと思っていたこと。しかし、実際にはLLDという広い範囲の中で、OODがその一部を占めているに過ぎない。
さらにビジネスロジックの部分にアルゴリズムを組み込むのが主流だが、
それ以外の可能性の考慮も大切
つまり、LLDだからといって必ずしもOOPを使い、インタフェースやデザインパターンを駆使する必要はない。実際、今回のインタビューではAPIのfunction設計に近いことが求められ、インタフェースを定義してクラスを作ろうとしたところ、「インタフェースは無視してもいいよ」と言われたり、「アルゴリズムはそこまで考えなくてよい」といった指摘を受けたりした。
一方で、エラーハンドリングについてはかなり深く議論した。成功の場合とエラーの場合、それぞれどういう値をどういう形で返すべきかについて話し合った。本当に会社と相手によって何を見られるのかは異なる。確認重要。
✨ 改善策 / 対策
✅ 設計するサービスのContextをはっきりさせる
これは前回と同じ。まず、設計するサービスのContextをしっかり把握する。
✅ 相手が実装で何を求めているかを明確にする
LLDの範囲は広い。相手が実装で何を重視しているのかを明確にし、それに応じた対応をすることが重要。OOPが求められているのか、Functional Programmingが求められているのか、アルゴリズムの部分を重視しているのか、APIの入力や出力、ファイルや関数の分割、DBとのやり取り、エラーハンドリング、デザインパターンの適用か、何をこだわって実装し、何を省略するかを都度確認するのが大切。
また、その会社がどのような形式で問題を出すかを事前に調べておく。これはLLDに限らず、すべての面接に共通する対策。特にLLDではそれによってスタイルが大きく変わる可能性があるため、必ず事前のリサーチが重要。
振り返り / 環境面
その他の細かい改善点や、やってよかったものを挙げる。個人の好みレベルだけど。
✨ 改善策 / 対策
✅ セカンドモニタの活用
今回セカンドモニタを用意して、これ自体は非常に役立った。正直、相手の顔、問題、メモを全て１画面に移すのは情報量が多すぎる。
一方で相手の顔をセカンドモニターに表示していたため、相手の顔を一生懸命見て話していたつもりでも、相手には僕の横顔しか映っていなかった。
正直、普段であれば来にしなくても良い内容。無礼とかも関係ない。あとCoding中であれば相手もコードしか見ていないので正直関係ない。ただインタビューで初対面で、Behavioral Questionsなどでお互いの顔を見れる場面で、候補者がずっと横向きで話していると、相手に対する印象よくないんじゃないかなぁと感じた。なにより自分は相手に向かって、真正面で話しているのに、自分の横顔が画面に映るのは違和感があり、集中できないことがあった。
✅ 複数の面接は間には必ず休憩時間を
これは非常に重要な点で、今回僕は面接を休憩なしで連続して行ってしまった。たとえば、2pm-3pm, 3pm-4pmのように。
このやり方のデメリットは、候補者が休憩できないだけでなく、一つ目の面接が全く延長できず、もし延長した場合、次の面接が短くなってしまうことである。面接官によってはインタビューを5〜15分延長してくれる。この数分というのは非常に大きく、その時間で挽回できる可能性もある。
今回、僕の場合はきっちり1時間で終わる必要があり、最初のインタビュー終わりにはいつも次の面接官からメッセージが来てて「次が始まる！」と焦ってしまい、非常に良くなかった。できればインタビューの間には30分程度の休憩時間を設けるべき。
✅ インタビューの環境、形式をできるだけ事前に把握しておく
当たり前のことだが、インタビューまでにできるだけインタビューでの環境やスタイル、何を聞かれるのかを事前に把握しておくことが重要。例えば、今回のTech interviewはすべて素のテキストエディタと描画ツールを使用し、run環境は全くなかった。これを知らずに、いきなり本番で直面するのとしないのでは大きな違いがある。
調べる方法としては、素直にリクルーターやHRにどのような形式で行われるのかを聞くのが良いと思う。内容は無理でも、コーディング環境やスタイルについては積極的に聞いてOK。また、ネットでもRedditやLeetCodeのディスカッション項目、Glassdoorのレビューには過去問や経験談が結構載っているので、調べる価値がある。
ただし、調べた情報と実際のインタビュー環境が異なる可能性もあるので、その心構えも持っておくことが大切。
✅ リクルーター / HRを有効活用
前項目と被るが、インタビュー前にはできるだけ情報を搾り取るべきである。リクルーターやHRに嫌われたくない、いい顔をしておきたいという減点主義的な考えから、質問や要望を遠慮してしまう必要はない。特にリクルーターは、担当する候補者が採用されることで自らの報酬につながるcommission制であるため、むしろ積極的に協力してくれるはずである。また、今回、たまたま友人が同じ時期にアマゾンで選考プロセスを進めていたが、私の担当リクルーターと友人のリクルーターで、与えられる情報量にかなりの差があった。まさにリクルーターガチャである。リクルーターが最初に与える情報が全てではないので、積極的に質問すべきである。
✅ コーヒーは不要
完全に個人の感想。日常生活でやる気を出すためにコーヒーは役立つが、インタビューでは自然にアドレナリンが出るので、コーヒーはオーバーキル。心臓がバクバクするだけでなく、尿意も増してしまうし…
振り返り / 全体
最後に全体を総括して振り返ってみる。
完璧主義!
今回のインタビューに全力を注ぎすぎた結果、メンタル的に完璧主義と神経質になってしまった。
最初は「やれることは全部やろう」という意気込みだったが、次第に「これをやらなければダメだ」という思考に陥り、少しでも準備が足りないと感じると強い焦りを感じるようになった。食事や睡眠、運動の準備を徹底し、インタビュー用にWeWorkで部屋を借りたり、新しいイヤホンを購入したりと、過度に準備をした。しかし、一つでも準備が不十分だと感じると不安になるのは本末転倒になってた。
この完璧主義の影響は、インタビュー中にも現れた。まず、うまく答えられなかったときに強い焦りを感じたこと。すべてを完璧に答える必要はないのに、失敗を許容できなかったことが焦りを生んだ。また、インタビューの進行が予想通りにいかないときにも同様の焦りが生じた。自分が準備したテンプレートはあくまで補助であり、インタビューはディスカッションであることを忘れていた。
さらに、面接官にも完璧を求めてしまった。Amazonという大企業であるため、面接官にも理想的な対応を期待してしまい、適当な対応や高圧的な態度の人にあたると意気消沈し、それがパフォーマンスに影響を与えた。どこにでもそういう人はいるものだと割り切るべきで、相手も人間であり、完璧ではないという現実を受け入れるべきだった。
Techパートの時間が本当に短い
前述の通り、AmazonのTechインタビューの時間は非常に短い。通常、1時間のインタビューでは最初の5〜15分が自己紹介や軽い質疑応答に充てられ、残りの45分がTechパートに割り当てられる。しかし、AmazonではTechパートがわずか30〜25分しかない。予想していたとはいえ、実際にやってみるとその短さに焦りを感じた。もし間違ったまま進んで後から気づいた場合、やり直す時間がなく、そのまま終了してしまう。また、前半のBehavioral Questionsが重く、Techパートに進む頃には脳がかなり疲弊していた。
問題定義がタフ
これも各パートで述べたように、問題文を渡されてから、結局何を解くのか、どこに注力すべきかを見つけるのが非常に大変だった。これは企業が意図的に問題文を曖昧にして、候補者が自分で要件を正しく定義できるかというスキルを見ているためである。
大体は100〜150ワード程度の文章と、簡単な例が付いた程度の問題文が渡されるだけ。そこからスコープ（解決したい範囲）を優先順位を含めて考え、inputやoutputの値や形式を自分で定義していく作業が必要になる。SD系の問題ではこれが一般的だとわかっていたが、DSAやLLDでも同様にこれが求められた。特に、30分くらいがっつりBehavioral Questionsを聞かれた後に、10分程度で問題の定義を行うのが大変だった。
✨ 改善策 / 対策 まとめ
ということで、さまざまな改善策を書いてきたが、最終回には以下の点が重要だと感じた。なんだかんだ結局王道なものに落ち着く。
✅ 完璧主義にならない
自分にも相手にも寛容であることの重要性
自分が対策したトピックや質問がそのまま同じように聞かれることはない。その場の会話と流れに応じて柔軟に対応することが重要
回答の仕方やインタビューの進め方のテンプレートは重要だが補助にすぎない。頼りすぎないこと。最終的には相手とのディスカッションが本質
✅ WhyやWhatの意識
相手が何故その質問をしているのかを意識
その質問で自分に対してどういうものを求めているのかを考えること
なぜそのサービスや問題解決をやりたいのかを理解
✅ こまめに面接官と確認
間違いはOK。なるべく早い段階で気づいて時間ロスを減らす
「問題の解釈、問題のスコープのミス、解決法のミス、どうでもいい部分」など
こまめに面接官と方向性、整合性、優先順位を確認すること
恐れずに質問し、都度確認する
参考文献
今回僕が今回情報集につかったものリンクを張っておく。
Behavioral Questions
とりあえずこれ。まじ有用。
過去問、経験談
LeetCode
大量の過去問と経験談が落ちてる。ある意味LeetCodeの真の価値がここにあると言えよう。https://leetcode.com/discuss/interview-question
GlassDoor
ここのレビューも情報落ちてる。
https://www.glassdoor.com/
Reddit
とりあえず、「気になる内容」 + redditで調べると幸せになれる。
DSA
NeetCode神
HLD
Alex Luの書籍以外にこの２つをめちゃ参考にした
おわりに
今回のインタビュー内容を振り返った。「回答をシンプルに」と思いつつ、この記事は少し長くなってしまった。
いろいろ書いたが、正直なところ、一番の課題はインタビューにたどり着くまでの過程である。今回の反省点は、数をこなすことで改善可能なものであり、Techの内容も基本＋αの範囲で、超難問ではなかった。しっかりと勉強すれば対応できる内容であり、問題は特殊な環境下での慣れだけである。したがって、試行回数が重要であり、Resumeを通過させることが大きなボトルネックとなる。リファラルの重要性を改めて感じ、挑戦回数を増やしていきたい。
またリファラルを提供してくれた友達、一緒に準備をしてくれた友達、Amazonのリクルーター、そして面接官の皆様に心から感謝している。今回の経験を通じて、さまざまな視点から多くのことを学ぶことができ、非常に有意義な時間となった。これらの支えがあったからこそ、多くの成長を実感できたと感じている。
この記事を読んでいただいた方の採用確率が少しでも上がり、みんなでリファラルしあえるようになれば幸いである。
この記事が気に入ったらサポートをしてみませんか？