見出し画像

ソフトウェアエンジニアのアメリカ就職体験記（後編）

Frank Wu

Behavior Question


Codingの次に重要なのはBehavior Questionでしょう。日本でお馴染みの志望動機や、なぜ前職をやめたのか、前職で一番挑戦したことは何のか、今までXXといった経験は何でしょうか。という類の質問です。

会社によっては、Coding面接の前に、つまりRecruiter面接で聞かれることもありますし、Coding面接30分＋Behavior30分でHybridパターンや、Behaviorのみで45分や60分というパターンもあります。

準備方法としては、業界で一番Behavior Questionに厳しいAmazonを基準に準備すれば、他の会社は難なく突破するでしょう。Amazonでは、面接の種類に問わず、各面接に30分のBehavior Question時間が設けられます。その中に、如何にLeadership Principleを体現しているかをチェックしています。

その中でも、13-16のは管理職？よりの話なので、主に前の12ヶ条を見るのは良いでしょう。一つのストーリーは複数のPrincipleに当てはまることが多いので、実際は12個のストーリーまで作らなくても良いですが、ここで一つ気をつけたいのは、一つの会社の面接において、同じのストーリーを二回以上話す（違う面接官とでも）ことはなるべく避けたいところです。なぜなら面接官は詳細なメモを取っていて、面接後Debriefというミーティングでメモのつき合わせをしていて、同じ話を何度も何度も出てくることはプラスにはならないです。

  1. Customer Obsession

  2. Ownership

  3. Deliver Results

  4. Earn Trust

  5. Invent and Simplify

  6. Are Right, A Lot

  7. Learn and Be Curious

  8. Insist on the Highest Standards

  9. Think Big

  10. Bias for Action

  11. Dive Deep

  12. Have Backbone; Disagree and Commit

  13. Hire and Develop the Best

  14. Frugality

  15. Strive to be Earth’s Best Employer

  16. Success and Scale Bring Broad Responsibility

では、どうやってストーリーを準備するのでしょうか。基本的な構造として、STAR（Situation -> Task -> Action -> Result）や、ネガティブのストーリーであれば、STARL（Situation -> Task -> Action -> Result -> Lesson Learned）という構造が定番です。また、数字が大切なので、でかいシステム
と言われても、ユーザは1万人なのか、100万人なのかは大違いです。以下はちょっとした例になります。システムの規模や、チームの規模、問題をなるべく具体的に話しましょう。また、面接官もファクトチェックのために追加質問があり、一段と掘り下げる形となります。なので、個人的には最初から数字や規模感を伝えておくとストーリー自体はわかりやすくなるかなと思います。

Situation Example: When I joined XX, I was tasked with taking over a critical XXX system developed by an overseas team. This system was essential for XXX services, serving over 60 million users and onboarding 200,000 new users monthly. However, it was running on Java 8, had poor documentation, and ….. As tech lead of 3 members, I …

通常のストーリーなら誰でも何個か持っているでしょう。ここで気をつけたいのは、ネガティブのストーリーも2、3個持つと良いでしょう。例題としては以下が挙げられます。ここでいうCustomerは必ずエンドユーザーではなく、別のチームメイトや他チーム、自分のManagerにも当てはまるケースがあります。

  • Tell me about a bug you created in the production system

  • Tell me about a time you receive a harsh feedback from your manager and how did you deal with it

  • Tell me about a time you felt really strongly about something on a project, but the team decided to go in a different direction

  • Tell me about a time that you push back a customer request

面接の場で、どうしても質問に当てはまるストーリーがなければ、面接官と相談して、ちょっと質問変えてもらっても大丈夫なケースがあります。

また、完全に自分がやってなくても、自分のチームメイトが行ったことでも、自分が状況を全部把握している前提であれば、自分がやったこととして話すのはよくやるテクニックなので、そこもうまくやりましょう。

よりシニアのポジションを目指す場合は、チームリード経験＆他チームとの連携経験＆Junior Memberのメンターシップ経験も重視されます。関連のストーリーももれなく準備しましょう。

System Design

アメリカでは、midレベル以上のソフトウェアエンジニアの面接では、System Designが必ずあります。ポジションによっては、System DesignがCodingよりも面接回数が多い会社も経験していました。制限時間は30分〜1時間、多くの場合、面接の会社が実際使えそうなシステムや、ビジネス問題を解決するようなシステムデザインがお題になることが多いです。

準備材料として、自分が一番参考になったのは、Hello InterviewとByteByteGoでした。あと、よく準備材料としてあげられるのはDesigning Data Intensive Applicationでしたが、良書であることは間違いですが、どちらというと辞書や、知識をじっくり深めたい場合には使いたいですが、2ヶ月間System Design面接のパフォーマンスを最大限に発揮できるには、個人的には、Low Levelの知識よりも、Systemのパターンや、よくある質問の解き方を覚えた方が効率的だと思います。

かといって、Hello InterviewとByteByteGoは全て事例に基づく例題集みたいなもので、基礎知識や各技術スタックのメリデメを知りたい場合は、Jordan has no lifeのSystem Design 2.0 Playlistがおすすめで、基本的にDesigning Data Intensive Applicationに沿って話しているから、素早くキャッチアップでき、さらに詳しく知りたい場合はDesigning Data Intensive Applicationの該当章を読むのは時間の節約になります。

面接回答の構成としては、自分はHello Interview提唱の構成に従って回答しています。Requirement -> Core Entites -> API or Interface -> (Data Flow) -> High level design -> Deep Diveとなります。他の有名なREADME方式Requirement -> Estimation -> API -> High level design -> Memory/Data -> Extendとほぼ似ていますが、Estimationが一番最初の段階で必要ないじゃないかとHello interviewの方が提唱しています。理由としては、最初にEstimationをしても、ユーザ数が多い、アクセスが多いですねぐらいしか結論がなく、実際に一番BasicなHigh level designを完成して、Functionalな条件を全部満たした後に、Estimationに合わせてScalabilityなDesignにしていくというような流れを想定しています。詳細はHello interviewでも紹介しています。

また、面接では基本的にSystem Designの会話をリードしてくれる期待値があるので、最初のお題出され、Requirement（Functional, Non Functional）を分析したのち、以後の時間はこのような順序で話しますとスケジュールを提示した方が良いみたいなので、自分もそれに沿って話しています。

 また、DrawingツールとしてExcalidrawは断トツで使いやすいです。面接の会社は大体Drawingツールを提供していて、自分が経験した会社では、ExcalidrawかMiroどちらかです。どちらも試しに使っても損がないです。

最後に、System Designのお題はCodingに比べて少ないため、GlassdoorやBlindで事前に昔どんなお題出しているか調べて、そこを準備するのは一番効率が良い気がします。自分もほとんど事前に準備することできました。

他の参考になったリンク

英語練習

自分はひたすらChatGPTのAdvanced Voice Modeで話していましたが、日常会話やMock interviewなど、本当にAIの進化がすごくて違和感なくかつスムーズに会話できています。

他には、面接自体は練習になりますので、英語の練習だけでなく、面接でこんな失敗をしたなと振り返り、次回以降の改善にも繋がります。なので、落ちても良い会社の面接を前の段階に設け、経験をある程度積み重ねたら、狙い目の会社の面接をやった方が良いでしょう。

Offer交渉

おめでとうございます。この段階まできたらまずは一安心でしょう。ですが、油断したらダメです。最終面接の後のプロセスとして、合格通知 -> (Team match) -> Verbal Offer -> Written Offer -> Signとなります。Team matchが会社によってなかったりするし、先にVerbal Offer出してTeam matchの会社もあります。Verbal Offerがあっても、Written Offerが来ないケースもよく聞きますので、最後のSignまでは気が緩まないようにしましょう。その間、他の面接も通常通り行いましょう。

通常では、Verbal Offerの時に、リクルータからの給料提示の電話があります。もしその場で同意したら1日〜数日間でWritten Offerが来ることが多いでしょう。ですが、アメリカでは、給料交渉は普通です。交渉したからといってOfferは撤回しないので試しにでも交渉した方が良いです。事前に給料のレンジを知った方が良いでしょう、levels.fyiやBlindで自分のランクのデータポイントを収集しましょう。よくあるやり方として、Offer電話のその場で同意するのではなく、家族と相談させてくださいと一旦電話を切り、給料の再調査やアピールポイント整理し、再度メールにて回答しましょう。

給料交渉の最強武器として、他社のOfferです。特に同レベルの会社、FAANGやビッグテック同士、PreIPO同士、StartupなどのCompete offerがあれば、自分のランクのMaxまで出してもらう可能性が高くなります。そのため、できれば最終面接も近い日に調整した方が結果が一緒に出るので調整しやすいです。

アメリカのソフトウェアエンジニアの給料体系して、Base Salary + Equity(RSU) + Bonus + (Signon Bonus) + (Relocation Fee)があり、全部合計でTotal compensation (TC)と呼ばれています。Offer提示の際にも、リクルータも実際Break downして説明はしてくれます。また、未上場の会社で上場までに会社辞める場合は、Equityはお金にならない場合もありますので、そこも考慮する必要があります。BaseはダメでもせめてSignon Bonus、もしくはRelocation Feeは交渉しましょう。

多拠点がある会社は、拠点によって給料が大きく違うこともあるので注意しましょう。Bay AreaではLiving Costが高く、物価調整金としてかなり上乗せして出している会社もあります。その場合は、Paycheck Calculatorで手取り年収も計算しとくと良いでしょう。

最後に

アメリカの就活はメンタルと体力の勝負です。1日では終わらないので、普段から適度にモチベーションを維持しつつメンタルが壊れないように意識しましょう。同じく就活の友達を作り、Mock interviewや情報交換を常に行いましょう。

最後になりますが、もしアメリカの就活に関する質問や悩みがあれば私に連絡ください、相談に乗ります。

いいなと思ったら応援しよう！