英語での技術面接でコードを説明する方法

母国語ではない言語での技術面接は、独特の難しさがあります。単に問題を解決するだけでなく、問題解決のプロセスをリアルタイムで声に出して説明することが求められるからです。面接官はあなたがどのように考えるかを知りたがっており、そのためには明確で自信に満ちたコミュニケーションが不可欠です。

このガイドでは、コーディングのプロセスを説明するのに役立つ、体系的なアプローチと具体的な英語フレーズを紹介します。最初の問題の明確化から最終的な解決策のウォークスルーまで、技術スキルとコミュニケーションスキルを同時に示すのに役立つ全てをカバーします。

コーディングを始める前に：問題を明確にする

候補者が犯しがちな最も一般的な間違いの一つは、あまりにも早くコーディングを始めてしまうことです。一行でもコードを書く前に、問題、その入力、出力、そして制約を完全に理解していることを確認しなければなりません。これは、あなたが思慮深く、系統だった人物であることを面接官に示します。

まず、問題を自分の言葉で言い換えて、理解を確認することから始めましょう。

要求を明確にするためのフレーズ

• "So, just to make sure I understand correctly, the goal is to write a function that takes [input] and returns [output]?" （念のため正しく理解できているか確認したいのですが、[入力] を受け取って [出力] を返す関数を作成する、ということでよろしいでしょうか？）
• "To clarify, are we expecting the input array to contain only numbers, or can it have other data types?" （明確にしたいのですが、入力の配列には数値のみが含まれる想定でしょうか、それとも他のデータ型も含まれますか？）
• "Could you give me an example of a valid input and the expected output?" （有効な入力と期待される出力の例をいただけますか？）
• "When you say 'most frequent,' if there's a tie, which value should be returned?" （「最も頻度が高い」とのことですが、もし同率一位があった場合は、どちらの値を返すべきでしょうか？）

制約とエッジケースを議論するためのフレーズ

• "What are the constraints on the size of the input? For example, how large can the array be?" （入力サイズに関する制約はありますか？例えば、配列はどのくらい大きくなる可能性がありますか？）
• "How should the function handle invalid inputs, like a null or an empty list? Should it return an error, or a specific value?" （null や空のリストのような無効な入力はどのように処理すべきですか？エラーを返すべきか、特定の値を返すべきでしょうか？）
• "Are there any performance requirements I should be aware of, like time or space complexity?" （時間計算量や空間計算量など、考慮すべきパフォーマンス要件はありますか？）
• "I'm thinking about edge cases. For instance, what if the input list contains duplicates? Or what if all elements are the same?" （エッジケースについて考えています。例えば、入力リストに重複が含まれる場合や、すべての要素が同じ場合はどうでしょうか？）

このために少し時間を取ることは、間違った問題を解いてしまうのを防ぐだけでなく、面接官と対話しながら考えるための貴重な時間を与えてくれます。

「思考の言語化」メソッド：思考プロセスを実況する

面接官は、あなたの思考力を評価するためにコーディングチャレンジを用います。沈黙の中で完璧なソリューションを提示するよりも、明確に説明された良いソリューションの方が価値があります。問題から解決策に至るまでの道のりを説明する必要があるのです。

ステージ1：最初のアプローチ

まず、最初に思いついた最もシンプルなアイデアを説明することから始めましょう。これは多くの場合、「ブルートフォース（力任せ）」の解決策です。これにより、最適化を試みる前に、まずは機能する解決策を見つけられることを示せます。

• "My first thought is to approach this with a nested loop. I can iterate through each element and then compare it with every other element." （まず考えたのは、ネストしたループでアプローチすることです。各要素をループで処理し、他のすべての要素と比較します。）
• "A straightforward way to solve this would be to sort the array first. That would simplify finding the duplicates." （この問題を解決する簡単な方法は、最初に配列をソートすることです。そうすれば重複を見つけるのが簡単になります。）
• "Initially, I'm thinking of a brute-force approach. It might not be the most efficient, but it would work. From there, we can look for optimizations." （最初は、ブルートフォースのアプローチを考えています。最も効率的ではないかもしれませんが、機能はするはずです。そこから最適化を探っていけます。）

ステージ2：分析と改良

最初のアイデアを述べた後、そのトレードオフ、特に時間計算量と空間計算量を分析します。これは、アルゴリズムとデータ構造に関する深い理解を示します。

• "The time complexity of this nested loop approach would be O(n²), which might be too slow if the input is very large." （このネストしたループのアプローチの時間計算量はO(n²)になり、入力が非常に大きい場合は遅すぎるかもしれません。）
• "This solution has a space complexity of O(n) because I'm creating a new data structure to store the results." （このソリューションの空間計算量はO(n)です。結果を保存するために新しいデータ構造を作成しているためです。）
• "We could optimize this. If we use a hash map, we can reduce the time complexity to O(n) by trading off some space." （これは最適化できます。ハッシュマップを使えば、多少のスペースを犠牲にすることで時間計算量をO(n)に削減できます。）
• "I think we can do better. Let me consider an alternative approach using a two-pointer technique." （もっと良い方法があると思います。2ポインターテクニックを使った別のアプローチを検討させてください。）

ステージ3：コードの構成を考える

猛烈な勢いでタイピングを始める前に、計画の概要を説明しましょう。使用する予定の関数、変数、ロジックを説明します。これは、あなたと面接官の両方にとってのロードマップとして機能します。

• "Okay, my plan is to first initialize an empty dictionary to store character counts." （では、私の計画は、まず文字の出現回数を保存するための空の辞書を初期化することです。）
• "I'll write a main function that takes the array as an argument. Inside it, I'll have a loop to iterate through the elements." （配列を引数として受け取るメイン関数を書きます。その中で、要素を反復処理するためのループを設けます。）
• "I think I'll need a helper function to handle the logic for reversing this part of the string. It will make the main function cleaner." （文字列のこの部分を逆にするロジックを処理するために、ヘルパー関数が必要になると思います。その方がメイン関数がクリーンになります。）
• "I'll start by handling the edge cases we discussed, like an empty input array." （まず、先ほど話した空の入力配列のようなエッジケースの処理から始めます。）

コーディング中：対話を続ける

コードを書きながら、何をしているのか、そしてなぜそうするのかを説明し続けましょう。ただコードを読み上げるのではなく、各ロジックブロックの目的を説明してください。

• "Now, I'm creating a for loop that will go from the beginning of the array to the end." （今、配列の最初から最後までを処理する for ループを作成しています。）
• "This variable, max_so_far, will keep track of the largest value we've seen." （この max_so_far という変数は、これまでに見つかった最大値を記録するためのものです。）
• "Inside the loop, this if statement checks if we've encountered this element before. If we have, I'll increment its count in the map." （ループの中のこの if 文は、この要素に以前遭遇したかどうかをチェックします。もし遭遇していれば、マップ内のカウントをインクリメントします。）
• "I'm using a while loop here because the number of iterations isn't fixed; it depends on the values of these two pointers." （ここでは while ループを使っています。なぜなら、反復回数が固定ではなく、これら2つのポインターの値に依存するからです。）

もし行き詰まったら？沈黙は禁物です。考える時間が必要になるのはごく普通のことです。ただ、そのことを伝えましょう。

• "Let me take a moment to think about the best way to structure this next part." （次の部分をどう構成するのがベストか、少し考えさせてください。）
• "I'm just double-checking my logic for this condition. One second." （この条件のロジックを再確認しています。少々お待ちください。）
• "Hmm, I think there might be a small issue here. Let me trace the execution with an example input to find it." （うーん、ここに少し問題があるかもしれません。例となる入力で実行をトレースして見つけてみます。）

ロジックに集中していて適切な英単語が出てこないと、ストレスを感じるかもしれません。そんな時、プロフェッショナルな言い回しを提案してくれるアシスタントが役立ちます。例えば、SubtlのAIプロンプターは、「Let me think through the logic for this edge case」（このエッジケースのロジックを考えさせてください）のようなフレーズをリアルタイムで作成し、集中力を途切れさせることなくスムーズな会話を維持するのに役立ちます。

ヒントやフィードバックへの対応

面接官がヒントをくれたとしても、それは失敗のしるしではありません。共同作業への招待状です。フィードバックをどのように受け入れ、取り入れるかは、彼らが試している重要なスキルです。注意深く耳を傾け、ヒントを認め、それをどのように活用するかを説明しましょう。

ヒントを認めるためのフレーズ

• "That's a great point. Using a set here would indeed make the lookup much faster. I'll change my approach." （それは素晴らしい指摘です。確かにここでセットを使えば、検索がずっと速くなりますね。アプローチを変更します。）
• "Thank you, that clarifies it. I see now that I was overcomplicating the base case for the recursion." （ありがとうございます、それで明確になりました。再帰のベースケースを複雑にしすぎていたことが分かりました。）
• "Ah, I didn't consider that edge case. You're right. I need to add a check for that before the loop starts." （ああ、そのエッジケースは考慮していませんでした。おっしゃる通りです。ループが始まる前にそのチェックを追加する必要があります。）

本当に行き詰まってしまった場合は、黙っているよりも助けを求める方が良いです。それは自己認識と助けを求める意欲を示します。

• "I'm a bit stuck on optimizing the space complexity here. Could I perhaps get a small hint?" （空間計算量の最適化で少し行き詰まっています。少しヒントをいただくことは可能でしょうか？）
• "I'm considering two data structures for this part, a dictionary or a simple list. I'm leaning towards the dictionary for performance, but I'm not sure. Do you have any thoughts on that?" （この部分には辞書か単純なリストの2つのデータ構造を検討しています。パフォーマンスの観点から辞書に傾いていますが、確信がありません。何かご意見はありますか？）

コーディング後：テストと説明

ソリューションを書き終えたら、ただ「終わりました」と言うだけではいけません。面接はまだ終わっていません。コードを検証し、そのパフォーマンスについて議論する必要があります。

1. 例を使ってテストする： サンプル入力を使って、手動でコードをウォークスルーします。これにより、バグを発見し、自分が書いたものを理解していることを証明できます。

   • "Let's test this with the example input [3, 1, 4, 1, 5]." （では、このコードを [3, 1, 4, 1, 5] というサンプル入力でテストしてみましょう。）
   • "First, the map is empty. In the first iteration, we add 3 with a count of 1. In the second, we add 1 with a count of 1. In the fourth iteration, we see 1 again, so we increment its count to 2." （まず、マップは空です。最初のイテレーションで、3 をカウント 1 で追加します。2回目では 1 をカウント 1 で追加します。4回目のイテレーションで再び 1 が現れるので、そのカウントを 2 にインクリメントします。）

2. 計算量を再度議論する： 最終的なソリューションの時間計算量と空間計算量を再度述べます。

   • "The final time complexity is O(n) because we iterate through the list once. The space complexity is O(k), where k is the number of unique elements, because of the hash map." （最終的な時間計算量は、リストを一度だけ反復処理するためO(n)です。空間計算量は、ハッシュマップを使用しているため、ユニークな要素の数をkとしてO(k)となります。）

3. 改善点について話す： もっと時間があればコードをどのように改善できるかについて、簡潔に言及します。

   • "If this were production code, I would add more robust error handling for different input types." （もしこれが本番用のコードであれば、さまざまな入力タイプに対応するため、より堅牢なエラーハンドリングを追加します。）
   • "Another possible optimization, if memory were a major concern, might be to modify the input array in-place, although that has its own trade-offs." （もしメモリが大きな懸念事項であれば、別の最適化として入力配列をインプレースで（元の配列を直接）変更する方法も考えられますが、それには別のトレードオフがあります。）

避けるべきよくある間違い

• 沈黙の中で作業する。 これが最大の間違いです。面接官はあなたの心を読むことはできません。思考プロセスを過剰なくらい伝えましょう。
• すぐにコーディングを始める。 必ず最初に問題を明確にし、アプローチについて議論しましょう。
• ヒントを無視したり、反論したりする。 面接官を協力者と見なしましょう。彼らのフィードバックを素直に取り入れましょう。
• 行き詰まったときに諦める。 立ち止まるのは問題ありませんが、考えていることを伝えましょう。声に出して自分のコードをデバッグしてみてください。
• エッジケースを忘れる。 空の入力、null、重複、その他の非標準的なシナリオを常に考慮しましょう。

同意とツールに関する注意点

通話中にライブ文字起こしやアシスタントツールを使用する予定がある場合は、その旨を透明性をもって伝えなければなりません。多くの法域では、文字起こしや録音をされることについて、すべての当事者の同意が必要です。そのようなツールを使用する場合は、必ず通話の最初に面接官に知らせてください。詳細については、通話録音法に関する一般的なガイダンスを確認できます。私たちのガイド /law/ をご覧ください。

英語で自分のコードを声に出して説明することは、練習によって身につけられるスキルです。コミュニケーションを体系化し、明確なフレーズを使い、面接を共同作業のセッションとして捉えることで、たとえ英語が母国語でなくても、あなたの技術力を効果的に示すことができます。

重要な面接に備えるには、リアルタイムのフィードバックや翻訳を提供するツールで練習することが自信につながります。Subtl for Macは、会話のライブトランスクリプトを提供するため、話された内容を確認でき、明確でプロフェッショナルな応答を作成するのに役立ちます。/use-cases/interviews/ での活用法について詳しく学びましょう。