アメリカでソフトウェアエンジニアの職を探した

はじめに

アメリカでソフトウェアエンジニアの職を昨年9~12月、今年1月で探していました。

アメリカでソフトウェアエンジニアの職を得るためには、大学受験*1に近いような膨大な対策が必要です。 また、アメリカの就活は情報を持っている方が有利になるケースが多く、インターネットやネットワーキングを通して情報収集をすることが大切です。

そのため、この記事では、対策方法、自分が就職活動の際に調べた情報をなるべく多く掲載しています。就活中にコツコツ書き溜めていたら2万5千字近いボリュームになってしまいました。この記事が今後、アメリカでソフトウェアエンジニアの職を探す方の参考になれば幸いです。

前提

アメリカで働くためのビザ

アメリカで就職活動をするためには、ビザの問題をクリアする必要があります。ビザについては、以下のfushiroyamaさんの記事がよくまとまっていますのでご参照ください。

fushiroyama.hatenablog.com

私は、アメリカの大学院を12月に卒業しました。そのため、F-1 OPTのルートを利用しています。

業務経験

私は9年ほど日本でソフトウェアエンジニアの経験があります。そのため、以降に述べるのは主にシニアソフトウェアエンジニア向けの対策となります。

ここからは余談ですが、アメリカのソフトウェアエンジニア就職でも、日本と同様で経験年数がかなり重要です。私の懸念として「日本でのソフトウェアエンジニアの経験はアメリカの業務経歴として扱われるのか？」という疑問がありましたが、その点は全く問題がありませんでした。
日本での経験をレジュメに載せれば、会社は相応の業務経歴を持つ人として扱ってくれるようです。

2023年のアメリカのテック業界の状況

2022年後半~2023年前半のレイオフラッシュによりエンジニアのジョブマーケットは劇的に変わりました。

自分が話を聞いた限り、2022年の9月ごろまではエンジニアの採用にバフがかかっており、アメリカでエンジニアとしてテック企業に入るのは非常に簡単だった *2と聞きました。 今、現在はビッグテックはおろかAirbnb, Uberなどのミドルティアのテック企業ですら入るのは難しい状況だと思います。特に経験年数が3年未満のジュニアだとかなり厳しいようです。

理由としては簡単で、「レイオフされた人が職を探している（供給過多）」「企業は採用を抑えている（需要不足）」によって発生しています。

実際に私のクラスの友人でも、半数近くが卒業後も職を探しており、現在の採用市場の厳しさを物語っています。自分も300以上のポジションに応募しましたが面接に進めたのは指で数えられる程度であり、オファーが出始めたのも就職活動を始めて4カ月後でした。

そのため、現在、アメリカでソフトウェアエンジニアのオファーを得るには十分な準備と運が必要となります。

具体的な就活のステップ

前提と現在のエンジニア採用市場を説明したところで、具体的なステップの説明に入ります。以下のステップを踏みます。

1. インタビューで求められることの理解
2. レジュメ作成
3. ネットワーキング・リファラル
4. 応募
5. コーディング面接
6. システムデザイン面接
7. 行動面接

それぞれ説明します。

ソフトウェアエンジニアのインタビューで求められることの抽象的な理解

まず、広くソフトウェアエンジニアのインタビューで求められることを理解しましょう。 これにより、効率的に対策を行うことができます。

以下のスライドが非常によくまとまっています。スライドの中でも言及されている通り、抽象的な内容を含みますがインタビューを行う目的や意義を説明するためには広く抽象的に説明せざるおえないでしょう。

docs.google.com

レジュメ

採用市場が厳しくなり、レジュメスクリーニングで弾かれる確率が上がったため、適当なレジュメだとオファーはもらえないでしょう。 レビューを受けたり、見直しを行って、レジュメの品質を研ぎ続けることをおすすめします。

以下自分がレジュメを書く際に気を付けたポイントです。

Job Descriptionから逆算してレジュメを作る

実際に何個か自分の経験に沿うようなJob Descriptionを見つけて、どういったキーワードが使われているのか調査をしてレジュメを作ることをおすすめします。

例えば、以下のStripeのJob Descriptionを見て以下のような経験が必要とされていることがわかります。

• ソフトウェアの開発のフルサイクル（デザイン、開発、テストからリリース）の経験があること
• 異なる専門職の人（例 セールス、デザイナー）などと協業してプロジェクトを行った経験がある

ここから自分は以下のような内容をレジュメに記載しました。

• orchestrated end-to-end SDLC, architecture and module design to coding, testing, and release -> SDLC (Software Development Lifecycle)を最初から最後まで一貫して対応し、アーキテクチャ設計やモジュールデザイン、コーディング、テスト、リリースまで担当しました
• Collaborated with designers and customer successes to design functionality and UX design of new features -> デザイナーやカスタマーサポートと協業して機能やUXデザインを設計しました

これをさまざまなJob Descriptionで繰り返して、いろんなJob Descriptionを元に自分のレジュメの記載をUPDATEしていくことをおすすめします。

一枚におさめる

レジュメは1枚におさめましょう。これについては諸説あり「キャリアが長い人であれば1.5枚でも大丈夫」説なども聞いたことがありますが、やはり1枚のおさめたほうが無難だと思います。

理由はリクルーターは100単位、ときには1000単位のレジュメをスクリーニングで確認する必要があり、レジュメは最大で25秒見て判断しているため1.5枚だと一目でレジュメが確認できず、不利になるからです。

実際に私のクラスメイトでも経歴8年ぐらいの人もいましたが漏れなくみなさん1枚に収めていました。

数字を用いてスケールとビジネスインパクトを示す

レジュメの箇条書き部分には数字を用いて、自分が携わっていた業務のスケールとビジネスインパクトを示すようにしましょう。

採用側は、レジュメを通じて以下の情報を知りたいのです。

• このエンジニアはどのくらいのスケールのプロジェクトにかかわったことがあるのか？
• このエンジニアを採用することでどのくらい会社の事業を拡大させられるのか？

例えば、「私はスタートアップでチームリードとして仕事をしていました」だと、採用側は「どこの馬の骨かわからん友人と適当に組んだユーザー0人のプロダクトの開発をするスタートアップでエンジニア一人で仕事しているのでは？」と疑われてしまうのです *5。

そのため「私は100人の従業員のスタートアップで5人のエンジニアを率いるチームリードをやっていました」と伝えると採用側はスコープをイメージすることができます。

ビジネスインパクトも同様で、例えば「私がリードを担当したプロジェクトは現在会社の売り上げの〇〇%に貢献しており金額にすると〇〇円です。」というと担当したプロジェクトのスケールを明確に伝えることができます。

エンジニアだと場合によっては、リリースしたプロジェクトが直接、売り上げなどの数値に関わらないパターンもありますが、可能であれば「リリース時間を○○時間 短縮した」と数字を入れることをおすすめします。エンジニアの単価を計算を合わせてコスト削減した金額に変換して金額を記載するのもおすすめです。

なるべく隙間を埋める

前述の通り、1枚に収める必要はあるのですが、その1枚で最大限の情報量を提供するために、レジュメの空白はなるべく埋めるようにしましょう。

以下の画像は、自分の就活開始当初のレジュメ(左)と終了時のレジュメ(右)の比較です。開始当初のレジュメは見ての通り空白が多いですが、終了時はかなり埋めているのがわかります。

フォーマット添削ツールにかける

レジュメのフォーマットや体裁、軽い文章のレビュー（同じ単語を多用していないか、Typoが無いか）をチェックしてくれるツールがあるので、こちらで体裁はチェックしましょう。

自分は学校がVMockというツールが無料で使えるようになっていたのでこちらを利用しました。

www.vmock.com

あとはResume Wordedというツールもよさそうです。

resumeworded.com

気を付けてほしいのは、このツールで100点となったからといってレジュメがバンバン通るようになる、ということはありません。前述のポイントを意識してフォーマットだけでなく、内容も良くしていきましょう。

レビューを受ける

書いたらレビューをしてもらいましょう。自分は以下の方にレビューしてもらいました。

1. クラスの友人
2. ネットワーキングでつながった現役エンジニアの方
3. 大学時代の友人や社会人時代の同僚

3.は個人的にはとても有用でした。自分は大学時代の友人にリファラルをお願いするついでにレジュメレビューをお願いしました。その友人と話をしてて、自分の業務経歴の「外からの見え方」と「自分の見え方」についてギャップがあることに気づきました。

自分的には大したことをしていないので、レジュメでは大したこと無さそうに書いていたのですが、実は外から見ると立派に見えていたのです。

それに基づいてレジュメを書き直したところ、ほとんど通らなかったレジュメスクリーニングが通るようになり、びっくりしました。

そのため、特に「自分の仕事や実績をなんとなくでも知っている過去の同僚、友人」にレジュメレビューをお願いするのは有用だと思います。

ネットワーキング・リファラル

アメリカでの就職活動といえばネットワーキングやリファラルが重要でした（注: 過去形です）。 以下のRedditの記事でも Refferals are king 書かれているとおりリファラルを出してもらう=面接確定というのが定石だったようです。 そのため、LinkedInで知らない人にメッセージを送り、リファラルをお願いする(Cold Messagingと呼ぶ)、というのが一般的でした。

Referrals Are King - A Shithead Guide On Successfully Applying To Jobs, Even - ESPECIALLY - When You're A Shithead.
byu/texzone incscareerquestions

しかし、今、現在 リファラルを出してもらう = 面接に行ける というわけではなくなりました。 私の推測ですが、以下のような理由だと考えられます。

【数年前まで】
数年前までは、売り手市場でJob Openingsに対して応募数が少ない、あるいはエバーグリーンポジションと呼ばれる常にOpeningがある状態だったため、多少 時間をかけてリファラルをお願いしたほうがリクルーターに見られて面接に行ける可能性が高い。

【現在】
現在は、買い手市場で一つのJob Openingがオープンした瞬間に100の応募があるのが当たり前の状況のため、むしろリファラルを取っている間にヘッドカウントが埋まってしまう。

そのため、ネットワーキングは「大学の先輩に就職活動のTipsを教えてもらう」や「モックインタビューをお願いする」などの用途に留め、リファラルをお願いする目的でのネットワーキングはやめました。

実際に昨年度に就職活動を行った先輩に聞いても「リファラルはお願いせず、直接アプライしまくった！」と言っていたので考察はあながち間違いではないのかと思います。

応募する

アメリカの就活はNumber Game

アメリカの就活はNumber Game (=応募数の勝負)だと言われています。とにかく応募しまくりましょう。理由としては、簡単で ほとんどレジュメスクリーニングで落とされるからです。

ただ、100通に1通ぐらいは通るので、応募しまくるしかありません。私のクラスメイトはMicrosoftとAmazonだけで300のポジションに応募しましたが、Microsoftからは0、Amazonからは1つレスポンスが来ただけです。 私も300ポジションほど応募しましたが返信が返ってきたのは指で数えられる程度しかありません。

応募しまくるのに使えるツールとしてSimplify Copilotがあります。

simplify.jobs

Simplify Copilotは会社に応募するときのフォームをオートフィルしてくれるツールです。毎回、定型句を会社に応募するとき入力しなければならないのですが、これだとボタン一発で全部入力してくれます。

採用のトレンドを追う

2024年現在もレイオフの嵐が吹き荒れているため、「どこの企業が採用を行っているか」をキャッチアップすることは大事です。レイオフしまくっていてヘッドカウントがほとんどない会社に応募するのは時間の無駄です。

例えば、ご存じの通りGoogleは絶賛レイオフ中ですが、採用でもほぼ同様の感じでほとんどのクラスメイトはPhone Interview後にヘッドカウントが無いと言われお祈りを受けていました。

逆に、クラスメイトから「今○○は採用をめっちゃ強化してるらしい」という噂を受けて応募するとReplyが来たりと採用のトレンドを追うことはかなり重要です。

上記のクラスメイトの口伝以外でも以下のソースを毎日見て採用のトレンドを追っていました。

https://www.reddit.com/r/leetcode/

RedditのLeetCodeサブレディットでは、LeetCodeだけでなくテック企業の採用トレンドの話が流れたり、「○○のオンサイト今度受けるから対策教えて！」など実践的なアドバイスが飛び交っています。

https://www.reddit.com/r/cscareerquestions/

Redditのcscarrerquestionsもレイオフのトレンドがよく流れます。

https://www.reddit.com/r/csMajors/

csMajorsは新卒向けの情報が流れてます。（みんな大変そうでした。）

www.teamblind.com

Blindはテック企業の社員向けの匿名SNSですが、テック企業の社員でなくてもパブリックな記事は閲覧できます。レイオフの噂はここが一番早く流れます。匿名のためかテック企業の暗部がよく見えます*3。

時期を見計らう

シニアのポジションは「今すぐ即戦力が欲しい！」という前提で募集が行われるので、稼働開始日が3カ月～半年先の場合、その時点で他の応募者が優先されお祈りされることが多いです。

自分も実際に8月、9月ぐらいは「すぐに働き始められる人材を求めているので11月ぐらいにまた応募して」と言われてお祈りをされました。

シニアの場合だと稼働開始2カ月~1カ月前から応募し始めるのがよいかと思います。

Linkedinで最新の求人を見つける方法

応募するためには最新の求人を誰よりも早く知る必要があります。 可能であれば、求人が出されてからしばらく経ったものではなく、新鮮な、出されたばかりの求人に応募するほうがオファーがもらえる確率が高くなります。 理由は、採用プロセスはパイプラインであり、以下の流れを経ます。

• よさげな人をピックアップ
• 採用プロセスに載せる
• すべて通ればオファー
• オファー受諾してヘッドカウントが埋まれば求人終了

この流れなので、しばらく経った求人だとパイプラインにすでに人がいて、採用プロセスの半ばでヘッドカウントが埋まって終了、という悲しい事態が発生するのです。 そのため、最新の求人を誰よりも早く知る必要があります。

アメリカの企業の求人サイトはLinkedin, Indeed, Monster, Hiredなどいろいろありますが、基本的にLinkedinさえ使えば十分かと思います。他は必要ありません。

ただ、Linkedinは何も考えずに使うとただのゴミ求人サイトです。 理由は簡単で、Linkedinは応募者からお金を取るビジネスモデルではなく、求人を出稿する企業側から主にお金を取ることで成立しているビジネスモデルだからです。 そのため、Linkedinは応募者が 欲しい求人情報を出すのではなく、多くお金を払った企業の求人情報を出します。

よって、応募者、ひいては私たちはLinkedinをその点を踏まえてハックする必要があります。以下手順です。

Promotedをすべて非表示にする

Promotedは先述のロジックにより企業側の出したい求人なのですべて非表示にします。 やり方は以下のRedditを参考にAdBlocker(uBlock Origin)にwww.linkedin.com##li:has-text(Promoted) というフィルターをセットします。

Is there a way to hide promoted job postings from my job search?
byu/-KuroOkami- inlinkedin

これでPromotedはすべて非表示になります。

"Most Recent"順にする

Linkedinは実はデフォルトで"Most Relevant" (関連度順)というよくわからないソート順になっているので、Most Recentにします。 このフィルターをONにするのも奥深くに隠されていて、設定しづらいというLinkedinの悪意を感じます。。。

"AllFilters" -> "Most Recent"で投稿順に

検索クエリを工夫する

Linkedinの検索クエリはSQLライクなLIKE, AND, NOT, ORが使えるのでそれを使って不要な条件を除きます。 自分は、以下のようにStaffやPrincipalエンジニアは対象から外したかったので以下のクエリを設定していました。

“software engineer” AND NOT "principal" AND NOT "staff"

設定をブックマークする

上記をすべて設定したらLinkedinの検索条件保存機能ではなく、ブックマークをします。 Linkedinの検索条件保存だと、"Most Recent"などすべての条件が保存されないので、いちいち設定しなおさなければならないので面倒です。

時間を決めて巡回する

自分は"Past 24 Hours"のフィルターも設定して朝と夜の決まった時間に巡回して応募していました。

この手順を踏むと、以下のようにLinkedinで投稿順に求人が綺麗にわかるため、おすすめです。

Linkedinの投稿順表示

コーディングインタビュー対策

アメリカのソフトウェアエンジニア職で鬼門となるコーディングインタビューです。

やはり対策の王道は「LeetCode」ですが、やみくもにLeetCodeの量を解いて「LeetCode XXX問解いた！」のような形で対策するのは時間の無駄だと思っています。質の高い150問を解いて、その解法をしっかり理解すれば通過できます。

leetcode.com

個人的におすすめしたい戦略は以下の通りです。

1. アルゴリズムの地図を脳内に作る
2. NeetCodeを例題として解き解決法のパターンを理解する
3. モックインタビューでアウトプットの練習を行う
4. 直前対策で類問を解く

アルゴリズムの地図を脳内に作る

以下のような方はまず「アルゴリズムの地図を脳内に作る」ことをお勧めします。 ただし、インタビューの予定が間近に迫っている場合はこのステップは省略してもかまいません。

• 情報工学、Computer Science専攻でなく、大学などで、アルゴリズム・データ構造のクラスを取っていない
• 今までアルゴリズムの本を通読したことが無い

「アルゴリズムの地図を脳内に作る」とは、そもそもアルゴリズムやデータ構造の以下のような要素がどのような関わりあいで関係しているかを把握し、説明できるようにする、ということです。 これは、LeetCodeをただただ解いているだけではほぼ身につかないと思います。

• Stack/Queue
• DFS/BFS/Backtracking
• 動的計画法/Greedy
• UnionFind
• グラフ

このためには、以下のいずれかの方法があります。

• 大学やCouseraでアルゴリズムの授業を取る
• アルゴリズムの本を通読する

大学やCouseraでアルゴリズムの授業を取る

直近で転職予定や就職活動の予定が無く、半年ほど時間が取れる場合にはアルゴリズムの授業を取ることをお勧めします。 私はCouseraでアルゴリズムの授業を取りましたが、これはコーディングインタビュー対策に間接的に役立ったと思います。

大学生の方で情報系の方はアルゴリズムの授業をしっかり受けてAを取りましょう。情報系以外の方はアルゴリズムの授業がなんとか取れないか交渉してみましょう。

英語ができる方はCouseraでアルゴリズムの授業を取りましょう。

blog.pco2699.net

英語ができない方は、アルゴ式というサイトに必要な知識が実戦形式でまとまってよいと思いました。

algo-method.com

アルゴリズムの本を通読する

時間が無い場合には、アルゴリズムの本を読みましょう。

個人的にオススメなのは「なっとく！アルゴリズム」です。

なっとく！アルゴリズム

そのほか、最近の本では以下がおすすめです。

問題解決力を鍛える！アルゴリズムとデータ構造 (ＫＳ情報科学専門書)

問題解決のための「アルゴリズム×数学」が基礎からしっかり身につく本

NeetCodeを例題として解き解決法のパターンを理解する

アルゴリズムの地図を作ったとしても、LeetCodeがサクサク解けるようにはなりません。実際に例題で演習を行う必要があります。

この例題演習は、大学受験のチャート式を意識するとわかやすいかもしれません。 チャート式は最初に例題があって、それで解き方を知る->実際に練習問題で問題を解く、という形です。

別の方がおっしゃっていた例で納得したのは、「コーディングインタビュー対策は機械学習に近い」というものです。例題をトレーニングセット、解答をラベルとして自分の脳に解答のパターンを形成するのが目的です。

この「例題演習」をNeetCodeを用いて行います。LeetCodeではありませんNeetCodeです。

neetcode.io

NeetCodeはご存じの方も多いかと思います。 もともとはYoutubeのチャンネルから始まっており無職だった（文字通りNeet）だったNavdeep Singhさんが時間が余っていたのと就職活動のために始めたLeetCodeの解説チャンネルです。 本人もこの活動のおかげでGoogleに入社しています。現在は、上記のneetcode.ioというサイトも立ち上げておりYoutubeの外に活動範囲を広げています。

NeetCodeは以下の点で他のYoutubeチャンネルやサイトよりも優れています。

• LeetCodeの解説のみであれば無料である
• 英語の発音に訛りが無く、ゆっくりしゃべるので聞き取りやすい
• 解答のコード・説明が簡潔である

実際に問題を解く解き方は以下の通りです。

• Grind 75
  1. EasyをRoadmapに沿って解く
  2. MediumをRoadmapに沿って解く
  3. HardをRoadmapに沿って解く
• NeetCode 150
  1. Easyの残りを解く
  2. Mediumの残りを解く
  3. Hardの残りを解く

Grind 75は有名ないわゆる「出る順！75題」でNeetCodeはそれの150です。実際にGrind 75を一通り解けばコーディングインタビューには臨める状態になるかと思います。NeetCode 150はダメ押しの精度向上です。

ただ、NeetCode 150を実際に解いてインタビューを受け、いくつか近年の出題傾向に沿っていない問題が含まれていることがわかりました。

• Advanced Graphの問題はPrimのアルゴリズムやダイクストラ法、ベルマンフォード法などを扱っているがほぼ出題されない。
• あまり出題されないHeapã‚„Dynamic Programmingの問題が多い
• 近年の傾向としてクラス設計やシステムデザインを少し含めたDesign系問題が出るようだが、問題数が少ない（LRU Cacheã‚„Design Twitter、Time Based-Key Value Storeのみ）

そのため、自分が少し問題を変えたSpreadsheetを作ったので良かったら参照してみてください。 なお、このSpreadsheetは実際に自分が解いたLeetCodeの問題の管理用シートが元になっています。

docs.google.com

注意点1: わからなかったらすぐに解き方を見る

解き方の注意点として「問題の解き方がわからなかったらすぐにビデオを見る」です。 ここでの目的は「解決法のパターンを脳内に作ること」であり、解いている問題は例題なので、1時間や2時間もかけてアイデアが出るまで問題を解くのは時間の無駄です。問題を理解し、5分考えてわからなかったら 解答のビデオを見ましょう。

注意点2: わからなかったら繰り返し解く

わからなかった問題は繰り返し解きましょう。自分は前述の通り、以下のようなシートを作ってわからなかった問題については、次に解く日程を設定して繰り返し解いていました。

この繰り返し解くというのが非常に肝です。繰り返し解くことによって、特定のパターンのコードを突っかからずに書けるようになります。 例えば、以下は典型的な二分探索のコードです。

def binary_search(nums: List[int], target: int):
    l, r = 0, len(nums) - 1
    while l <= r:
       mid = (l + r) // 2
       if nums[mid] == target:
           return mid
       elif nums[mid] < target:
           l = mid + 1
       else:
          r = mid - 1
    return -1

このコードを書くにあたって、以下のポイントがあります。

• rはlen(nums)に設定すべきか？len(nums)-1に設定すべきか？
• whileの条件はl <= rか？l < rか？
• nums[mid] < targetの場合はlを更新すべきか？rを更新すべきか？

こういったポイントについて、考えながらコードを書いていると30分はあっという間に過ぎてしまいます。繰り返し問題を解くことで、こういった事項をマッスルメモリーに叩き込み、コードの書く速度を上げる必要があります。これが繰り返し解く目的です。

モックインタビューを行う

コーディングインタビューがLeetCodeのようにオンラインジャッジであればよいのですが、現実はそうではありません。面接官とコミュニケーションを進めることでインタビューをすすめます。

そのため、黙ってコードを書いていると、いくら最適なアルゴリズムが導き出せても、落ちます。 ここらへんの考え方は、以下の記事によくまとまっています。

nodchip.hatenadiary.org

2 つ目は、話す量です。面接官と同じか、それ以上話しましょう。

再度繰り返しになりますが、ソフトウェアエンジニアリングの目的は、ユーザーのためになるものを提供することです。そのためには、同僚同士が意見を出し合い、意見をブラッシュアップしていく必要があります。ところが、こちらが話しかけても、はいとかいいえとか最低限のことしか返さず、全然話さない同僚がいたらどうでしょうか？ おそらく、良い意見が出にくくなり、意見のブラッシュアップもしにくくなってしまうのではないかと思います。特に面接で仮想体験するシチュエーションは、困っている同僚があなたに助けを求めているという状況です。そのような状況では、応募者のほうがたくさん話すほうが自然だと思います。

この「コミュニケーションを進めながらコードを書く」というのは日常のエンジニアの業務としてはなかなか行わない作業のため、モックインタビューで練習を行いましょう。

モックインタビューは以下の方法があります。

1. ネットワーキングでモックインタビューをお願いする
2. 仲間（クラスメイトなど）を見つけてモックインタビューする
3. 無料のモックインタビューマッチングサービスであるPrampを利用する
4. お金を払ってモックインタビューする ( interviewing.io など)

それぞれに一長一短がありますが、個人的には「ネットワーキングでモックインタビューをお願いする」が最も効果的だと思いました。

1, に関してインタビュワーが実際にコーディングインタビューをしているエンジニアならば、コーディングインタビューを行うノウハウがあるため本番に近い状態でモックインタビューができます。 短所としては、現職のエンジニアのためあまり回数を行えない、ということです。

実際に、Google Japanの元エンジニアや現役のGoogleのエンジニアとモックインタビューを行いましたが、非常に有用でした。 そもそもコーディングインタビューにおいては、インタビュアーにもある程度の技量が求められます。例えば以下です。

• 問題の質を担保する: 簡単に解ける問題や難しすぎる問題、トリッキーな問題は出さないほうがよい。LeetCodeの問題をそのまま出すのも意味がない。*4
• 問題の出し方: 問題解決能力やコードのデザイン能力を測るため意図的に問題を抽象的にし、解答者に設計を意図的に委ねる場合がある。
• ヒントの出し方: 意図的に難しい問題を出して、ヒントを出していくことでコミュニケーション力（ヒントに気づけるか、意図を図れるか）を測る場合がある。

後述する仲間やPrampでは、上述の点をカバーできません。

2, 3.に関しては、逆に回数は確保できます。しかし、説明した通りインタビューの品質は担保できません。特にPrampについては、相手も練習中のエンジニアですし相手もマッチングによってまちまちでした。

4, はインタビュアーの品質が担保されますし、お金を払い続ける限り回数もできますのでお金がある方は検討してもいいかもしれません。（あまりお勧めしないですが。）

どうしても、モックインタビュー相手が見つからない！という方は自分もモックインタビューはできるかと思いますので、右の問い合わせより問い合わせてください。

2025年8月6日更新: 会社のConflict of Interestのポリシーの都合上、現在はモックインタビューは行っていません。

直前対策: LeetCode Tagged/Glassdoorで見つけた問題をやる

LeetCodeのPremiumを購読しているとみることができるLeetCode tagged questionやGlassdoorにインタビューで出された問題を書いてくれている人がいるのでそれに基づいて対策します。

これに関しては、LeetCodeやGlassdoorで書いている人はNDA違反している可能性があり、かなりグレーゾーンではあります。

本番のTips

コーディングインタビュー本番の際に有用なTips、特に解法が思いつかないときの対応方法を紹介します。

最後まで諦めない

解法がわからないと頭が真っ白になり、「わりぃ、俺死んだ」っていう言葉がよぎりますが、まず最後まであきらめないようにしましょう。

解法がわからなかったり、詰まったりするのはインタビューでは当たり前のことで、面接官も「つまったから減点」ということはありません。むしろ詰まることは当たり前です。

自分でいろいろ考えて詰まった状態から抜けることができると、むしろプラスになることが多いです。そのため、詰まったら、いろいろ声に出して試行錯誤してみましょう。

例をトレースする

細かいifの条件などがわからなくなった場合に有用なテクニックです。途中でもいいのでとりあえず書いて、何個か例を通してみると条件が思いつくときがあります。

自分もbacktrackの返り値を返すタイミングがわからなくなった際に実際に例をトレースしたら思いついたことがありました。

図を書く

図を書いて整理すると解法を思いつくことがあります。Coderpadには最近、drawing機能があるので、描いて説明することができます。

Intervals系の問題はコードだけ書いてるとかなり混乱しますが、図を書いてみると案外非常にシンプルだったりします。

システムデザイン対策

システムデザイン面接は、システム周りの知識を問う面接で例えば「Twitterをデザインせよ」というお題目でホワイトボード上で実際にシステムをデザインしてみる、という面接です。

以下のステップで対策を行うことをおすすめします。

• システムデザインの知識を習得する
• システムデザイン面接のフレームワークを学ぶ
• 実際に面接例をYoutubeで学習する
• Drawing Toolに慣れる
• モックインタビューを行う

システムデザインの知識を習得する

システムデザイン面接の対策にあたり、まず最初に行うべきなのは分散システムなどの大規模システムの基礎知識を学ぶことです。

後述するYoutube ChannelのSystem Design Fight Clubの主催者が作成しているGitHubレポジトリが2024年 現在もっとも対策の文献情報がまとまっています。 そのため、自分で計画が立てられる方は以下のレポジトリを参考に、自分で勉強計画を立ててみることをおすすめします。

github.com

この中でも、以下の教材がおすすめです。

データ指向アプリケーションデザイン

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

分散システムの知識のバイブルと言っても過言ではない神本です。自分は日本語版を日本からわざわざ持ってきました。

この本のすごいところは、近年の分散システムの論文を体系立ててまとめている点です。

例えば「Cassandraなどの列指向データベースは他のNoSQLと何が違うのか」ということが気になった場合、この本を参照すれば仕組みの説明とともに回答が載っています。

ただ、理論の話が中心なので、後述する教材と合わせて「システムデザインインタビューの練習をする中でトレードオフや採用する理由を説明できなかった技術要素」を掘り下げて勉強するための教材として利用するのがおすすめです。 最後の索引を用いて分散システムの辞書として使うようなイメージです。

Hacking The System Design Interview

Hacking the System Design Interview: Real Big Tech Interview Questions and In-depth Solutions

紹介するシステムデザイン対策資料の中で最も新しく2022年に出版されました。近年のシステムデザインの傾向を捉えた上で非常にまとまっておりおススメです。

英語なのと物理本しかないのが玉に瑕ですが、おススメです。

時間が取れる方は、上記のDDIA本とこの本だけでもシステムデザインの対策としては十分ではないかと思っています。

ByteByteGo

bytebytego.com

ByteByteGoはシステムデザイン対策として有名な本「System Design Interview」Seriesの著者であるAlex Xuさんが立ち上げたサイトで、本の内容をそのままウェブサイトにしただけです。ただし有料で年間9000円ほど支払う必要があります。年間でお金を支払うのが嫌な場合は、本を購入することをおすすめします。

内容としては、例えば「URL Shortner」などのお題目に沿って要素技術を紹介していくものです。面接をどう進めるか、よりもシステムデザインの技術要素を習得する目的で使うとよいサイトです。

昨年、本が日本語化されて出版されたので、英語が苦手な方はこちらを読むとおすすめです。Vol2は日本語化されていませんが、どちらかというと応用編で、Vol1さえよめば80%のシステムデザインは問題ないかと思います。

システム設計の面接試験

今年の10月にByteByteGoからシステムデザインの技術要素をまとめたレポジトリが出たのですが、こちらシステムデザインの技術要素を一枚絵におさめていておすすめです。

github.com

CMUの分散システムの授業

https://www.composablesystems.org/15-440/fa2023/www.composablesystems.org

私が昨年秋に取って、TAをしたので教材として載せておきます。 ただ、システムデザイン対策のためだけだとやや冗長な内容です。分散システムそのものに興味がある方はスライドを参照してみるとよいかもしれません。

実際、MapReduce、SparkやRPCなど一部、システムデザインで役に立つような内容がありました。

システムデザイン面接のフレームワークを学ぶ

技術要素を取得した後は、どうやって面接を進めるかのフレームワークを学びます。自分が見た限り以下の方法があるかと思います。

• ByteByteGoフレームワーク
• READMEフレームワーク

ByteByteGoフレームワーク

ByteByteGoフレームワークはByteByteGoフレームワークは以下の順番で面接をすすめます。

• 要件確認
• 概要見積
• 大まかなデザイン
• デザイン詳細

自分が見た限り、だいたいの人はこのフレームワークを用いて面接を進めることが多そうでした。

READMEフレームワーク

READMEフレームワークはMetaのエンジニアの人が匿名でやっているYoutubeチャンネルCracking FAANG内で提唱されているもので、以下の方式を取ります。

• R: Requirements
• E: Estimation
• A: API Design
• D: [High Level] Design
• M: Memory (Database)
• E: Extend [Your Design]

私は当初はByteByteGoフレームワークを使っていたのですが、若干説明しづらく、READMEフレームワークを見て、こちらをより使うようになりました。

www.youtube.com

実際に面接例をYoutubeで学習する

Youtube上でさまざまなシステムデザインの解説動画やモックインタビューの動画が上がっているので見ます。以下おすすめのチャンネルを紹介します。

www.youtube.com

System Design Fight Clubは近年のシステムデザイン対策系Youtubeチャンネルの中で最もクオリティが高いチャンネルだと思います。 FAANG系のエンジニアをされている方が毎週いろんなシステムデザインの問題を解くのですが、技術選定の理由が明確なのと本人もさまざま分散システムの文献に目を通しており、知見が豊富です。

www.youtube.com

Jordan has no lifeも近年のチャンネルでおすすめです。最近、システムデザイン対策の基礎コンテンツを出しているのですが、10分程度で他のチャンネルや教材にはない近年の技術トピックも扱っており有用です。

• CRDTとは何か、何に有用か
• Spannerは他のデータベースと比べて何が優れているのか
• クオラムについて

youtu.be

最近、実践系の問題も出しているのですが、Stream Processing（Kafka/Flink）を多用しすぎている気がするので、参考程度に見ておくのがおすすめです。

youtu.be

www.youtube.com

System Design Inteviewも有名なチャンネルです。かなり動画が古い(4年前!)のと少ないのが残念ですが、動画の内容が濃いのと非常に説明がわかりやすいので、全部ぱぱっと見てしまうとよいと思います。

www.youtube.com

前述のNeetCodeもSystem Design対策の動画を出しており、実際のシステムを元に解説を行っています。 見積りの計算やそこからの技術選定の理由が非常にわかりやすく、おすすめです。

上記のようにいくつかはYoutubeに上がっていますがお金を払うと8つほどの動画を見ることができます。

Drawing Toolに慣れる

昨今はほとんどインタビューはオンラインになりホワイドボードを使う機会は無くなりました。自分もすべて面接はZoomなどのビデオで行いました。そのため、システムデザインも仮想のホワイドボーディングツールを使って行います。

そのため、ツールを事前にピックアップしておき慣れるようにしておきましょう。案外、ぶっつけ本番で挑むと思うように自分の書きたいものが書けなくて時間をロスしてしまいます。

会社によってはツールを指定される場合もありますが、自分が受けた会社は自分でピックしてよいことが多く、Excalidrawを使いました。

excalidraw.com

Excalidrawはシステムデザイン用のフリー素材が多く扱いやすいので、もしこだわりが無ければExcalidrawがおすすめです。

事前に右上のLibraryからシステムデザイン用の素材をインストールしておきましょう。

モックインタビューを行う

これもコーディングインタビューと同様にモックインタビューを行いましょう。基本的なやり方はモックインタビューと同じです。

可能であれば、インタビュアーの経験ある人とモックインタビューを行うのがよいかと思います。

あとシステムデザインはタイムマネジメントも重要な要素の一つのため、時間を測るようにしましょう。（35分~45分程度が平均的なシステムデザインの面接時間です。）

行動面接対策

行動面接(Behavioral Interview)は、過去の経験をもとにリーダーシップやソフトスキルを測る面接です。

「人間としてちゃんと受け答えできれば行動面接は通るでしょ？」や「エンジニアだからシステムデザインやコーディングさえできればOK」 と思って舐めていると痛い目を見ます。実際に以下のRedditの記事でもMetaのHiring Managerが行動面接によって多くのエンジニアがダウングレード *5になったと話しています。

Behavioral Interviews Matter Too 👉👈
byu/BluebirdAway5246 inleetcode

私は以下の通りに対策を行いました。

• 過去の経験から6~7エピソード選ぶ
• ChatGPTを用いてSTAR形式でスクリプトを作成する
• ChatGPTを相手に実際に喋って練習する

LeetCodeやシステムデザインはなかなかAIを駆使するのが難しかったですが、行動面接はChatGPTをバンバンに駆使して効率的に対策できます。

過去の経験から6~7エピソード選ぶ

まずは過去の経験を振り返って以下のお題目に答えられるようなエピソードを6~7個選びます。

• Growth mindset : 個人や会社・チーム成長機会を求めた経験
• Leadership : リーダーシップを発揮した経験
• Conflict resolution: 個人間やチーム間の衝突を解決した経験
• Adaptability : 何かに柔軟に対応した経験
• Perseverance : 忍耐強く何かに取り組んだ経験
• Teamwork & collaboration : チームワークを発揮した経験

このお題目はさきほどのRedditの投稿者が提唱するもので、おそらくMetaの行動面接の質問項目に沿ったものだと思いますが、一般的に利用できるのでこれを用います。

注意点としては、応募するポジションに相応のエピソードを用意することです。例えばスタッフやスタッフに近いシニアエンジニアの場合ですと、チーム間や組織レベルでの技術的な問題を解決したエピソードが求められます。 チーム内での閉じたエピソードや一人で自分の問題を解決した話だと、スタッフやシニアポジションでのオファーがもらえずダウングレードになってしまうかもしれません。

過去の経験がなかなか思い出せない、、、という方は、過去の上司などに会って話を聞いてみるといいかもしれません。自分も実際に上司とコンタクトを取って思い出話を振り返りつつ、話せる内容を整理しました。

スプレッドシートで列に上記のお題目、行にエピソードを対応させて網羅しているかチェックするといいかと思います。

ChatGPTを用いてSTAR形式でスクリプトを作成する

ChatGPTを用いてエピソードをSTAR形式で書き下してもらいます。

STARとは行動面接のフレームワークの王道でSituation -> Task -> Action -> Resultで自分の過去の経験を話すものです。

ChatGPTで箇条書きで内容を書いて、スクリプトにしてもらいましょう。

以下のHello InterviewというサービスのStory Builderもスクリプトを作成するのに便利でした。

www.hellointerview.com

ChatGPTを相手に実際に喋って練習する

コーディングインタビューやシステムデザインと同様にモックインタビューをしてもいいのですが、ChatGPTのアプリの音声機能でほとんどモックインタビューに近いことができます。こちらを活用しましょう。

www.youtube.com

自分はパソコンで書き下したスクリプトを見つつ、ChatGPTに「自分の話がSTAR形式に沿っているかシニアソフトウェアエンジニアとしてよいものかGradeして」と言って、実際に話して練習していました。

(Optional) モックインタビュー

これはOptionalですが、行動面接も1~2回モックインタビューを行うといいかと思います。自分も現役のインタビュアーの方にモックインタビューをしてもらい以下の点をチェックしてもらいました。

• 話すストーリーが自分が応募するポジションにふさわしいか
• 話すストーリーが上記のポイントをカバーしているかどうか
• レッドフラグに該当するような話はないか

最後のレッドフラグのチェックは重要です。例として、人種差別などが示唆されるような話をしてしまったら一発アウトで、どんなにコーディングやシステムデザインができても終わりです。そのレベルまでいかなくても、会社のポリシーに沿わないような話をして不合格になることを避けるためにチェックをしてもらいましょう。

行動面接のTips

そのほか行動面接にあたって有用だったTipsを何個か紹介します。

「英語が聞き取れなかった場合は聞き返して」と最初に宣言する

日本で育った日本人が英語を喋る場合、どうしても発音しづらい単語があると思います。

実はその場合、面接官は聞き返すことが難しい場合があります。理由としてはアメリカの企業の面接官は「anti-bias(=対差別)」の訓練を受けていることがあるからです。 「anti-bias」とは、見た目などで人を判断する差別を避けるための訓練です。

面接官は、「この人のEnglishは発音や文法的にネイティブっぽくないなあ」と思ったとしてもそれを言及したりするのはNGなのです。なぜならそういう人でも実際はネイティブの可能性があり差別にあたる可能性があるからです。

ただ、インタビュイーが自ら「英語は第二言語なので、聞き取りづらかったら言ってください」と自己開示をした上であれば、それは差別にはあたらないのでインタビュアーは気兼ねなく聞き返すことができるのです。

こうすることで、英語の発音が原因で、面接官が内容を理解できず、Rejectという確率を減らすことができます。

数字やタイトルでスコープとインパクトを示す

レジュメの項でも記載しましたが、行動面接でも数字を使って、過去の仕事のスコープとインパクトを示すことが大事です。

レジュメの項で記載してないテクニックとして、タイトルを使うのも有用です。例えば「マイクロサービスアーキテクチャを会社に導入するために CEO を直接交渉してプロジェクトを立ち上げました。」と言えば、この人は全社に関わるプロジェクトやプロセスに関わっていた=スケールの大きい仕事に携わっていたと説得することができます。

就活の結果

結果的にテック企業から3件オファーをもらうことができました。*6この厳しいジョブマーケットでOfferをもらえたのは幸運だと思います。

おわりに

アメリカの就職活動はジョブマーケットが厳しいこともあり、非常に大変でした。数えてないですが応募だけで300は行ったのではないでしょうか。

就職活動に際してもっとも有用だったリソースは大学のキャリアセンター、ではなくクラスの友人でした。レジュメが一個も通らずに焦っていると相談にのってくれてアドバイスやレジュメレビューをしてくれたり、LeetCodeをしすぎて疲れたときは寿司を食べに行ったりと、ストレスフルな就活を乗り越えられたのはクラスの友人のおかげといっても過言ではありません。

転職活動は概して孤独ですが、アメリカの大学院に入って就活することのメリットの一つは「就活する仲間がいること」なのかもしれません。

また、最初の数カ月はレジュメを送っても全く返事が来ず、かなり焦りました。自分は日本でエンジニア9年 -> 米大学院という経歴なので、「アメリカでの業務経歴が無いとだめなのか」と日本での就活にシフトチェンジを真剣に考えたこともありました。しかし、クラスメイトや大学時代の友人などと会話してレジュメを大幅に書き換えたところ、かなり返事が返ってくるようになりました。

レジュメを変えて、11月の初週あたりに毎週3~4社ぐらい返事が届くようになり、感激したのを覚えています。

就活はメンタルにいろいろ来ますが、考えて行動すればうまくいくと思うのでぜひ、皆さんも挑戦してみてください。もし困っている方がいればXや問い合わせを通していただければなんでも相談に乗ります。

Appendix: そのほかの参考リンク集

そのほか過去の資料で様々な面で役立った日本語の記事を共有します。

tnanjo.net

大学院の先輩のnanjoさんの就職活動の内容です。LeetCodeの解き方を参考にさせていただきました。*7

anond.hatelabo.jp

この記事ではあまりフォーカスしていませんでしたが、アメリカのソフトウェアエンジニア職の給与体系や給与交渉、レイオフなどの内容が纏まっています。

note.com

この方はデータサイエンティストでの転職活動だったようですが、2023年のジョブマーケットが冷え込んでいることがわかる貴重な記事です。

*1:ソフトウェアエンジニアのインタビューはSATに近い、と言ってる記事も見かけます。

*2: 相応の学歴 or 経験がある前提ですが

*3:何を聞いてもTC (Total Compesation)=年収を必ず添えろ、と言われるなど

*4: 一部の会社はLeetCodeの問題がそのまま出てびっくりしましたが...

*5: オファーされるポジションのクラスが下がること 例: スタッフ -> シニアなど

*6:Offerをもらった会社名やOfferの内容について内容を控えさせていただきます。

*7: 余談ですが、5年前と今では面接対策の資料が様変わりしていてびっくりしました...