技術面接の英語語彙——FAANGのオファーを勝ち取る80語

---

TL;DR：3つのポイント

• 英語での技術面接は二重の負荷——CSの知識を示すだけでなく、第二言語で正確に言語化する力が問われる。多くの非ネイティブが落とすのは概念ではなく伝え方。
• 4カテゴリー80語でアルゴリズム、システムデザイン、行動面接、プロフェッショナル英語のコネクタをカバー。実際に必要な語彙だけを厳選。
• STARメソッド（Situation, Task, Action, Result）はあらゆる行動面接質問の構造的な背骨。各要素の語彙を押さえることは交渉の余地なく必須。

---

技術面接の語彙が「隠れた決め手」になる理由

LeetCodeは解ける。最適な計算量もわかる。実プロダクションでコードを書いてきた経験もある。なのに面接官に「walk me through your approach」と言われた瞬間、頭が真っ白になる。答えがわからないからではなく、それを英語で説明する言葉が出てこないから。

これは珍しい話ではありません。FAANGや最上位スタートアップの面接を受ける非ネイティブにとって、ほとんど「あるある」の状況です。

競争の激しいエンジニア採用では、技術力のバーは「フィルター」であって「差別化要因」ではありません。LeetCodeのMediumを誰もが解ける環境では、コミュニケーションの質こそがオファーと不採用を分けます。Google、Meta、Amazon、Microsoftの面接官は、思考をいかに明確に言語化できるか——トレードオフを説明する力、システムの制約を描写する力、行動面接の事例を精度高くフレーミングする力——を明示的に評価しています。

中国人、日本人、韓国人エンジニアは技術スキルでは世界トップクラスにありながら、このコミュニケーション・ギャップで不釣り合いに損をしてきました。非ネイティブ話者の高ストークス口頭評価に関する研究は一貫して示しています。「無能に見える」原因の主因は文法ミスではなく語彙の欠落です。言いたいことはわかっている。ただ、その瞬間に正確な単語が出てこない。

この課題には4つの次元があります。

**第一に、技術語彙は抽象的です。**Algorithm、complexity、bottleneck、trade-off——これらの単語には東アジア言語に直接の対応語がないことが多い。翻訳ではなく、英語の概念として学び直すしかありません。

**第二に、行動面接の語彙はカルチャー由来です。**Ownership、ship it、rubber duck debugging、retrospectiveといった単語はカルチャー固有。シリコンバレーのエンジニアリング文化が背負っているニュアンスを、字面の翻訳では拾えません。

**第三に、流暢さよりも精度が大事です。**面接官はネイティブ並みの発音を求めていません。求めているのは正確さです。「This solution is O(n log n) which is better than the naive O(n²) approach, but the trade-off is increased space complexity」と言えば知性が伝わります。曖昧な英語はその逆を伝えます。

**第四に、プレッシャー下でコミュニケーションは劣化します。**緊張は語彙へのアクセスを狭めます。半分しか知らない単語から最初に消えていく。解決策は「リラックスすること」ではなく、プレッシャー下でも引き出せるレベルまで語彙を自動化することです。

このガイドでは、面接コンテキスト別に整理した80語を、定義とパーソナライズされた例文とともに提示します。さらに、明晰な思考を伝える構造的フレームワーク（STAR、システムデザインの言語、プロフェッショナルなコネクタ）も収録しています。

---

セクション1：4カテゴリーで覚える技術面接の80語

各エントリーは3要素で構成されています——単語またはフレーズ、面接特有の定義、中級レベルのパーソナライズされた例文。教科書的な文ではなく、実際に面接で使うような文です。

カテゴリーA：データ構造とアルゴリズムの語彙

コーディング面接で必ず使う20語。自分の解法が何をするか、どう動くか、なぜその選択をしたかを説明する言葉です。

単語・フレーズ	面接での定義	例文
algorithm	問題を解くための段階的な手順	"My algorithm processes each node once, so it runs in linear time."
complexity	入力サイズの増加に対するリソース使用量の伸び方	"The complexity of this approach improves from quadratic to linearithmic with a better data structure."
time complexity	アルゴリズムの実行時間が入力サイズに対してどうスケールするか	"The time complexity of binary search is O(log n), which makes it efficient for large datasets."
space complexity	入力増加に対して追加のメモリをどれだけ使うか	"By reusing the input array instead of allocating a new one, I reduced the space complexity to O(1)."
optimization	解法の効率や正確性を改善するプロセス	"The first step in my optimization was to eliminate redundant computations inside the inner loop."
iterate	通常はループを使って同じ処理を繰り返し適用すること	"I iterate through the array once, keeping track of the maximum value seen so far."
recursion	関数が自分自身を呼び出して、同じ問題のより小さい版を解く技法	"Recursion is natural here because the tree structure is self-similar at every level."
trade-off	何かを良くすると別の何かが悪くなる状況	"The trade-off between time and space complexity is the central design decision in this problem."
edge case	想定値の境界にある入力や条件	"I should handle the edge case where the input array is empty before entering the main logic."
bottleneck	システム全体のパフォーマンスを制限している部分	"Profiling revealed that the database query was the bottleneck, not the sorting algorithm."
latency	命令を発行してからデータ転送が始まるまでの遅延	"Adding a cache reduces latency for repeated requests because the data no longer needs to be recomputed."
throughput	単位時間あたりに完了する作業量	"To increase throughput, we can process requests in parallel instead of sequentially."
scalability	負荷が増えても性能が劣化しないシステムの能力	"The design lacks scalability because every new user doubles the number of database writes."
refactor	外部の振る舞いを変えずに既存コードを再構造化すること	"I would refactor this into a helper function to make the logic reusable and easier to test."
modular	独立して交換可能なコンポーネントで設計されていること	"Keeping the code modular means we can swap out the sorting function later without touching the rest."
abstraction	実装の詳細をシンプルなインターフェースの裏に隠す原則	"Using a stack as an abstraction here means the calling code doesn't need to know how the data is stored internally."
encapsulation	データとそれを操作する関数を一つにまとめ、内部状態を隠すこと	"Encapsulation keeps the class's internal state safe from external modification."
debugging	コードのエラーを特定し修正するプロセス	"During debugging, I added logging statements at each step to trace where the value was going wrong."
iteration	ループを1周すること、または繰り返し処理の1サイクル	"Each iteration of the outer loop processes one row of the matrix."
constraint	入力・時間・メモリなどに対する制限で、有効な解の空間を形作るもの	"Given the constraint that the array is sorted, we can rule out any O(n²) approach."

---

カテゴリーB：システムデザインの語彙

システムデザイン面接は「スケールで考えられるか」を問うものです。これら20語は分散システムの語彙——「URL shortenerを設計してください」「Twitterをどう作りますか」と聞かれたとき、面接官が期待している言語です。

単語・フレーズ	面接での定義	例文
architecture	システムの高レベル構造とコンポーネント間の相互作用	"Before diving into components, I want to describe the overall architecture and then zoom into each layer."
microservices	アプリケーションを小さく独立してデプロイ可能なサービスの集合として構築する設計アプローチ	"Migrating from a monolith to microservices allowed each team to deploy their service independently."
monolith	すべてのコンポーネントが密結合した単一の統合アプリケーション	"Starting as a monolith makes sense here — we can extract services later once the domain is better understood."
distributed system	複数のコンピュータがネットワーク経由で通信して動くシステム	"In a distributed system, we have to assume that any node can fail at any time."
load balancing	リクエストを複数サーバーに分散させ、特定の1台に負荷が集中しないようにすること	"Load balancing across three server instances ensures no single server becomes a bottleneck."
caching	アクセス頻度の高いデータを高速メモリに保存して取得時間を短縮すること	"Caching the top 1% of URLs would handle the vast majority of read traffic without hitting the database."
database sharding	データベースを複数マシンに分割して、より小さく速く管理しやすい単位に分けること	"With 10 billion rows, database sharding by user ID would keep each shard's size manageable."
redundancy	信頼性と可用性を高めるためのコンポーネントの冗長化	"Adding a secondary replica provides redundancy — if the primary fails, traffic fails over automatically."
fault tolerance	一部コンポーネントが故障してもシステムが正常に動き続ける能力	"Fault tolerance at this layer means replicating the message queue across three availability zones."
consistency	分散システム内のすべてのノードが同じデータを同時に見られる保証	"There's a fundamental tension between consistency and availability in a distributed database."
availability	システムが稼働しアクセス可能な時間の割合	"The design targets 99.9% availability, which allows for less than 9 hours of downtime per year."
partitioning	データや機能を複数ノード・システムに分割すること	"Horizontal partitioning by region reduces cross-region latency for most users."
API gateway	クライアントからのすべてのリクエストの単一エントリーポイントとなり、適切なサービスにルーティングするサーバー	"The API gateway handles authentication and rate limiting before requests reach any internal service."
rate limiting	一定時間内にクライアントが送れるリクエスト数を制御すること	"Rate limiting at 1,000 requests per minute per user prevents a single client from overwhelming the system."
message queue	プロデューサとコンシューマの間でメッセージを保持し、両者を疎結合にするバッファ	"Using a message queue means the notification service can fall behind without affecting the core transaction flow."
pub/sub	パブリッシャがトピックにメッセージを送り、サブスクライバが受け取るメッセージングパターン	"The pub/sub model here means adding a new consumer — say, an analytics service — requires zero changes to the publisher."
CDN	Content Delivery Network——地理的に分散したサーバー網で、ユーザーに近い場所から静的コンテンツを配信する	"Serving static assets through a CDN reduces page load time from 800ms to 90ms for users in Asia."
horizontal scaling	負荷増加に対応するためマシンを追加すること	"Horizontal scaling is preferable here because the workload is stateless and easy to distribute."
vertical scaling	単一マシンの容量（CPU、RAM、ストレージ）を増やすこと	"Vertical scaling has a ceiling — at some point you can't buy a bigger server, and the cost grows non-linearly."
technical debt	今より速く簡単な解決策を選ぶことで生じる、後でより多くの作業を要するコスト	"The current implementation has significant technical debt — we took shortcuts to hit the launch deadline that we'll need to pay back."

---

カテゴリーC：行動面接の語彙

行動質問（"Tell me about a time you..."）は「ソフト」な質問ではありません。判断力、協働、インパクトを構造的に評価する場です。これら20語はその評価の語彙です。

単語・フレーズ	面接での定義	例文
initiative	指示されなくても自律的に動き、必要なことを先回りすること	"I took the initiative to write the post-mortem document before the team lead asked, which helped us identify the root cause faster."
accountability	失敗も含めて自分の行動と結果に責任を持つこと	"When the deployment caused a 30-minute outage, I owned the accountability — I wrote the incident report and presented it to the team."
stakeholder	プロジェクトの結果に利害を持つ、または影響を受けるすべての人	"Aligning with stakeholders early meant we avoided a three-week rework cycle when requirements changed."
cross-functional	異なる部署や専門領域の人やチームが関わること	"I led a cross-functional effort between engineering, product, and legal to ship the data privacy feature on time."
ownership	公式な役割を超えて、プロジェクトや領域を自分ごととして扱う姿勢	"Ownership in this context meant I stayed through the incident until the root cause was resolved, even though it wasn't technically my service."
retrospective	プロジェクトやスプリントの後、何が良くて何を改善すべきかを振り返る構造化されたミーティング	"After the launch failure, we ran a retrospective and identified three process gaps we've since addressed."
iterate (agile)	動くバージョンを早くリリースし、フィードバックをもとに繰り返し改善すること	"We chose to iterate on a minimal version first rather than spend six months building the complete solution."
ship	機能やプロダクトをユーザーにリリースすること	"The goal of that sprint was to ship a working prototype that internal users could test before the end of Q3."
feedback loop	結果に関する情報を集めて、次の行動の改善に活かす仕組み	"We added user analytics to create a tighter feedback loop — we could see within 48 hours whether the change was working."
scope creep	プロジェクトの要件が当初の境界を超えて徐々に膨らんでいくこと	"Scope creep was the primary risk — we had to make a deliberate decision to defer three features to the next release."
align	異なる関係者を共通の理解や方向性に揃えること	"Before writing a single line of code, I aligned with the product manager on what success looked like."
escalate	現場で解決できない問題を、上位の権限者やシニアメンバーに引き上げること	"When I couldn't get a decision on the API contract, I escalated to my manager, who resolved it with the other team lead in one meeting."
prioritize	タスクや目標を相対的な重要度・緊急度で順序づけること	"Given the two-week deadline, I had to prioritize the features by user impact and deprioritize anything that wasn't on the critical path."
impact	ユーザー、ビジネス、技術成果に対する自分の仕事の測定可能な効果	"The impact of the caching layer was a 60% reduction in database load, which directly lowered our infrastructure costs."
influence	公式な権限がない状況でも、他者の方向性・行動・意見を変えること	"I influenced the team's decision to adopt the new framework by writing a comparative analysis and presenting it at the tech review."
mentor	アドバイス、フィードバック、知識共有を通じてジュニアメンバーをガイドし育てること	"I mentored two junior engineers during my time there, pair-programming with them weekly and reviewing their design documents."
collaborate	共通のゴールに向けて他者と協働し、能動的に貢献し連携すること	"The feature required me to collaborate closely with the mobile team, which meant daily syncs and shared documentation."
deliver	合意したスコープ・品質・期限の中で動く成果物を完成させ引き渡すこと	"Despite the ambiguous requirements, I delivered a working API within the sprint timeline by making early, explicit assumptions and validating them."
pivot	新しい情報や結果に基づいてアプローチを大きく変えること	"Three weeks in, user testing showed our initial approach was wrong. We had to pivot quickly, which meant cutting two planned features."
drive	能動的な努力とリーダーシップでプロジェクトやゴールを前進させること	"I drove the migration project from start to finish — coordinating across four teams and delivering it two weeks ahead of schedule."

---

カテゴリーD：面接で使うプロフェッショナル英語

技術用語ではありません。面接コミュニケーションをつなぐ「結合組織」、明晰な思考を示し、発言を適切に限定し、面接官の質問にしっかり噛み合わせるためのフレーズ群です。

非ネイティブの多くは技術語彙は知っていてもこのプロフェッショナルなコネクタを持っていません。これがないと、答えがブツ切りに、自信過剰に、あるいは曖昧に聞こえます。あれば、構造的でシニアな印象になります。

フレーズ	機能	面接での例
elaborate	これから詳細を追加するという合図	"Could you elaborate on the scale requirements? That would change my design significantly."
clarify	進む前に曖昧さを確認・解消する	"Before I start, I want to clarify — are we optimizing for read performance or write performance?"
rephrase	質問やアイデアを言い換えて理解を確認する	"Let me rephrase that constraint to make sure I have it right: we have a 100ms SLA for 99th percentile response times?"
walk through	思考を段階的にガイドする	"Let me walk through my reasoning before I write any code."
break down	複雑な問題を小さな部分に分割する	"I'll break down the problem into three components: data modeling, API design, and caching strategy."
in terms of	どの軸で議論しているかを明示する	"In terms of time complexity, this is optimal. The question is whether the space trade-off is acceptable."
to elaborate	より詳細な説明を導入する	"To elaborate on the latency concern — the bottleneck is the synchronous call to the third-party API, which we can't control."
to circle back	先に触れた論点に戻る	"I want to circle back to the edge case I mentioned — it becomes important once we consider the concurrent write scenario."
approach	提案している全体的な手法・戦略	"My approach would be to start with a simple solution, establish correctness, and then optimize."
considerations	意思決定に影響すべき要素	"The main considerations here are consistency requirements, expected read/write ratio, and team familiarity with the technology."
trade-offs	選択肢ごとのコストと利益	"There are real trade-offs between these two designs, and the right choice depends on the read/write ratio."
in my experience	個人的な経験で発言を裏付ける	"In my experience, starting with a monolith and extracting services later is less risky than starting distributed."
I'd argue that	弁護する用意がある立場を提示する	"I'd argue that the additional complexity of microservices isn't justified at this scale."
one way to think about it	メンタルモデルや類比を提示する	"One way to think about this is that the cache is a buffer between the fast and slow parts of the system."
that said	直前の論点を認めたうえで反論を導入する	"That said, there are scenarios where the simpler approach would fail — specifically, high-concurrency writes."
to be specific	これから具体例を示すという合図	"To be specific, I reduced query time from 1.2 seconds to 40 milliseconds by adding a composite index."
building on that	すでに述べた論点を拡張する	"Building on that — if we add a read replica, we can handle the read scaling without changing the write path at all."
to your point	面接官の発言を受けて噛み合わせる	"To your point about consistency — you're right that eventual consistency won't work here given the financial nature of the data."
the crux of the matter	中心となる最重要ポイントを特定する	"The crux of the matter is whether we prioritize write throughput or read latency — everything else follows from that decision."
it depends on	答えが文脈依存であることを認める	"It depends on the access pattern. If reads far outnumber writes, a cache makes sense. If writes dominate, it adds complexity without benefit."

---

セクション2：STARメソッド語彙ガイド

STARメソッドは行動面接における最も重要なフレームワークです。主要テック企業（Google、Amazon、Meta、Microsoft、Apple）はすべてコンピテンシーベースの行動評価を明示的に採用しており、STARはその期待される回答構造です。

STARの中身：

• Situation——文脈と背景。どこにいて、何が起きていたか。
• Task——あなた特有の責任。何をすることが期待されていたか。
• Action——実際に取った具体的なステップ。
• Result——測定可能な成果。あなたの行動の結果として何が起きたか。

面接官が望む比率はおおよそ10% / 15% / 50% / 25%です。多くの候補者がSituationに過剰投資し、ActionとResultが薄くなる。語彙が最も効くのはここです。

STARの開き方フレーズ

Situationを開く（場面を素早くセットする）：

1. "This happened during my time at [company], when our team was responsible for..."
2. "The context was a critical migration project with a hard deadline of..."
3. "We were in the middle of a product launch when..."
4. "Shortly after I joined the team, we encountered a situation where..."
5. "During Q3 of last year, our service started experiencing..."

Taskを開く（自分の担当を明示する）：

1. "My specific responsibility was to..."
2. "I was accountable for delivering..."
3. "The task fell to me because..."
4. "I owned the end-to-end design and implementation of..."
5. "The team needed someone to drive the..."

Actionを開く（イニシアチブと思考を見せる）：

1. "The first thing I did was..."
2. "I started by breaking the problem into three components..."
3. "My approach was to first understand the root cause before proposing any solution..."
4. "I decided to escalate early, because..."
5. "Rather than accepting the existing approach, I proposed an alternative by..."

Resultを開く（数字でリードする）：

1. "The outcome was a [X]% improvement in..."
2. "As a direct result, we reduced [metric] from X to Y..."
3. "The feature shipped on time and within budget, and subsequently..."
4. "We received direct feedback from the engineering director that..."
5. "The impact was significant: specifically, [quantified outcome]..."

STAR完全回答の例

質問："Tell me about a time you dealt with a difficult technical problem."

Situation： During my second year at the company, our main product API started experiencing intermittent 500 errors that only appeared under high load — specifically during peak traffic hours. The errors were non-deterministic and difficult to reproduce in staging.

Task： I was assigned as the engineer responsible for identifying the root cause and resolving the issue. The constraint was that we had a major customer demo in eight days, and the instability was unacceptable for that event.

Action： My approach was methodical: I started by analyzing the error logs to establish a pattern before touching any code. I noticed the errors correlated with specific database query patterns, which suggested a bottleneck rather than a code bug. I added granular logging to iterate through the call stack and isolate the problem. To be specific, I found that a particular ORM query was performing a full table scan on a 50-million-row table because a composite index was missing. I wrote a database migration, tested it in a replica environment to verify correctness, and deployed it with a feature flag so we could roll back instantly if anything went wrong. I also circled back to review the other five highest-traffic queries to check for the same issue — I found two more.

Result： The fix reduced the error rate from approximately 0.8% to near zero within 24 hours of deployment. The impact on p99 response time was a reduction from 1.4 seconds to 210 milliseconds. The customer demo proceeded without any issues. I subsequently wrote a documentation guide for the team on identifying and preventing this class of query performance issue, which we've used in three code reviews since.

働いている語彙に注目してください——constraint、approach、bottleneck、iterate、to be specific、circle back、impact。これらは飾りではありません。「この人は構造化されたプロのエンジニアの言葉で考えている」と面接官に伝えるシグナルです。

---

セクション3：システムデザイン面接の言語

システムデザイン面接には唯一の正解がありません。面接官が見ているのは「シニアエンジニアのように考えられるか」——曖昧さに構造を与え、トレードオフを推論し、決定を明確に伝えられるか。

以下の語彙パターンは、シニアレベルのエンジニア候補者が話す言葉です。スクリプトを暗記するためではなく、その背後にある思考パターンを内面化するために学んでください。

回答の構造化方法

システムデザイン面接の最初の2分が、その後の流れを決めます。強い候補者は一貫した構造を使います。

1. 要件をまず明確化する。 "Before I start designing, I want to clarify a few things. What's the expected scale? Are we optimizing for reads or writes? What's the acceptable latency for the critical path?"

2. アプローチを明示的に宣言する。 "My approach will be: define the data model, design the API, then talk through the main components and their interactions. I'll flag trade-offs as I go."

3. 意思決定に向かって進む。 "Given the constraints you've described, I'd lean toward a SQL database over NoSQL here, because the relational structure of the data is a better fit. That said, if write volume exceeds X, we'd want to revisit that decision."

シニア思考を示す10のシグナルフレーズ

これらのフレーズはアーキテクチャ的な成熟を示します。強い採用推薦を受ける候補者の回答に共通して登場します。

シグナルフレーズ	何を伝えるか
"The first question I'd ask is..."	設計の前に要件を集める
"The trade-off between X and Y is..."	競合する関心事を推論する
"A key consideration here is..."	何が重要かを優先づける
"I'd start simple and add complexity only when needed..."	早すぎる最適化を避ける
"This assumes [assumption] — if that changes, the design would change significantly..."	前提を明示的にする
"The bottleneck in this design is likely..."	障害点を予期する
"One failure mode we need to handle is..."	レジリエンスを考える
"If I were to scale this to 10x traffic..."	現状のスコープを失わずに先を考える
"I would monitor this with..."	運用と可観測性を考える
"The simplest thing that could work is... and here's when we'd outgrow it..."	システムの進化を理解している

非ネイティブによくあるミス

非ネイティブ英語話者の面接で頻出し、面接官から一貫してネガティブなフィードバックを引き出すパターンです。

ミス1：明確化せずに解法に飛びつく。

• 何が起きるか：要件が固まる前に特定の技術を語り始める。
• 面接官の見方：「明確化質問をしない。実務環境ではリスク。」
• 修正：「Before I propose a design, can I ask a few questions to make sure I understand the constraints?」

ミス2：決定せずに記述する。

• 何が起きるか：「We could use MySQL, or we could use Cassandra. Both have advantages. MySQL is relational. Cassandra is distributed.」
• 面接官の見方：「事実は並べられても、判断ができない。」
• 修正：「Given the read-heavy workload and structured data, I'd go with PostgreSQL. Here's why...」

ミス3：曖昧なポジティブ修飾を使う。

• 何が起きるか：「this is very efficient」「this approach is much better」のような発言。
• 面接官の見方：「何の指標で良いのか？どのくらい良いのか？」
• 修正：具体的にする。「This reduces time complexity from O(n²) to O(n log n), which matters at 10 million records.」可能な限り定量化する。

ミス4：母語の文構造をそのまま英訳する。

• 中国語例：「This problem, I think can be solved by using...」 → 「I think this problem can be solved by using...」
• 日本語例：技術文脈での*「I feel that...」*の多用 → 「My assessment is that...」または「The data suggests...」
• 韓国語例：英語で必須の主語を省略する

ミス5：考えるとき沈黙する。

• 何が起きるか：考え込んで黙ってしまい、面接官に「詰まったのか？」と思わせる。
• 修正：思考をナレーションする。「Let me think about this for a moment... I'm considering whether the consistency requirement here rules out an eventually consistent store...」これが「詰まっているように見える」と「思慮深く見える」の違いです。

---

セクション4：30日間プレ面接語彙スプリント

面接の4週間前から、この集中的な語彙スプリントを回してください。順番が大事です——アルゴリズム、システムデザイン、行動面接、統合の順。

第1週——カテゴリーA：アルゴリズム語彙

ゴール： コードを説明するときに自然に出てくるレベルまで、20語のアルゴリズム単語を自動化する。

毎日の練習（20分）：

• 1〜2日目：最初の10語を学習。Rhythm Wordに追加し、初回SRSセッションを完了。
• 3〜4日目：残り10語を学習。20語全部のSRSセッションを完了。
• 5日目：LeetCodeのEasyかMediumを完全に声に出して解く。カテゴリーAから最低5語を強制的に使う。
• 6日目：以前解いたLeetCodeの解法2問を、想像上の面接官に説明する。録音する。
• 7日目：Rhythm WordのSRSが弱いとフラグしたカテゴリーAの単語を集中復習。

第1週チェックポイント： マージソート、二分探索、ハッシュテーブルのルックアップの時間・空間計算量を、明快な英語で淀みなく説明できるか？

第2週——カテゴリーB：システムデザイン語彙

ゴール： 精密な語彙を使って、システムデザインの選択を提案・比較・正当化できる。

毎日の練習（25分）：

• 8〜9日目：最初の10語を学習。Rhythm Wordに追加。
• 10〜11日目：残り10語を学習。20語全部のSRSセッションを完了。
• 12日目：古典的なシステムデザイン問題を1つ（URL shortener、Twitter timeline、rate limiter）取り、自分の設計を15分話す。カテゴリーB単語を最低8つ強制的に使う。
• 13日目：システムデザインのブログ記事かアーキテクチャ記事を1本読み、文脈で出会ったカテゴリーB単語をすべてメモする。
• 14日目：Rhythm Wordでフラグされた単語を復習。声に出す設計演習を繰り返す。

第2週チェックポイント： Horizontal scalingとvertical scalingのトレードオフ、それぞれをいつ選ぶかを60秒以内で説明できるか？

第3週——カテゴリーC：行動面接語彙

ゴール： 行動面接の語彙を自然に使うSTAR回答を準備する。

毎日の練習（25分）：

• 15〜16日目：行動面接の20語を学習。Rhythm Wordに追加。
• 17日目：自分の経験から3つのSTARストーリーを書き出す。各ストーリーで行動語彙を最低3つ使う。
• 18日目：3つのストーリーを声に出して練習し、時間を計る。各回答は2〜3分。
• 19日目：Resultセクションに集中。各ストーリーの結果段落を書き直し、具体的な数字や測定可能な成果を入れる。
• 20日目：最頻出の行動質問5つに答える練習：
  • "Tell me about a time you had a conflict with a teammate."
  • "Describe a situation where you had to deliver under a tight deadline."
  • "Tell me about a time you made a significant technical decision."
  • "Give an example of a time you influenced a team without formal authority."
  • "Tell me about a time you failed."
• 21日目：Rhythm Wordでフラグされた行動単語を復習。

第3週チェックポイント： 3つの異なるSTARストーリーをそれぞれ3分以内、各ストーリーに最低1つの測定可能な結果を入れて話せるか？

第4週——模擬面接の統合

ゴール： すべての語彙を、現実的な面接プレッシャー下で組み合わせる。

• 22〜23日目：模擬コーディング面接を2回実施。終わるたびに、抜けたり避けたりした語彙を復習し、Rhythm Wordのレビューキューに追加。
• 24日目：模擬システムデザイン面接を1回実施（Pramp、interviewing.io、または友人を使う）。可能なら録画する。
• 25日目：録画を見直す（または練習相手にフィードバックをもらう）。どの語彙ギャップが現れたか？
• 26日目：22〜25日目にギャップとフラグした単語に絞ってRhythm Wordセッション。
• 27〜28日目：模擬面接2回。今度はカテゴリーDのコネクタフレーズ（elaborate、walk through、circle back、to your point、it depends on）を能動的に使う。自然に感じられるはず。
• 29日目：休む。新しい語彙はなし。
• 30日目：Rhythm Wordで最も弱い10語を軽く復習。自信を確かめるセッションだけ。

月末チェックポイント： 45分の模擬技術面接（コーディング、システムデザイン、行動面接）を、このガイドの語彙を使い、淀みなく曖昧な言葉に頼らずに完走できる。

---

FAQ

英語の技術面接にはどんな語彙が必要ですか？

4領域の語彙が必要です：(1)アルゴリズムとデータ構造——complexity、trade-off、edge case、recursion、bottleneckなど；(2)システムデザイン——architecture、scalability、fault tolerance、caching、consistency；(3)行動面接——ownership、accountability、impact、initiative、stakeholder；(4)プロフェッショナルなコネクタ——「walk me through」「to elaborate」「the trade-off between X and Y」「it depends on」など。多くの非ネイティブはカテゴリーごとに部分的にしかカバーできていません。このガイドは80語すべてを網羅します。

英語でアルゴリズムをどう説明すればいいですか？

この構造を使ってください：アルゴリズムを宣言、時間と空間の計算量を説明、なぜその問題に適切かを述べ、トレードオフがあれば付け加える。例："My approach uses a two-pointer technique. The time complexity is O(n) since we traverse the array once, and the space complexity is O(1) since we're not using any additional data structures. The trade-off is that this only works if the input is sorted — which, given the constraints, it is."

面接の「walk me through your approach」とはどういう意味ですか？

コードを書く前に、自分の思考プロセスを段階的に説明してください、という意味です。面接官は推論をナレーションする声を聞きたい——どう問題を分解しているか、どんなトレードオフを検討しているか、なぜあるデータ構造を別のものより選んだか。「すぐコーディングを始めろ」というシグナルではなく、「声に出して考えてください」という招待です。強い候補者はこう返します："Sure. Let me start by clarifying the constraints, then I'll outline my approach before writing any code."

英語の技術面接でもっと自信があるように聞こえるには？

3つの具体的なテクニック。第一に、構造的なフレーズを使って整理された思考を示す——「I'll break this into three parts」「the key considerations are X, Y, and Z」。これらは熟慮された印象を与えます。第二に、すべてを定量化する——「I reduced latency from 800ms to 90ms」は「I improved the performance significantly」よりも遥かに自信に満ちて聞こえます。第三に、前提を明示的にする——「I'm going to assume the input array is sorted; I'll note where that assumption matters」。明示的な前提は弱さではなく自覚のシグナルです。

STARメソッドとは何で、どんな語彙を使いますか？

STARはSituation、Task、Action、Result——行動面接質問に答えるためのフレームワークです。Situationの語彙："The context was"、"During my time at"、"We were in the middle of"。Taskの語彙："I was responsible for"、"I owned"、"My accountability was"。Actionの語彙："My approach was to"、"I escalated to"、"I drove the"、"I collaborated with"。Resultの語彙："The outcome was a [X]% improvement"、"As a direct result"、"The impact was"。重要な比率：Actionに50%、Resultに25%を使う。多くの候補者はこれをSituationに使ってしまい、面接官にはほとんど何も伝わりません。

---

まとめ

FAANGからオファーを得るエンジニアは、必ずしも最も難しいLeetCodeを解ける人ではありません。中程度の難易度の問題を明快に解き、思考を精密に伝え、「一緒に働きたい」と面接官に思わせる人です。

非ネイティブにとって、これは学習可能なスキルです。才能ではなく、運でもなく。このガイドのすべてのフレーズは、実際のエンジニアが実際の面接で使ってきたものです。語彙は有限。フレームワーク（STAR、システムデザインの構造化、声に出す推論）は学習可能です。

30日スプリントは1つの決断から始まります——今、最もコストになっている語彙ギャップはどれか？

技術面接を準備中のエンジニアにとって、Rhythm Wordはこのガイドの80語をどれでも追加し、必要なレジスター——プロフェッショナル、テクニカル、文脈豊かな——でパーソナライズされた例文と一緒に学習できます。アプリの間隔反復エンジンが、すでに知っている単語ではなく弱い単語を確実に復習させます。

自動化した単語の数だけ、面接室での「えっと」が減ります。

App StoreでRhythm Wordをダウンロード——無料

---

プロフェッショナル英語の語彙リソースをもっと見たい方へ：

• ビジネス英語の必須語彙——プロフェッショナルの完全ガイド
• 就職面接の英語——採用される60の単語とフレーズ
• 能動的リコール——語彙を最速で定着させる方法
• なぜコンテキスト例文が語彙学習で最も効率的なのか