IT・Web業界の技術面接、コーディングテストで落ちる人に共通する準備不足

画面共有ソフトを開いたまま、20分近く無言でコードを書き続けてしまった——そんな経験がある人は、決して少数派ではありません。

IT・Web業界を中心に800名以上の転職支援に携わってきましたが、ウィルオブ・ワークが転職経験のあるITエンジニア522名を対象に行った調査では、コーディングテストを「難しい」と感じた人が73.8%にのぼる一方、事前対策を希望する人は84.0%にも達しています。今回は、「対策したいのに、何をすればいいか分からない」という声に応える形で、実際に不合格となった候補者の準備不足のパターンを、企業から届いたフィードバックとともにお伝えします。

目次

1. 技術面接・コーディングテストで落ちる人に共通する準備不足とは
2. パターン①、声に出さず黙々と書き進めてしまう（ライブコーディング形式）
3. パターン②、完璧主義で時間切れになる（オンラインジャッジ形式）
4. パターン③、制約条件とテストケースの読み方でつまずく（オンラインジャッジ形式）
5. パターン④、フィードバックを取り入れられない（ペアプログラミング形式）
6. ライブコーディング・オンラインジャッジ・ペアプロ、形式で変わる準備の中身
7. 面接官は実際どこで不合格判定を出しているか
8. 今日からできる、形式別の準備チェックリスト
9. ライブコーディング形式の準備
10. オンラインジャッジ形式の準備
11. ペアプログラミング形式の準備
12. まとめ、コーディングテスト対策は「解ける」だけでは終わらない

技術面接・コーディングテストで落ちる人に共通する準備不足とは

転職エージェントとして候補者の相談に乗っていると、「コーディングテストの対策って、結局何をすればいいんですか」と聞かれる場面によく出会います。ウィルオブ・ワークが2024年6月に転職経験のあるITエンジニア522名を対象に行った調査では、コーディングテストを受けたことがある人のうち「難しい」と感じた人は73.8%（かなり難しい24.1%、やや難しい49.7%）にのぼり、事前対策を希望する人は84.0%に達しています（ウィルオブ・ワーク「ITエンジニアの転職コーディングテストに関する調査」）。

対策したい気持ちは強いのに、何をすればいいか分からないまま本番を迎えている人が、想像以上に多いという実感があります。

同じ調査では、コーディングテストを受けた経験がある人は全体で38.1%ですが、20代に絞ると53.1%まで上がります。若手層ほどこの形式の選考に直面しやすいということです。さらに、選考結果のフィードバックを希望する人は66.5%にのぼりますが、実際に企業側から不合格の具体的な理由まで開示されるケースは多くありません。

「不合格でした」という結果だけが伝えられ、何がまずかったのか分からないまま次の選考に臨む人を、私はこれまでたくさん見てきました。エージェント経由の応募であれば、企業からのフィードバックをこちらで受け取り、可能な範囲で共有できることもあるので、選考後に「差し支えなければ理由を伺えますか」と一言添えて聞いてみる価値はあります。

私自身はコーディングテストの採点をする立場ではありません。ただIT・Web業界を担当するキャリアアドバイザーとして、候補者から選考の様子を聞き、企業の採用担当者から不合格の理由をフィードバックとして受け取る機会が日常的にあります。7年間で800名以上を支援してきた中で見えてきたのは、落ちる人の多くが「アルゴリズムを知らなかった」のではなく、本番形式に合わせた準備をしていなかったという点です。

技術面接やコーディングテストには、ライブコーディング、オンラインジャッジ、ペアプログラミングという主に3つの形式があり、それぞれ評価されるポイントも、陥りやすい準備不足のパターンも違います。ここからは、実際に不合格となった候補者の実例をもとに、形式別の準備不足のパターンを見ていきます。

パターン①、声に出さず黙々と書き進めてしまう（ライブコーディング形式）

ライブコーディングは、面接官の前で画面を共有しながら、その場でコードを書いて見せる形式です。多くの企業が一次〜二次面接に組み込んでおり、コードの正確さだけでなく、書きながら何を考えているかを言葉にできるかが見られています。

以前担当したAさん（20代後半・SIerでインフラ運用を担当、Web系自社開発企業への転職を希望）は、個人開発の経験も豊富で、書けるコードの水準自体は高い方でした。ところが面接本番、配列操作の問題を渡されると、画面共有のまま20分近くほぼ無言でコードを書き続けてしまいました。途中で面接官が「今どのあたりを考えていますか」と声をかけても、「もう少しで書き終わります」と返すだけで、思考の途中経過を説明する場面はほとんどありませんでした。

面接後、企業の採用担当者から届いたフィードバックは、「コードは動くものが書けていたが、途中の思考が見えず、チームで一緒に開発できるイメージが持てなかった」というものでした。Aさん本人は、静かに集中して解くタイプの方でした。ただ面接官の立場からすると、無言で20分待たされる時間は、候補者が詰まっているのか順調なのか判断できず、不安になる時間でしかありません。

私がその後Aさんに勧めたのは、模擬面接で「今、〇〇のアプローチを試そうとしています」「この書き方だと計算量が多くなりそうなので、別の方法を考えます」というように、考えていることを一言ずつ声に出す練習でした。次に受けた企業のライブコーディングでは、同じくらいの難易度の問題に対し、都度言葉にしながら進めたところ、「思考のプロセスが分かりやすかった」という評価をもらい、選考を通過しています。

パターン②、完璧主義で時間切れになる（オンラインジャッジ形式）

オンラインジャッジ形式は、HackerRankやpaiza、LeetCodeのようなプラットフォーム上で、制限時間内に複数問を解く形式です。ライブコーディングと違って面接官がリアルタイムで見ているわけではなく、提出したコードとテストケースの通過率だけで評価されるのが特徴です。

同じくオンラインジャッジ形式でつまずいたのが、Bさん（30代前半・SES企業でバックエンドエンジニア、実務6年）です。業務でのコーディング経験は十分にありましたが、オンラインジャッジ形式のテストは今回が初めてでした。60分で3問という設定で、1問目に手をつけた際、業務での癖がそのまま出て、変数名を丁寧に付け、例外処理まで作り込んだ完成度の高いコードを書こうとしました。結果、1問目だけで25分近くを使い切り、2問目は途中まで、3問目はほぼ手つかずのまま時間切れになりました。

後日聞いた採用担当者の話では、「1問目のコードの質は高かったが、3問中1問しか解けていない。実務では期限内に一定の質で終わらせる判断力も見ている」とのことでした。Bさんの実力自体は決して低くありませんでした。問題は、業務と同じ完成度をテストの場に持ち込んでしまったことです。

オンラインジャッジ形式では、まず動くコードを最短で書き、テストケースを通してから余裕があれば整えるという優先順位が求められます。私が候補者に伝えているのは、「1問あたりにかけていい時間を、開始前に電卓で割り算しておく」というシンプルな方法です。Bさんも次の選考では、60分3問なら1問18分を上限と決めて臨み、3問とも部分点以上を確保して通過しました。

パターン③、制約条件とテストケースの読み方でつまずく（オンラインジャッジ形式）

オンラインジャッジ形式には、もう一つ独特のつまずきどころがあります。それが、問題文に書かれた制約条件を正しく読み取れるかどうかです。

相談に来ていたCさん（20代後半・異業種からエンジニアに転向して2年目）は、業務でのコーディング経験こそ浅いものの、独学でアルゴリズムの勉強を続けていた方でした。ところが本番のテストで、配列のサイズが「最大10万件」と制約条件に明記されていた問題に対し、二重ループを使う計算量の大きい書き方をしてしまい、テストケースの後半で軒並みTLE（制限時間超過）の判定を受けました。テストケースが何個通ったかがリアルタイムで表示される形式に慣れておらず、赤い×マークが増えていく画面を見て焦り、残り時間のほとんどを見直しに使えないまま終わってしまったそうです。

ポイント： オンラインジャッジ形式では、問題文の下部や末尾に小さく書かれている制約条件（データ数の上限、値の範囲など）が、使うべきアルゴリズムを決める重要な手がかりになります。「10万件」とあれば計算量がO(n²)の書き方は基本的に間に合わず、O(n log n)以下の発想が必要になる、というように、制約条件から逆算して解法を選ぶ練習が欠かせません。

Cさんの場合、アルゴリズムの知識自体は不足していませんでした。足りなかったのは、制約条件を読んでから解法を選ぶという順番と、テストケースが可視化される形式への慣れです。次の選考の前に、同じプラットフォームで似た形式の問題を10問ほど時間を計って解く練習をしてもらったところ、本番でも制約条件を先に確認してから書き始める習慣がつき、無事に通過しています。

パターン④、フィードバックを取り入れられない（ペアプログラミング形式）

ペアプログラミング形式は、面接官と一緒にコードを書きながら進める形式で、途中で面接官から指摘やヒントが入ることが前提になっています。ここで見られているのは、コードの正確さ以上に、指摘を受けたときの反応です。

ペアプログラミング形式でつまずいたのが、Dさん（30代前半・自社開発企業のフロントエンドエンジニア）です。個人での開発力には自信を持っていました。ペアプロの面接中、書いていたコードに対して面接官から「この処理、別の関数に切り出した方が読みやすくなりそうですね」と指摘を受けた際、Dさんは「今のままでも動くので大丈夫です」と返し、そのまま自分のやり方を貫きました。

後日届いたフィードバックには、「技術力に問題はないが、指摘に対してやや頑なな印象を受けた。チームで開発する上で、他者の意見を取り入れる柔軟性も見たかった」とありました。Dさんの対応そのものが間違っていたわけではありません。ただペアプロ形式は一人で完結させる場ではなく、その場のやり取りを含めて評価される場だという前提を、Dさんは十分に意識できていませんでした。

私からは、「指摘をもらったら、まず理由を一言確認してから、取り入れるかどうかを判断する」という進め方を提案しました。次の面接では、「なるほど、可読性の観点ですね。他の箇所との一貫性を考えると、こちらの書き方の方が良さそうです」というように、指摘の意図を確認した上で自分の判断を添える対応ができ、内定につながっています。

ライブコーディング・オンラインジャッジ・ペアプロ、形式で変わる準備の中身

ここまで紹介した4つの実例からも分かる通り、コーディングテストと一口に言っても、形式によって求められる準備はまったく違います。私が候補者に伝えている、形式ごとの評価軸と準備のポイントを整理すると、次のようになります。

同じ「コーディングテスト対策」という言葉でも、練習すべき内容は形式によって別物だという点は、案外見落とされがちです。オンラインジャッジの問題を100問解いた人でも、ライブコーディングで声に出す練習をしていなければパターン①のような結果になり得ますし、逆にコミュニケーション力に自信がある人でも、オンラインジャッジの時間配分に慣れていなければパターン②のようにつまずきます。

求人票や選考案内に「コーディングテストあり」とだけ書かれていて、具体的な形式が分からないまま本番を迎える候補者も少なくありません。エージェント経由の応募であれば、過去にその企業を受けた候補者の情報をもとに形式を事前に伝えられることが多いので、選考が決まった時点で担当のアドバイザーに形式を確認しておくと、練習の的が絞りやすくなります。企業によっては、一次はオンラインジャッジ、二次でライブコーディングというように複数の形式を組み合わせていることもあるため、一つの形式だけ対策して安心してしまわないよう注意してください。

面接官は実際どこで不合格判定を出しているか

ここまでは候補者側から見た準備不足を紹介してきましたが、視点を変えて、企業側は実際どこで不合格の判定を出しているのでしょうか。私が採用担当者から受け取ってきたフィードバックを大まかに分類すると、次のような傾向があります。

特に多いと感じるのが、「技術力自体は問題ないが、〇〇が見えなかった」という言い方のフィードバックです。コードが正しく動くこと自体は前提条件であり、そこから先の「どう考えたか」「指摘にどう応じたか」という部分で合否が分かれているケースを、この7年間で数えきれないほど見てきました。

あるSaaS系企業の技術責任者からは、「うちは最終的にコードの綺麗さより、一緒に働いたときの進め方をイメージできるかで判断している」と聞いたことがあります。逆に言えば、コーディングテストの点数がボーダーライン近くでも進め方に好印象を持たれれば通過することもあれば、点数自体は高くても、その手前の姿勢で評価を落とすこともあるということです。点数だけを追いかけた対策が、必ずしも合格に直結しない理由はここにあります。

最近は、コーディングテスト中に生成AIやコード補完ツールを使ってよいかどうかも、企業ごとに方針が割れ始めています。「調べながらで構いません」という企業もあれば、「自力での実装力を見たいので不可」とする企業もあり、一律のルールはありません。AIの普及で採用側の評価基準そのものがどう変わってきているかは、生成AI時代のエンジニア転職で評価基準がどう変わったかで詳しく触れているので、気になる方はあわせて読んでみてください。

もう一つ、複数の企業から共通して聞くのが「時間内に終わらなかった候補者への評価は、想像以上にシビアになる」という話です。テストケースの通過率が7割を超えていても、制限時間を大幅にオーバーして提出した場合、実務でのタスク管理能力に懸念を持たれ、他の候補者との比較で見送りになることがあるそうです。裏を返せば、時間内に提出し切ったコードのほうが評価上は有利に働きやすいということでもあります。

今日からできる、形式別の準備チェックリスト

最後に、形式別にすぐ始められる準備を整理します。難しいアルゴリズムを新たに覚えるという話ではなく、本番までに癖をつけておくべき習慣です。

ライブコーディング形式の準備

コードを書き始める前に、口に出す練習をどれだけ積んでいるかで結果が変わります。一人での練習では意識しづらい部分なので、次の点を意識してみてください。

オンラインジャッジ形式の準備

こちらは時間配分と制約条件の読み方が鍵になります。事前に感覚をつかんでおくだけで、本番の焦りがかなり減ります。

ペアプログラミング形式の準備

指摘を受けたときの一言目をどう返すかを、あらかじめ決めておくと本番でも落ち着いて対応できます。

まとめ、コーディングテスト対策は「解ける」だけでは終わらない

技術面接やコーディングテストで落ちる人に共通するのは、アルゴリズムの知識不足より、本番の形式に合わせた練習をしていないことです。声に出す練習、時間配分の感覚、制約条件の読み方、指摘を受けたときの対応——どれも問題集を何百問解いても身につかない部分だからこそ、対策が後回しにされがちです。

コーディングテストを「難しい」と感じている人が7割を超えている一方で、対策の中身まで具体的にイメージできている人はまだ多くありません。この記事で紹介した4つの実例を、自分がどの形式で、どのパターンに近いかを確認する材料にしてもらえればと思います。

技術面接を突破した先にも、選考は続きます。希望年収を下げすぎて後悔した実例は以前の記事で紹介しましたし、逆質問の受け答えで通過率が変わった例も別の記事にまとめています。コーディングテストの対策とあわせて、選考全体を見据えて準備を進めてもらえればと思います。