はじめに

背景

僕は北米に住んで4年以上になる。そのうち、3年以上はソフトウェアエンジニアとして北米の現地企業で働いている。ただ、来た当初はスキル不足だったし、後半の2年は大不況でレイオフも経験した。周りでもレイオフの話をよく耳にするし、単純に仕事を見つけるのも時間がかかる。何が言いたいかというと、北米での仕事探しは本当に大変だ、ということだ。

そんな中で気づいたのは、就活に関する情報と対策が成功の鍵を握っているということだ。就活のスキルとソフトウェアエンジニアのスキルは全く別物である。だから、優秀なエンジニアであるだけでは仕事が見つかるとは限らない。逆に、特定の技術スキルがそこまで高くなくても、面接の準備と対策をしっかりすれば、チャンスを掴める確率が圧倒的に高くなると感じた。

実際、僕も転職を含めてこれまで2回就職したが、特に2回目はレイオフされた時期で、不況の真っ只中だった。ただそれでもピーク時には1ヶ月で7つの会社と同時にインタビューをこなし、最終的にはMobileエンジニアから狙ってたBackendエンジニアとしてキャリチェンジをすることができた。もちろん、最終的には運や周りのサポートのおかげも大きかったが、それでも情報と対策がなければ、その土台に立つことすらできなかったと思う。

動機

そこで今回、自分自身や他の人の経験をもとに、北米での就活やインタビューがどのようなものかをざっくり紹介するメモを残したい。この記事では具体的な対策については書かない。内容が長くなりすぎてしまうので。そのため、ある程度経験がある人には当たり前の内容も多いが、これから始める人や経験が浅い人には役立つことを願ってる。僕自身もまだキャリアとしては発展途上だが、この4年間で得た情報や経験（自分と他人のものを含む）をこの記事にまとめたい。

この記事を残す理由は主に3つある。

1つ目は、将来の自分への備忘録。今後、より良い環境を目指す中で、過去の経験を振り返り、それを活かせるようにしたい。2つ目は、北米で就職活動をしている人やこれから挑戦しようとしている人に参考なれば嬉しいので。「この記事を読めばなんとなく北米（や外資系）のインタビュー概要が掴める」と思ってもらえたら嬉しい。3つ目は、この情報を基に新たな知見が集まり、みんなでブラッシュアップしていける可能性があると思ったからだ。経験や考察を共有することで、より良い情報を作り上げていけたら嬉しい。

概要

範囲

この記事で「就活」の中でも特にインタビュープロセスについてフォーカスする。「就活」は「職に就くための活動」全般を指し、Resumeを出してインタビューに至る前の段階も含む。しかし、範囲が広がりすぎると要素が多くなりすぎるため、その部分については扱わないつもりだ。

したがって、以下の要素にはほぼ触れない：
・進学する学校の選び方
・キャリアの事前準備
・ポートフォリオの作成
・アウトプット活動
・LinkedInのプロフィール作成
・ネットワーキング

これらの広範なキャリア全体について知りたい場合は、このあたりのチャンネル (https://www.youtube.com/@kei_NA,　https://www.youtube.com/@frogagent) がすごく参考になるはずだ。

今回の対象範囲は、Resume提出からオファーを受け、契約に至るまでのプロセスにフォーカスする。また、次の条件を念頭に置いている：

• 業界：ソフトウェアエンジニア

• レベル：エントリーから中級（Intermediate上位、L4～）レベル

• 場所：カナダを中心に、北米。でも日本の外資系企業や一部のメガベンチャーにもあてはまると思う

なお、僕自身のポジション上、シニアやリードレベルに特化した情報は含まれないが、一部の内容は技術職（Tech）全般やプロダクトデザイナーなど、キャリアを積み上げたいと考えている人にも役立つと思ってる。

内容

また今回は以下のテーマをメインに書いてみるつもりだ。
・インタビュープロセスのスタイルと流れ
・インタビュープロセスの主要な要素と傾向

具体的には以下のように話を展開してく。
1. 選考プロセスの概要
全体の流れを俯瞰的に捉えるための情報を述べる。「木を見る前に森を知る」というように、詳細を知る前に、全体を知っておいた方が効率がいいので。
2. 選考プロセスの具体的要素
次に、インタビューでよくあるトピックや整理する。具体的にどのようなインタビューがあるのか、どのような質問がされるのかを掘り下げてカテゴライズする。
3. プロセス要素の傾向
2で挙げた具体的な要素をもとに、どのようなポジションや企業がどのようなインタビューを行いやすいのか、その傾向を考察する。
4. 準備の順番
1-3をもとに、何をいつを優先して手を付ければいいのか考察する。
5. まとめ
最後にインタビュープロセスの簡単な例と、まとめを行う。

これらに関する普遍的な部分を中心にまとめる予定だ。正直、この手の情報は古くなりやすいが、できるだけ今後5年、場合によっては10年程度は大きく変わらないと思われる内容を意識して書くつもりだ。もっとも、近年はAIの急速な発展により業界全体が大きく変化しているため、今後の予測が難しい点もあるが🧠

略語

本題に入る前に、この記事で使用する略語の一覧をまとめておく。文章が長くなってしまうため、略語を基本使用していく。基本的に、これらの略語は一般的にも通用する（検索すれば出てくる）ものだ。

1. 選考プロセスの概要

まずは北米のインタビューってどんな流れやねん、というところから

インタビューの流れ

インタビューは、大きく以下の3つのフェーズに分けられる。

Screening（足切りフェーズ）：
いわゆるフィルタリングにあたるフェーズで、「この候補者を本選考に進める価値があるか？」を判断するステップである。メインのインタビューではシニアやリードポジションの人が1時間くらい面接官として選考に時間を使う必要があるため、コストがかかる。応募者が多い中、全員を本選考で審査するのは当然現実的でないため、ここでResume（履歴書）やOA（オンライン選考）を使い、機械的に足切りを行う。またその後HRやリクルーターが関所の役割を果たし、資格がありそうな人だけを残す。

日本では、経歴があれば応募後にHRとの面談がだいたいでき、不採用であっても何らかの返事が来るのが一般的だが、これが北米や外資だと返事が来ないのが当たり前になって、SPIやOA試験への案内を受け取るだけでもレアケースである。人間と直接話せるまでの道のりが非常に遠いので、それを事前に理解しておくと心が折れにくい🌞

Main Process（選考のメイン）：
ここでは「この候補者が本当にこの会社で成果をだせるか」「チームの一員として入ってやっていけるか」を判断する。

このフェーズでは技術的スキルがガッツリ見られる。Techインタビューが2～3回以上あるのは普通で、業務に必要なスキルだけでなく、DSA（データ構造とアルゴリズム）やシステムデザインといった理論的な内容も問われることが多い。

さらに技術力だけでなく、ソフトスキルやコミュニケーションスキルなどのポテンシャル要素も見られる。加えて候補者が会社の文化や経営理念に合うか、いわゆるCulture Fitも重要な評価基準である。このため、配属予定のチームや直属の上司、それに近い人たちとのインタビューが行われる。準備すべき範囲が広く深く、時間と労力がかかる領域だが１つ１つ積み重ねることで確実に前に進める部分💪

Offer（最終調整フェーズ）：
候補者に対して、本当に採用して大丈夫かチェックする最終確認＆契約調整の場面。本選考を通過した段階で、即採用！となるわけではない。Offerはあくまで向こうからの提案に過ぎず、ビザの確認、入社日や給与の交渉、Reference Check（前職の確認）、契約書の精査、などお互いの確認作業が残っている。

これらがすべて完了し、最終的に契約書にサインをして初めてプロセスが終了となる。ここでも油断は禁物だ。ビザの問題やバックグラウンドチェックで引っかかる、もしくは契約内容が期待と異なるなどの理由でOfferが取り消されることもある。このため、緊張するが最後の最後まで慎重さを大体大丈夫な場面🎉

インタビューの形式

インタビューの具体的な内容に入る前に、形式について整理したい。オンラインか対面か、といった形式の違いを先に説明しておくことで、後半の具体的な要素をスムーズに理解できるようにするためだ。インタビューの形式は、大きく以下の4つに分けられる。

Online Assessment (OA) 
メールで送られてきたリンクからWeb上で課題を解く形式。基本的にリアルタイムで人と話すことはない。特に大手企業では、HRと話す前に大量の応募者をふるいにかける必要があるため、OAが実施されることが多い。コードを画面上で書いて提出する形式が主流。選択式のQ&Aや、日本のSPIのような適性検査が含まれることも。

Offline Assessment / Take Home Assignment
オフラインで課題を実装して提出する形式。OAがWeb上で直接実施するのに対し、こちらはローカルでコードを実装し、それをプルリクやZipファイルで提出する形となる。小～中規模の企業で採用されることが多い。提出した課題をもとに、後日インタビューを進めるケースが多い。

 対面（Virtual）
ZoomやGoogle Meet、電話などのオンラインツールを使ったインタビュー形式。全インタビューの大半がこれに該当する。

対面（On-site , In Person）
コロナ前によくあったオフィスに実際に足を運んで行うインタビュー形式。オンライン形式が主流になった現在では稀だが、最近はオフィス勤務が戻りつつあり、一部の企業でたまに行われる。めんどいが実際のオフィス環境や職場の雰囲気を体感できるのが大きなメリット。

2. 選考プロセスの具体的要素

ここではインタビュープロセスにおいて実際にどのような要素が重要視され、どのような準備が必要なのかをリストアップしたい。すべてを最初から完璧にする必要はないが、優先順位を意識して進めると幸せになれる。

共通トーク

始めにOfferフェーズ以外のどのインタビューでもほぼ必ず聞かれる共通の要素を挙げたい。

Small Talk：いわゆるアイスブレイクの挨拶。「How is it going?」と聞かれるので、「I’m fine! 」で終わらず、少しプラスアルファの答えをして雑談につなげるのがポイント。日本の面接にはあまりない文化だが、これを知っておくと北米スタイル習得の第一歩になれる😎。インタビューだけでなく、普段の仕事でも重要な要素。
Self Introduction：自己紹介。自分の経歴や職歴、今後のキャリアについて説明する部分。どのインタビューでも必ず聞かれる。目安としては30秒～3分程度、相手や状況に合わせて２，３パターン用意しておくと柔軟に対応できる😎
Interviewee Questions（逆質問）：会社に対する質問をする時間。自分が会社について深く知るための機会であると同時に、興味や積極性をアピールする場でもある。非常に重要なポイントなので、事前に準備しておくと強い😎

Resume（履歴書）

インタビューのすべての始まりであり、基本となる部分。

2024年現在、1つのポジションに100～1000人以上の応募が集まるのが当たり前の時代🤮。そのため、まずはATS（Applicant Tracking System）などのシステムを使って機械的にフィルタリングされる。

その後、HRやリクルーターが目を通し、さらに審査されるだけでなく、Tech Interviewの際にもResumeが基準として会話が発展するため。そのためどの場面でも使用されるので、しっかりと作り込むことで差をつけられる😎。

Status Check（ステータス確認）

職歴やスキルの以前に「この人、ちゃんと働ける資格あるんか？」という部分を確認する要素。

Resume提出時に追加情報として入力や選択が求められるか、書類選考を通過した後、HRやリクルーターと最初の面談で確認されることが多い。
チェックされる項目はおおよそ以下の通り：

• 働けるビザ

• 働き始められる時期

• 応募理由、なんで今の職場を離れようとしてる（した）のか

• リモート、出社の形態

• 現在住んでいる場所、リロケーションの可否

• 給与希望額

• 雇用形態（フルタイム、パートタイムなど）

この時点で条件を満たしていないと判断されると落とされるので、事前にこれらの項目をいい印象で回答できるようなると強い💪。

Work Experience（職歴確認）

Resumeをもとに、職歴が具体的にチェックされる。過去のポジション、使用していたTech Stack、担当していた業務内容、そしてどんな成果を出したのかが確認される。

スクリーニングの段階でフィルタリング目的で人事に聞かれるし、また後半でスキル評価の目的でTechインタビューでも頻繁に確認され、面接の段階や担当者によって質問の深さや内容は異なる。なのでHRやリクルーター、TechチームのManagerやエンジニアなど、話す相手を意識して準備しておくと突破率があがる🌞。

Behavioral Questions

行動面接と翻訳されるがいわゆる「今まで一番大変だったことは？長所短所は？」みたいな質問

聞かれる目的は、主に技術者としての職歴や過去の経験とともに、ポテンシャルを測ることにある。つまり「今までどんな💩を乗り越えてきたか」を確認することで「今後の💩もどれだけ乗り越えられるか」をアピールする場所である。

行動面接はScreeningフェーズで軽く聞かれることもあるが、本選考（特にTech interview）でガッツリ質問されるケースも多い。軽視されがちだが立派なインタビュー項目であり、対策する価値がある要素

Tech Quiz

コーディングを伴わない、口頭形式の技術質問。いわばQ&Aスタイルの技術クイズのようなもの。本選考（Tech interview）の中で行われることが多い。

具体例をあげると、特定のフレームワークや言語について聞かれることもあれば、もう少し全体的または理論的な質問を問われることもある。基本的にはJDに関係したものが聞かれやすい。

例えばフロントエンドだと
・ReactのHooskってなに？useState、useEffectっていつ使うねん
・JSのasync awaitとpromiseの違いってなんやんねん
もう少し一般的な概念だと
・SQLとNoSQLの違いは？
・Array と HashMapの違いは？
・DI（依存性注入）とは何か？
みたいなもの色々

Coding: Hands-on Programming

いわゆる、「アプリや機能の一部を実際にコーディング実装してね」というタイプのテスト。

たとえば、ToDoリストを作る、画像をfetchして一覧表示する、ログイン画面を実装する、などがある。設計力も問われるが、特にフレームワークや言語への精通度、そして実際の実装力が求められる。フロントエンドポジションの方がでる機会が多い印象。

基本的にはペアプロ形式でリアルタイムで進めることが多いが、事前に課題を提出させ、それをもとにインタビューでコードの説明やレビューをするスタイルもある。

*ちなみに「Hands-on Programming」という呼び名は一般的ではなく、自分が便宜的に作った略称。もっといいのがあったら誰か教えてください🫨

Coding: Low Level Design (LLD)

特定の機能をどう設計するかを問われるテスト。Hands-on と違い、具体的な実装よりも設計に重点を置いた内容。実行環境がない場合が多く、抽象度が高めで、やや俯瞰した視点が求められる。

たとえば、「Item情報を更新するAPIを作るには？」「ファイル検索を行うアプリを作るには？」などがある。特定のフレームワークや言語に依存せず、Presudo codeを用いて設計力を図る。体感的にDSAやSDよりも頻度は少ないイメージ。
こんな感じ  https://www.youtube.com/watch?v=1qw5ITr3k9E

OOP設計やアルゴリズムを求められる場合もあるし、インターフェース設計、データベースとのやり取り、ロジック、ログ出力、エラーハンドリングなど運用を考えた設計力が見られる場合もあり。正直ひと括りにしにくい分野。なので事前に会社を下調べするか、インタビューアーとのやりとりで何が求められるか明確化するとかなり楽になれる💪

Coding : High Level Design (HLD)

別名System Design(SD)とも言われるテストで、TwitterやDropboxのようなシステム全体の設計がテーマになる。

LLDが1つのサーバー内で行う具体的な設計だとすれば、HLDは複数のLLDを統合したシステム全体をどう設計するかを問われる。たとえば、サーバー同士の通信方法やDBの構成、キャッシュなどを含めたプロダクト全体のアーキテクチャを考える必要がある。
こんな感じ：https://www.youtube.com/watch?v=_K-eupuDVEc

Presudocodeも書く機会は少なく、要件定義や図での説明が求められる。どういうサーバーやDBが必要か、ScalabilityやConsistencyをどう実現するか、といった視点も重要となる。Back End経験があると非常に強い。また未経験でもSDを勉強することでBack Endの基礎知識がつく💪

Coding: Data Structure and Algorith (DSA)

いわゆるLeetCodeのような問題で、アルゴリズムやデータ構造を問われるテスト。HLDとは逆に、プログラミングのもっと根幹的な部分、Low Layerを測る内容。

Array、HashMap、Treeといった基本的なデータ構造を理解しているか、また、それを使った効率的なアルゴリズム設計ができるかをテストされる。
こんな感じ：https://www.youtube.com/watch?v=rw4s4M3hFfs

入り口部分の基礎的な内容はSWEにとって必須だが、発展的な問題になると実務とはかけ離れたものも多い。それでも、フィルタリングと評価が簡単にしやすいという理由から、多くの企業が選考手段として取り入れている。そのため「実務ではほとんど使わないのに対策と準備がクソだるい」とネタにさえる分野🤪

*ちなみにAtCoderのような競技プログラミングはインタビューは想定してなく、一部領域が微妙に異なる。70％くらい重なってるイメージ

Culture Fit、Work Style

一言で言うと、「バイブスが合うか」が見られる。

基本的な働く条件やスキルをクリアした上で、この会社やチームの理念、人間性が合うかをチェックされる。もっと端的に言えば、「われわれのチームはこいつと一緒に働きたいと思うか」

Culture Fitという項目が明確に設けられたインタビュー枠がある場合もあれば、SPI試験のような選択式でOAの段階で機械的にフィルタリングされることもある。また、特別な枠がなくても、ほぼすべてのインタビューで何となく見られている部分でもある。

正直なところ、最終的には「人と人」の感覚に依存する部分が大きい。逆にいえば多少経験不足でも気が合って「こいつと働きたい」と思わせられば受かりやすくなる😎

Reference and Background Check

オファーとは別に、最後の最後にその人がほんまに大丈夫か第三者の客観的評価によって審査するフェーズが会社によってはある。主に２つありReference CheckとBackground Checkといわれるもの。

Reference Checkは、過去の職歴を確認するプロセス。選考中の会社に対して、過去に働いていた会社の上司やマネージャーの連絡先を提供する。その連絡先に電話やメールで問い合わせを行い、「この人は本当にこの役職で働いていましたか？」といった確認をする。地味に手間がかかる部分ので、過去にちゃんと働いて信用を得てる実績があると嬉しい✨

Background Check（Criminal Check）は、犯罪経歴を確認するプロセス。多くの場合、選考中の会社から送られてきたリンクを開き、IDや個人情報を入力して確認してもらう形になる。感覚的にはビザの審査に似ている。

これらのチェックは、会社によって進め方が異なる。チェックが完全に終わってから正式なOfferが出る、ってパターンもあれば、 契約書のサインと同時に進行し、チェックが完了次第、契約が有効になるケースも。中小企業ではこのフェーズを省略することが多いが、大手企業ほど厳密に行う傾向がある。

Offer, Sign

オファー。最後のやつ。すべての面接をパスしたあと、ＨＲからオファー電話がかかってくる。（事前に一声メール案内がくる場合が多い）

インタビューではないが、この電話ではスクリーニング時に確認したビザ、働き始める日、給与交渉、雇用形態などを最終的にもう一度確認する場面である。その後、契約書がメールで送られてくるので、内容をしっかり確認することが重要。思わぬところで当初の話と違っていたり、ビザやCOOPに関する追加の話が出る場合もあるため、非常に重要なステップである。そして嬉しいフェーズ🎉

3. 選考プロセスの傾向

色々あげたので「多すぎやろ」となるかもしれない。が、すべての選考でこれだけのことが毎回聞かれるわけではない。実際には企業の規模や応募ポジションによって、どの要素が重視されるかは全然変わる。そのため、状況に応じて必要な準備を適切なタイミングで進めることができれば嬉しい。

以下では、自身や他人の経験をもとに、選考プロセスの傾向を整理してみた。

小規模〜中規模の企業

小〜中規模の企業では、主に「Tech Quiz」「Hands-on Programming」「軽めのBQ」を聞いてくることが多かった。具体的には次のような特徴：

• OAによるフィルタリングがない

• DSA、HLD、LLDなどのインタビューはほぼない

• Tech Quiz が多く、JDに関連した特定のフレームワークや言語に関する質問が出やすい

• Coding interviewではHands-on Programming がメイン。実際のJDに沿ったUIやAPIのアプリ実装が求められることが多い

• BQ は聞かれる場合もあるが、内容は抽象的で深掘りされにくい。数も少なめ

• ReferenceやBackground Check が省略される場合が多い

• 全体的にインタビューの回数が少なく（3〜4ステップ以下）、結果通知や次のインタビューへのスケジュール設定が早く、スピード感が重視される

中規模〜大規模の企業

一方、中〜大規模の企業では、「DSA」「HLD」「LLD」「重めのBQ」「Reference/Background Check」がよくあった。具体的には以下のような特徴：

• OAによる事前フィルタリングが行われることが多い

• 実行/ビルドが必要なUI、API実装課題は少ない

• Coding Interviewでは、DSA、HLD、LLDが多い

• Tech Quizは特定のフレームワークや言語に関する質問よりも、CSやSWEに関する概念や理論的な内容が問われることが多い。それかそもそも存在せず、DSAやHLD/LLDのやりとり中で間接的に評価される場合が多い

• BQ は頻繁に聞かれ、内容も具体的に深く掘り下げられる

• オファー前後でReferenceやBackground Checkが行われることが一般的

• インタビューの回数が多く（4〜5ステップ以上）、次のインタビューまでの期間が長め（結果通知やスケジュール調整に時間がかかる）で、慎重なプロセスが特徴

なんで？

これらの違いとして、僕は以下のように考えてる

• 企業の規模とリソース
  大きな企業ほど予算と時間に余裕があり、また応募者も多いため、選考プロセスに回数と時間をかけることが可能である。

• 即戦力よりポテンシャル重視
  中〜大規模の企業では、特定分野の即戦力というよりも、SWEとして幅広い領域に対応できるポテンシャルのある人材を重視する傾向がある。

• 理論や教養の重視
  そのため、CSや技術の理論・教養を重要視しがちである。

• 評価基準の違い
  小規模な企業が特定のフレームワークや実装力を重視する一方で、大規模企業では、BQやDSA、HLD/LLDを通して、設計力やソフトスキルを評価する傾向が強い。

逆に言えば、小規模企業では迅速な対応と特定分野での技術力、そして大規模企業では幅広いスキルセットと深い基礎知識が求められる、と考えてる。

4. 準備の順番

まずは応募

具体的に「何から手をつけたらいいねん？」と思うかもしれないが、まずは何より応募してみることをおすすめする。まず応募を進めると何が嬉しいかというと、自分の履歴書やプロフィールの不足点が見えてくる。また、応募に必要な情報が揃っていないことや、自分のスキルを改めて整理するきっかけにもなる。

応募しても企業からの反応には時間がかかることが多い。実際に応募してみて、結果が悪かった場合に「何が足りないのか」「どの方向を強化すべきか」が見えてくるのに、2～3か月ほどかかってしまうのだ。

たとえば、上のようにすべてを完璧に終えてから次のアクションに進む戦法をとると、フィードバックを得るのが遅くなり、最初の改善点が見えるまでに総合的な時間がかかってしまう。

そこで下のようにまずは応募を進めつつ、足りない部分を同時並行で補っていくほうが早い段階でフィードバックを得て軌道修正がしやすくなる。

「ポートフォリオを完成させてから」「今のプロジェクトが終わってから」といった考えにこだわる必要はない。どんだけ時間をかけて完璧に準備したとしても、結局あとで修正が必要になることがほとんどなのだ。ウォーターフォールとアジャイルの対比に似てるかもしれない。

※ただし、ポートフォリオで大きな差がつくプロダクトデザイナーやビジュアル優先の超フロントエンドの場合は、応募の段階で高い品質のものを提出しないといけないので、このケースにあたはまらない場合も

DSAやHLDはいつ？

「LeetCodeってやっぱやったほうがいい？」というのを僕はよく聞かれる。DSA、HLD、LLDについても同様にいえるのだが、これは狙うポジションと会社によって変わってくる。

なので前述の通り、もし大規模な企業でSWEやバックエンド中心を狙う場合に必要になることが多い。これらの領域はかなりの準備期間が必要で、1から始めるならDSAとHLDだけでも最低半年、1年かかっとしても早いほうだ。したがって、自分が「何をいつ狙うのか」を明確にし、それに基づいて逆算して準備を進めるのが良い。ただこれも普通の応募同様に、完全に準備してから、とういよりは応募して必要性を生み出して、それをモチベに対策、修正するのもありだと思ってる。

なので結局は状況次第ではあるが、渡航で大きな会社を目指す場合、最初の数年間はビザや職歴の確保を優先するために、小規模から中規模の企業で経験を積むのが一般的な戦略となる。その間に、DSA/HLD/LLDの対策を進めながら応募と練習を繰り返し、少しずつ目指す企業の規模を大きくしていくというパターンが１つの王道だと思ってる。

*また具体的に自分の狙ってる会社やポジションDSA、HLDをやる可能性があるか知りたい場合は、一回ググってみるとよき。大体はGlassdoor (転職会議やOpenWorksのようなやつ)のインタビュー枠、LeedCodeのDiscussion枠、Redditに過去の記録がのってる。そしてググっても記録がない場合は、小規模な会社の可能性が高く、DSA、HLDをやる可能性が低い。

5. まとめ

Example Case

これまでの内容をもとに、実際のインタビューの流れの例をあげてたい。以下は、タイムラインに沿って、どの段階でどのようなことが聞かれるかをざっくりまとめた図を作成したものだ。

この図では、横軸を時系列、縦軸を会社の規模感として示している。もちろん実際は会社によって順番が異なったりスキップすることもあるので、あくまで平均的な傾向を示す指標になる。個々のケースに応じて柔軟に対応する必要があるが、大まかな流れや全体像を把握するための参考になれば嬉しい。

以下に、小規模と大規模の2つのインタビュープロセスの例を挙げてみた。当然ながら、すべての企業がきっちりこの2パターンに当てはまるわけではなく、中間的なケースも存在する。ただし、頭の中でこの2つを意識しておくと整理しやすく、今、今後何をすべきか、というアクションに役立つ。

ケース1: 小規模な企業（Web Front）の場合

・応募: 会社の応募ページから履歴書を提出。
・初回面談: HR（またはリクルーター）と30分の電話面談。ステータスや職歴の軽い確認。
・Tech Interview 1: Tech Managerと30分の職歴確認 + 簡単なTech Quiz。
・Tech Interview 2: Tech Team（Senior）と1時間のコーディング面接でReactによるLog In 画面の実装
・Culture Fit Interview: Tech Leadとの30分間のカルチャーフィット面談。
・内定案内: HRから電話でオファーを受け取り、ステータスや働く日付など最終確認
・契約書サイン後、就職🎉😎

ケース2: 大規模な企業(Software Engineer)の場合

・応募: 企業のポータルサイトからResumeを提出。
・OA: アルゴリズム（DSA）+ 選択式のWork Styelに関する2時間の試験。
・初回面談: HR（またはリクルーター）と30分間の電話面談。ステータスや職歴の確認、次の面接案内。
・Tech Interview 1: Tech Team（中堅レベル）と1時間のDSA + BQ
・Tech Interview 2: Tech Seniorと1時間とDSA+ BQ + 職歴確認。
・Tech Interview 3: Tech Team（中堅レベル）と1時間のLLD+ BQ
・Tech Interview 4: Tech Leadと1時間のHLD+ BQ + 職歴確認。
・内定案内: リクルーターから電話でオファーと今後の流れを案内
・Reference & Background Check: リファレンス確認と身辺調査。
・契約書サイン後、審査に通って就職🎉😎

余談

また最後に対策のゲーしすぎて、僕が陥った注意点も書きたい。一時期、テンプレの型にはまりすぎた時期があった。マニュアル的な内容を学びすぎて、予想外の質問や状況に対応する柔軟性を失予想外の問題に出くわす度「は？これ、進研ゼミで習ったやつとちゃうやんかー！？」って感じになってパニクることが多かった。ただ振り返ってみると、これまでたくさんのインタビューを経験したが、すべてがパターン通りやってくれたインタビューはほとんどなかった。どのインタビューも2～3割は必ず想定外の質問やスタイルをやってきたと思う。そのとき、想定外のことばかりに気を捕らわれるのではなく、残りの対策できた7～8割の土台を活かして柔軟に対応できたときから、インタビューはマジでうまくいった。正直、面接官も予想外の内容に対して、どうやって対応するかも見てるかもしれない。

たとえば、僕が経験しておもしろかったインタビューの例を挙げると、small talkや自己紹介が全くなく、いきなり問題を聞かれるパターンもあった。問題がすべて口頭で伝えられ、「自分でメモってね」と言われたこともある。ResumeからGitHubのリンクをたどって、「その中で一番自信のある成果物はなに？」と直球で聞かれたこともあった。SD対策（システムデザイン）をしたのに、全然一般的じゃない難しいお題を出された経験もある。さらには、Tech interviewだと聞いていたのに、40分間ずっとBehavioral Questions（BQ）だけを聞かれ、話すネタが尽きてしまったこともあった。中には、AI試験官のようなウェブシステムが登場して、CELPIPやTOEFLのスピーキングテストみたいにひたすらAIに向かって話すだけの面接もあった。インタビューとは、まさに「happy accident」の塊だ。

おわりに

以上で北米で数年間就活をし、自分や周りの経験をもとに、主観的にまとめてみた。今回挙げた各要素については、時間と余裕があれば、今後さらに各パートごとに詳しく別記事としてまとめるかもしれない。最初に述べた通り、就活は情報と対策が大きな鍵を握る。

今回挙げた内容をすべて実行するのは確かに量が多く大変だ。だからこそ、1つ1つ分解して優先順位をつけ、トライアンドエラーを繰り返しながら進められれば強い。結局のところ、考えて分析し、試し、結果をもとにプランを修正して実行するというサイクルを粘り強く続ける胆力が成功の鍵だと思っている。逆にいえば、一度にすべてやる必要はなく、日々少しずつ積み重ねれば、それがやがて大きな成果につながる。そして一度得た知識やスキルは（それがたとえ就職できなかったとしても）、今後のキャリアや実際の仕事でも長く活きるものになると信じている。またみなさんの経験や意見も大歓迎だ。今回の内容が少しでも参考になれば嬉しい。