コーディング・実装力で聞かれる8の質問と答え方、対策を解説【技術面接 集中講座 #4】

• 1. 本記事で扱う2つの面接形式

• 2. 【Part A】自分のコードを語る6の質問

• 3. 【Part B】その場で書く2の質問

• 4. コーディング・実装の質問で評価される人の3つの特徴

• 5. 日々の実装で意識すべき4つの習慣

• 6. まとめ

1. 本記事で扱う2つの面接形式

今回扱う面接形式は、「コードレビュー型」と「コーディングテスト型」の大きく2つに分かれます。

Part A：コードレビュー型

ポートフォリオや事前のコーディングテストなどで自分が書いたコードを、面接官に深掘りされる形式です。GitHubを画面共有しながら、あるいはコードを事前に読んだ上で質問されます。

Part B：コーディングテスト型

面接官がいる場で問題を解く形式です。ライブコーディングやホワイトボードコーディングが課されます。

実際の面接では、Part Aの自分のコードを語る形式が大半を占めます。Part Bのその場でコードを書く形式は、企業によって有無が分かれるのが実情です。そのため本章も、Part Aを6問、Part Bを2問という比重で扱います。

2. 【Part A】自分のコードを語る6の質問

このパートは、面接官があなたのコードを読み解きながら深掘りしてくる場面に対応します。各質問について、「よくあるNGな回答例」「面接官が見ているポイント」「回答の型」の3つに分けて解説します。

▼クリックすると各質問の解説にとべます

質問1｜このコード、なぜこう書いたのか説明してください

質問2｜この関数、もっとシンプルに書けますか（リファクタリング）

質問3｜このループの計算量はどのくらいですか（O記法）

質問4｜このコードのエッジケースは何が想定されますか

質問5｜このコードに問題があるとしたら、どこですか

質問6｜N+1問題やパフォーマンス問題は、どう発見・解決しましたか

質問1｜このコード、なぜこう書いたのか説明してください

■ よくあるNGな回答例

「えーと、ここはユーザー情報を取得して…」と、コードの読み上げになってしまいます。「Reactのドキュメントを参考にしました」と、外部の権威に逃げてしまうこともあるでしょう。「動いたので、これで良いと思って」と結果論で答えるケースもあります。いずれも、「なぜこう書いたか」の判断軸を、自分の言葉で持てていません。

■ 面接官が見ているポイント

見られているのは、「コードの一行一行を、自分の判断として説明できるか」です。コピペや参照元の模倣でも構いません。その上で「なぜこの書き方を選んだか」を理解しているかが分かれ目です。

■ 回答の型

「この箇所の意図→なぜこの書き方を選んだか→他の書き方の選択肢→トレードオフ」の流れで回答しましょう。選んだ書き方と捨てた書き方をセットで語ります。

▼回答のイメージ

「ここは非同期処理を逐次実行している。Promise.allでの並列実行も考えたが、APIに同時呼び出し制限があったので逐次にした。完全な逐次か全並列かの二択ではなく、同時実行数を絞った並列（並行度制御）やレートリミッターで制御する手もある」

質問2｜この関数、もっとシンプルに書けますか（リファクタリング）

■ よくあるNGな回答例

「うーん、特に思いつきません…」と沈黙してしまうか、「コメントを足します」「変数名を分かりやすくします」と、表層的な改善を答えてしまいます。「これで完璧だと思います」と答えてしまうと、自信過剰と受け取られてしまうでしょう。「コードに改善余地はある」という前提が抜けていて、リファクタリングの提案ができていません。

■ 面接官が見ているポイント

見られているのは、「自分のコードを批判的に見られるか」です。実務では動くコードを書く力と同じくらい、動くコードを読み返して改善する力が求められます。リファクタリングの引き出しが多い学生は、コードレビュー文化になじみやすく、チーム開発で活躍します。

■ 回答の型

「現状の課題（可読性／重複／責任の混在など）→改善案→改善後のメリット→トレードオフ」の流れで語れるようにしましょう。改善後のデメリットまで語れると、一段上の評価になります。

▼回答のイメージ

「現状は、ロジックとUI描画が一つの関数に混在している。副作用のない純粋なロジックは通常の関数へ切り出すと、テストが容易になる。React状態に絡む部分はカスタムフックに分離する。ただし関数が分かれるぶん、初見の人には流れが追いにくくなるトレードオフがある」

質問3｜このループの計算量はどのくらいですか（O記法）

■ よくあるNGな回答例

「O(n)です」とパッと答えても、「この中で配列を毎回検索しているのは何ですか」と掘られると詰まります。実際は、内側で配列を毎回線形検索しているため、全体ではO(n²)です。「計算量って何ですか」と、そもそも知識がないことが露呈することもあります。メモリ使用量を聞かれて答えられないケースもあります。計算量の概念は知っていても、自分のコードに当てはめて答えられていません。

■ 面接官が見ているポイント

見られているのは、「自分の書いたコードの性能特性を理解しているか」です。計算量はパフォーマンスの基礎で、これを理解せずに書いていると、データ量が増えたときに破綻します。実務を行うエンジニアにとって、計算量を意識するのは常識のレベルです。

■ 回答の型

「ループの構造→各操作の計算量→全体の計算量→改善案（あれば）」の流れで伝えましょう。改善案までセットで語れると、評価につながります。

▼回答のイメージ

「外側のループはn回まわり、内側で配列を線形検索しているのでO(n)。掛け合わせて、全体ではO(n²)になる。データ量が増えると問題になるので、Mapに変換して平均O(1)で参照すれば、O(n)に改善できる」

質問4｜このコードのエッジケースは何が想定されますか

■ よくあるNGな回答例

「nullが入ってくる場合とか…」と、漠然と答えてしまいます。「想定通りに動けば問題ないです」と、ハッピーパスしか考えていないことが露呈することもあります。「配列が空のとき」「負の数」「極端に大きな数値」など、定型的なエッジケースの引き出しが少ないのです。動くコードは書けても、想定外の入力への耐性を語れていません。

■ 面接官が見ているポイント

見られているのは、「コードを書く時点で、エッジケースを想定できているか」です。実務のバグの大半は、想定外の入力から生まれます。エッジケースを意識する習慣は、コードの堅牢性に直結します。学生のうちに身についていないと、実務で大量のバグを生みかねません。

■ 回答の型

「入力の境界（空・null・最大・最小・型違い）→状態の境界（初期化前・並行アクセス・タイムアウト）→自分のコードでの想定」の流れで回答しましょう。入力と状態の両方を語ります。

▼回答のイメージ

「ユーザー入力を受け取る箇所では、空文字・極端に長い文字列・不正な文字列を想定した。型はTypeScriptで担保しつつ、ランタイムでもZodでバリデーションしている。状態としては、ネットワーク断時のリトライ処理が未実装で、今後の改善ポイントだ」

なお、SQLインジェクションのような攻撃への本筋の対策は、パラメータ化クエリです。入力バリデーションはあくまで補助、と理解しておきましょう。

質問5｜このコードに問題があるとしたら、どこですか

質問2は「より良くできるか（改善余地）」を、質問4は「壊れる条件（網羅性）」を問う質問でした。それに対して質問5は、「今この設計に潜むリスク（バグ・保守性・セキュリティ）」を問う、より広い視点の質問です。

■ よくあるNGな回答例

「特に問題はないと思います」と、問題なしで答えてしまいます。これは避けたい回答パターンです。また、「コードが汚いです」「コメントが少ないです」と、表層的な答えに終始することもあります。自分のコードを批判的に見て、潜在的なリスクを語ることができていません。

■ 面接官が見ているポイント

見られているのは、「自分のコードのリスクを客観視できるか」です。「完璧なコードは存在しない」という前提に立ち、健全な懐疑心を持つことが、実務においてコードの品質を支えます。「問題ない」と答える学生は、レビューでも自分のコードを擁護しがちで、チームで働きにくいと見られかねません。

■ 回答の型

「機能面の問題（バグ・エッジケース）／非機能面の問題（パフォーマンス・セキュリティ）／保守面の問題（可読性・テスタビリティ）」の3軸で語りましょう。

▼回答のイメージ

「機能面では、エラー時のリトライ処理がなく、ネットワークが不安定なときに失敗する。非機能面では、重い処理をリクエスト内で同期実行していて、ブロッキングI/Oを直列で待っている。そのため、データ量が増えるとレスポンスが遅くなる。保守面では、ロジックが密結合で、新機能を追加するときの影響範囲が広い」

質問6｜N+1問題やパフォーマンス問題は、どう発見・解決しましたか

第3章では「そもそも遅くならない設計」を扱いました。ここで問われるのは、すでに書かれたコードから、ボトルネックを見つけ直す力です。

■ よくあるNGな回答例

「N+1問題は気にしていました」と、知識レベルで答えてしまいます。「ORMでEager Loadingを使えば解決します」と、一般論で済ませてしまう人もいるでしょう。多くは、「N+1という言葉は知っているが、自分のコードのどこで起きていたかは説明できない」状態にとどまります。知識は語れても、自分のコードでの発見と解決を、経験として語れていません。

■ 面接官が見ているポイント

見られているのは、「パフォーマンス問題への感度を、コードレベルで持っているか」です。設計の話ではなく、コードレベルでどう発見し、どう直したかの具体性が問われます。とはいえ、学生のポートフォリオ規模では、N+1があっても遅延として体感できないことのほうが普通です。だからこそ、「将来データ量が増えたときに問題になりうる箇所を、自分のコードの中で意図的に見つけ、先回りで対処した経験」を語れる学生は強いといえます。

■ 回答の型

「コード中の発生箇所（どの処理・どのクエリか）→発見の方法（ログ確認・コードレビューでの気づき）→修正したコード→効果の見立て」の流れで回答します。

実測の数字があれば添えてもよいですが、無理に作る必要はありません。「データ量が少ないうちから、将来を見越して対処できた」というスタンスのほうが、ポートフォリオ規模では誠実で、評価につながります。

▼回答のイメージ

「ダッシュボードで投稿一覧を取得する処理で、各投稿に紐づくユーザー情報を別々に取得していた。Rails consoleでクエリログを確認したところ、典型的なN+1になっていた。現状のデータ量では体感の遅延はなかったが、includesを追加し（Railsは状況に応じ、関連を別クエリでまとめるpreload＝親1＋子1の計2回か、JOINでまとめるeager_load＝1回を選ぶ）、クエリ本数をN+1回から数回に減らした。投稿数が膨大になったときに、表示が大幅に遅くなるリスクを潰せたと考えている」

3. 【Part B】その場で書く2の質問

Part Bの2問は、正解を答える質問ではありません。解く過程を見せる質問です。以降の「よくあるNGな回答例」「面接官が見ているポイント」「回答の型」も、答えの中身より、進め方や実況のやり方を意識して読んでください。

▼クリックすると各質問の解説にとべます

質問7｜【ライブコーディング】この問題を解いてみてください

質問8｜【ホワイトボード】○○という機能を追加するなら、どう実装しますか

質問7｜【ライブコーディング】この問題を解いてみてください

■ よくあるNGな回答例

無言で考え込み、いきなりコードを書き始めてしまいます。詰まると沈黙が続き、「分かりません」と早々に諦めることもあるでしょう。焦っていきなり最適化に走り、ブルートフォース解も書けずに時間切れになることもあります。思考のプロセスを声に出さないことが、最も多い失敗です。

■ 面接官が見ているポイント

見られているのは、「完答できるか」ではなく、「どう考え、どう動いたか」です。実務でも、正解が分からない問題に向き合うのが日常です。そのときに、思考プロセスを言語化できるかが重要になります。「実況中継スタイル」が有効なのは、思考が見えれば、完答できなくても評価されるからです。

■ 回答の型

「問題の理解確認→入出力例の確認→方針宣言（ブルートフォース→最適化）→実装の声出し→デバッグの思考共有」の流れで対応しましょう。次のように声を出して話しながら進めます。

▼回答のイメージ

「○○という入力に対して△△を返せばいい、という理解で合っていますか」「まずブルートフォースで書いて、その後に最適化します」「ここでnullが入るかもしれないので、まず入力値を確認します」

沈黙しないことが、最も大切です。完答よりも、思考プロセスを示すことを優先しましょう。

質問8｜【ホワイトボード】○○という機能を追加するなら、どう実装しますか

■ よくあるNGな回答例

いきなりコードを書き始めて、設計が不足してしまいます。「うーん、複雑ですね…」と、全体像を整理できないまま手が止まってしまうこともあるでしょう。設計の順序立てが身についていないと、何から考えればいいか分からなくなります。個別の実装はできても、ゼロから設計を組み立てる思考の手順を見せられていません。

■ 面接官が見ているポイント

見られているのは、「即興で設計を組み立てる思考の順序」です。ライブコーディングはアルゴリズム実装寄り、ホワイトボードは設計・モデリング寄りの問いが出やすい傾向があります。ただし、媒体と出題種別は本来べつの軸です。設計を深く問う形式は「システムデザイン面接」と呼ばれます。要件確認・データモデリング・API設計・実装方針までを、限られた時間で組み立てられるかが分かれ目です。

■ 回答の型

「要件の確認→エンティティの抽出→データモデル→APIまたは関数のインターフェース→実装の核心部分」の流れで進めましょう。次のように声を出します。

▼回答のイメージ

「この機能のユーザーは誰で、何ができればゴールか確認させてください」「必要なデータは○○と××です」「APIは△△のような形にします」「実装の核心はここで、流れは…」

すべてを書ききる必要はありません。設計の骨格を示し、最も重要な部分を実装しましょう。

4. コーディング・実装の質問で評価される人の3つの特徴

ここからは、評価される人とされない人の違いを、3つの軸で整理します。

特徴1：自分のコードを客観的な視点で読める

評価される人は、「ここはこう書いたが、振り返るとリファクタリングしたい部分です」と、距離を持って語れます。

評価されない人は、「動いたのでこれで良いと思いました」「ベストだと思います」と、自分のコードを擁護します。

自分のコードに健全な懐疑心を持てるかが、コードレビュー文化への適応性を示します。

特徴2：「動く」と「良い」の違いを語れる

評価される人は、「これで動くが、可読性は犠牲にしている」「これで動くが、テスタビリティは低い」と、「動く」の先を語れます。

評価されない人は、「動けば良い」「テストは通っています」と、「動く」で満足してしまいます。

実装力は、「動かす力」ではなく「良いコードに育てる力」だと理解しているかが問われます。

特徴3：手を動かしながら思考を共有できる

評価される人は、ライブコーディングやホワイトボードで「実況中継スタイル」が自然にできます。沈黙が少なく、思考のプロセスが見えます。

評価されない人は、無言で考え込み、答えが出ないまま時間が過ぎます。完答できないと、早々に諦めてしまいます。

「正解にたどり着けなくても、思考プロセスが見えれば評価される」という原則を理解しているかが分かれ目です。

5. 日々の実装で意識すべき4つの習慣

前述の3つの特徴は、一朝一夕では身につきません。ここでは、技術面接で評価されるために日常で身に付けておきたい4つの習慣を紹介します。

習慣1：自分のコードに「リファクタリングメモ」を残す

コードを書いた直後に、「ここは後で直したい」「ここは選択肢を絞り切れなかった」というメモを残します。面接で語れるリファクタリング候補が、自然と蓄積されていきます。

習慣2：書いたコードを翌日以降に読み返す

書いた直後は良いコードに見えても、時間を置いて読み返すと粗が見えます。「自分のコードを他人のコードとして読む」訓練を、コードを書くたびに行いましょう。

習慣3：計算量を毎回書く（コメントでも頭の中でも）

ループや再帰を書くときは、計算量を必ず意識します。最初は紙に書いてもかまいません。慣れてくると、書いた瞬間にO記法で答えられるようになります。

習慣4：ライブコーディングの「実況中継」を一人で練習する

たとえばLeetCodeのEasy問題を、声に出して解いてみましょう。スマホで録画してみるのもおすすめです。「考えていることを言葉にする」訓練は、一人でできる最大の準備です。週に2〜3問やれば、面接でも自然に声が出るようになります。Easyで実況の型を作ったら、その後はMedium中心に移行すると、実態に近い練習になります。

6. まとめ

コーディングや実装力に関する質問は、丸暗記だけでは突破できない、日々の実装習慣が表れる問いです。自分のコードを「他人のコード」として批判的に読めるかが、最大の分かれ目です。また、ライブコーディングでは「実況中継スタイル」で思考を見せることが評価につながります。

日々の開発の中でリファクタリングメモを残すことや、計算量を意識すること、後日読み返すクセを習慣づけておきましょう。一夜漬けの対策が効かないからこそ、普段の習慣と思考プロセスが、そのまま強みになります。