エンジニア転職のコーディングテスト対策｜出題形式別の準備法
転職活動を始めてみたら、書類の次にいきなり「コーディングテスト」が来た。そんな経験はないだろうか。
日々の業務でコードを書いているエンジニアでも、制限時間付きのアルゴリズム問題となると勝手が違う。実務で使うスキルと、コーディングテストで問われるスキルは別物だからだ。実力はあるのにテストで落ちてしまうのは、対策不足が原因であることがほとんどだと思っていい。
この記事では、エンジニア転職で出題されるコーディングテストの傾向と、形式ごとの対策法をまとめた。どんな企業で出るのか、何を練習すればいいのか、実務経験者が引っかかりやすいポイントは何か。選考を受ける前に知っておくだけで、結果がかなり変わるはずだ。
コーディングテストを実施する企業の傾向
すべての企業がコーディングテストを実施しているわけではない。傾向としてはっきりしているのは、自社開発のメガベンチャーと外資系テック企業で実施率が高いということだ。
メガベンチャーでいうと、メルカリ、サイバーエージェント、LINEヤフー、DeNAあたりは選考プロセスにコーディングテストが含まれるケースが多い。応募者が多いため、書類選考の次のフィルターとして機能している面がある。
外資系ではGoogle、Amazon、Metaなどが有名だが、国内拠点を持つSmartNewsやTreasure Dataなども同様の選考を行う。難易度は国内企業と比べてワンランク上がる印象で、データ構造やアルゴリズムの理解が前提になる。
一方で、中小規模の自社開発企業やSIer、受託開発の会社ではコーディングテストを実施しないケースも多い。ポートフォリオや技術面接で代替するパターンだ。つまり、志望先によって準備すべき内容は変わる。まずは応募先の選考フローを確認するところから始めたい。
コーディングテストの出題形式は大きく3つ
コーディングテストと一口に言っても、形式はいくつかに分かれる。それぞれ求められるスキルが違うので、形式を知っておくだけで対策の方向性が見える。
オンラインジャッジ型
最も一般的な形式。HackerRankやTrackといったプラットフォーム上で、制限時間内にアルゴリズム問題を解く。自宅で受験するケースがほとんどで、言語は自由に選べることが多い。
出題内容は配列操作、文字列処理、探索・ソート、動的計画法あたりが定番。AtCoderでいうとABC（AtCoder Beginner Contest）のC〜D問題レベルが目安になる。制限時間は60〜90分で2〜3問というパターンが典型的だ。
この形式のポイントは「部分点」の存在。すべてのテストケースを通せなくても、正しいアプローチで一部を通せれば評価される場合がある。完璧を目指して時間を使い切るより、確実に取れる問題から片付けるのが鉄則だ。
ライブコーディング型
面接官の前でリアルタイムにコードを書く形式。Google等の外資系で多く、国内でもメルカリやSmartNewsが採用している。
技術的な難易度はオンラインジャッジ型と同程度か少し下がることが多い。ただし、思考過程を声に出して説明しながら解く必要がある。コードが完成しなくても、アプローチの筋がよければ通過できることもある。逆に、正解を出しても説明がしどろもどろだと評価が下がる。
面接官とのコミュニケーションも評価対象だ。問題の曖昧な部分を質問で潰す、エッジケースを自分から指摘する、計算量を意識した選択肢を提示する。こういった振る舞いが「一緒に仕事をしたい」という印象に直結する。
技術課題提出型（テイクホーム）
数日〜1週間の期限で、小さなアプリやAPIを実装して提出する形式。スタートアップや自社開発企業で採用されている。
「TODOアプリを作ってください」「REST APIを設計・実装してください」のようなお題が出る。アルゴリズム力よりも、実務に近い設計力やコードの読みやすさが問われる。テストコードの有無、エラーハンドリング、READMEの書き方まで見られる。
この形式では「やりすぎない」バランス感覚が大事だ。認証機能やCI/CDまで盛り込んで提出する人がいるが、求められていない機能を足すよりも、求められた範囲を丁寧に仕上げるほうが評価は高い。
形式ごとの対策法と練習リソース
対策は闇雲にやっても効率が悪い。形式に合わせて練習方法を変えるのが近道だ。
オンラインジャッジ型の対策
LeetCodeが世界的に定番のプラットフォーム。Easy→Mediumの順に解いていけば、転職で出題されるレベルはカバーできる。日本語で取り組みたいならAtCoderのABCが入りやすい。過去問が大量に公開されていて、解説記事も豊富だ。paizaのスキルチェックも国内企業の出題傾向に近く、対策として使える。
練習のコツは、1問にかける時間を決めること。20〜30分考えてわからなければ解説を読む。解法を理解したら、翌日にもう一度自力で解く。この「理解→再現」のサイクルを回すと、パターンが身についていく。週に5〜10問を1ヶ月続ければ、見違えるほど解けるようになる。
ライブコーディング型の対策
アルゴリズムの練習に加えて、声に出しながら解く訓練が必要になる。Pramp（無料のモック面接サービス）を使えば、実際の面接に近い環境で練習できる。相手もエンジニアなので、フィードバックがもらえるのもいい。
一人で練習する場合は、LeetCodeの問題を解きながら自分の思考を録音してみるのも効果的だ。後から聞き返すと「ここの説明が飛んでいる」「沈黙が長すぎる」といった改善点が見つかる。実際の面接では、沈黙が30秒以上続くと面接官も不安になる。「今こういうアプローチを考えていて、こういう理由でこの方法を試します」と、途中経過を共有する癖をつけておきたい。
技術課題提出型の対策
この形式は特別な練習というより、日頃の開発習慣がそのまま出る。強いて言えば、GitHubに個人プロジェクトを1つ丁寧に作っておくのが最良の準備になる。ディレクトリ構成、コミット粒度、テストカバレッジ、READMEの書き方。提出課題で見られるポイントを網羅的に練習できる。
課題に取り組む際は、最初にREADMEを書くところから始めるのがおすすめだ。要件の整理になるし、設計方針を言語化する練習にもなる。レビューする側の視点で考えると、READMEが丁寧なだけで「この人はコミュニケーションコストが低そうだ」という好印象につながる。
実務経験者が陥りやすい罠
業務でバリバリコードを書いているエンジニアほど、コーディングテストで思わぬ失敗をすることがある。典型的なパターンを2つ挙げておく。
「実務ではこう書かない」問題
実務では可読性やメンテナンス性を重視してコードを書く。変数名は丁寧につけるし、処理は関数に切り出す。だがコーディングテスト、特にオンラインジャッジ型では、制限時間内に正しい出力を返すことが最優先だ。実務の感覚で丁寧にコードを書いていると、時間が足りなくなる。
かといって、めちゃくちゃなコードを書けという話ではない。テストの場では「動くコードを速く書く」モードに切り替える意識が大事だということだ。変数名が多少雑でも、アルゴリズムが正しく動けば通過できる。この割り切りを事前に練習しておくと、本番で焦らずに済む。
時間配分のミス
3問出題されて最初の1問に40分かけてしまい、残り2問を20分で解こうとして全滅。これは非常によくあるパターンだ。特に「もう少しで解けそう」という状態が一番危険で、サンクコスト効果で離れられなくなる。
対策はシンプルで、最初に全問に目を通して難易度を見積もる時間を取ること。3分あれば十分だ。簡単な問題から着手して確実に得点を積み上げ、難しい問題は余った時間で取り組む。部分点が出る形式なら、完答を目指すより複数問で部分点を取るほうが合計スコアは高くなりやすい。
コーディングテストがない企業という選択肢
ここまで対策法を紹介してきたが、そもそもコーディングテストを実施しない企業に絞るという戦略もある。
スタートアップや成長フェーズのベンチャー企業では、カジュアル面談→技術面接→最終面接という流れで、コーディングテストなしで内定が出ることも珍しくない。エンジニアの採用を急いでいる企業ほど、選考ステップは少なくなる傾向がある。
LAPRASやFindy、転職ドラフトのようなスカウト型サービスを使えば、技術力をプロフィールで示した上で企業からアプローチを受けられる。スカウト経由だとコーディングテストが免除されるケースもある。選考のハードルを下げながら、自分に合った企業と出会いやすい仕組みだ。
もちろん、コーディングテストを避けること自体が目的になってはいけない。テストがある企業には優秀なエンジニアが集まりやすく、技術的に刺激のある環境であることも多い。自分が何を優先するかを整理した上で、戦略的に選考先を選ぶのがベストだろう。
まとめ
コーディングテストの対策で押さえておきたいポイントは3つ。
- 出題形式は「オンラインジャッジ型」「ライブコーディング型」「技術課題提出型」の3つ。形式ごとに求められるスキルが異なるので、志望先に合わせて対策する
- LeetCode・AtCoder・paizaで週5〜10問を1ヶ月継続するだけで、実力は大きく伸びる。ライブコーディングは声出し練習を忘れずに
- 実務経験者は「丁寧に書きすぎる」「時間配分を間違える」罠に注意。テスト用の立ち回りを事前に練習しておく