コーディング課題への向き合い方｜提出前にやる5つの確認【2026年版】

エンジニアの選考で、コーディング課題が出ることがあります。持ち帰りで数日、あるいはその場で解く形。「解けるかどうか」だけが見られていると思うと、対策を間違えます。

実際に見られているのは、動くコードを書けるかに加えて、どう考えて書いたかです。だから、完璧に動くコードを提出しても落ちることがあり、一部が未完成でも通ることがあります。

この記事では、評価される点と、提出前にやる確認を整理します。

1. 結論：見られているのは4つ

1、動くかどうか。これは前提です。動かないコードは評価の対象になりません。

2、読めるかどうか。変数名、関数の分け方、コメント。他人が読んで分かるか。

3、指示を満たしているか。課題文に書かれた要件を、漏れなく実装しているか。

4、考えた過程が分かるか。なぜその設計にしたか、何を諦めたか。

4番目が最も差がつきます。そして、これはコードではなくREADMEや提出時のコメントで示します。

未経験や経験の浅い段階では、1〜3が満たせていれば十分です。その上で4があると、他の応募者と差がつきます。

2. 課題の種類

第二新卒の選考では、1行目と2行目が多いです。

3行目のライブコーディングは、解けることより「詰まったときにどう動くか」が見られます。黙り込まず、考えていることを口に出してください。「今、この部分でループの条件を考えています」と言うだけで、評価が変わります。

4行目は、経験者向けに出されることが多い形です。

3. 編集長が相談を受けた話：完璧より説明が評価された

未経験からエンジニア職を受けた方から、選考の話を聞きました。

相談者「課題を出したんですが、一部が実装しきれなくて」

私「それでも通ったんですね」

相談者「はい。READMEに『検索機能は実装できませんでした。理由は、絞り込みの条件が複数になったときの設計が固まらなかったためです』と書きました」

私「それを書いたんですか」

相談者「面接で、そこを一番聞かれました。『どういう設計で迷いましたか』と」

実装できなかった部分を書いたことが、評価につながりました。

できなかったことを隠すと、面接で説明できません。「なぜこの機能がないのですか」と聞かれて、その場で答えることになります。

先に書いておけば、それが議論の材料になります。

「できなかった」と書くのは、正直さの証明ではありません。設計の判断について考えていた証拠になるから評価されます。

4. 時間のかけ方

持ち帰り課題の場合

手順1を飛ばさないでください。要件を箇条書きにしないと、実装漏れが起きます。課題文に5つの要件があれば、5行の箇条書きにしてから始めます。

手順5に時間を確保してください。動いたところで終わりにすると、変数名が雑なまま提出することになります。

手順6は5%ですが、第3章の通り最も差がつく部分です。

期限の使い方

期限が5日なら、3日目に一度完成させてください。残り2日で整える形にします。最終日に実装していると、READMEを書く時間がなくなります。

5. 提出前の5つの確認

確認1、課題文の要件をすべて満たしているか。箇条書きにした要件と、実装したものを突き合わせます。

確認2、動作を確認したか。正常なケースだけでなく、空の入力、想定外の値でも試してください。

確認3、変数名と関数名が読めるか。a tmp data2 のような名前が残っていないか。

確認4、不要なコードが残っていないか。コメントアウトした古いコード、デバッグ用の出力。

確認5、READMEがあるか。次章の内容が書かれているか。

2行目が最も多い落とし穴です。正常なケースでしか試していないと、空の入力やゼロ件の結果で落ちます。

提出前に、最低3パターン試してください。正常なケース、空のケース、想定外の値。

6. READMEに書くこと

書く6項目

1行目を必ず書いてください。実行方法が分からないと、評価する側が動かせません。

3行目と4行目が、第3章で評価された部分です。

書き方の例

【実装した機能】
・一覧の表示（要件1）
・新規登録（要件2）
・削除（要件3）

【実装しなかった機能】
・検索機能（要件4）
　絞り込みの条件が複数になったときの設計が固まらず、
　中途半端な実装を避けて見送りました。
　条件を配列で受け取り、順に適用する形を考えていました。

【設計の判断】
・データの保存はファイルにしました。
　課題の規模ではデータベースを使う必要がないと判断したためです。

【詰まった点】
・日付の形式の変換で、想定と違う結果になりました。
　タイムゾーンの指定が必要だと分かり、明示的に指定して解決しています。

「実装しなかった機能」に、考えていた方針まで書くのが要点です。「できませんでした」だけだと、考えていなかったように見えます。

7. 面接で聞かれる3問と答え方

課題を提出すると、その内容が面接で掘られます。

Q1「この設計にした理由を教えてください」

回答例：「データの保存にファイルを使いました。課題のデータ量では、データベースを立てる手間に対して得られる利点が小さいと判断したためです。件数が増える想定であれば、データベースに変える必要があると考えています。」

「なぜ他の選択肢ではないか」まで答えられると、判断できる人だと伝わります。

Q2「一番時間がかかった部分はどこですか」

回答例：「日付の形式の変換です。想定と違う日付が出力されて、原因が分かるまで1時間かかりました。タイムゾーンの指定が必要だと、公式のドキュメントを読んで分かりました。」

Q3「時間があれば何を直しますか」

回答例：「検索機能の実装と、テストコードの追加です。特にテストは、機能を追加するたびに手動で確認していたので、そこを自動化したいと考えています。」

現状の限界を理解していることを示す質問です。「特にありません」だと、改善の余地が見えていないと受け取られます。

8. 解けなかった場合の対応

提出しないのは避けてください。

やること

1、できたところまでを提出する。部分的でも構いません。

2、READMEに、どこまでできてどこで止まったかを書く。

3、止まった理由を具体的に書く。「難しかった」ではなく、何が分からなかったかを書きます。

4、期限内に提出する。完成度より期限です。

書き方の例

【現在の状態】
要件1と2は実装済みで動作します。
要件3の削除機能は、実装の途中で提出しています。

【止まった理由】
削除の際、関連するデータをどう扱うかで判断がつきませんでした。
関連データも一緒に削除する方法と、削除フラグを立てる方法の
どちらが適切か、判断の基準が分からず手が止まりました。

この書き方だと、面接で「その2つの違いは何だと思いますか」という会話ができます。

提出しないと、その会話自体が生まれません。

期限に間に合わない場合

期限前に連絡してください。「〇日までに提出予定でしたが、実装が完了していません。現状のもので提出してよろしいでしょうか」と確認します。

黙って遅れるのが最も印象が悪くなります。

9. よくある質問

調べながら解いていいですか

多くの場合、問題ありません。実務でも調べながら書くためです。ただし、課題文に「調べずに」と指定がある場合は従ってください。

AIツールを使っていいですか

課題文に指定がなければ、使用の可否を確認してください。使った場合は、その旨をREADMEに書くほうが誠実です。面接でコードの内容を説明できることが前提になります。

実装にかける時間の目安は

課題文に「3時間程度」などの目安が書かれていることがあります。書かれていない場合、期限の半分程度で一度完成させ、残りで整える形にしてください。

動かないまま提出していいですか

部分的にでも動く状態にしてください。まったく動かない場合、READMEにその旨と、どこで詰まったかを書いて提出します。

テストコードは書くべきですか

課題文に指定があれば必須です。指定がなくても、簡単なものを書くと評価されます。ただし、本体の実装を優先してください。

コメントはどのくらい書きますか

処理の内容ではなく、判断の理由を書いてください。「なぜこうしたか」が伝わるコメントが有効です。

提出後に間違いに気づきました

期限内なら、修正して再提出してよいか確認してください。期限後なら、面接で自分から触れてください。

ライブコーディングで頭が真っ白になったら

黙り込まず、考えていることを口に出してください。「今、この条件をどう書くか考えています」でも構いません。詰まったときの動き方が見られています。

10. まとめ：課題を受け取ったらやる3つのこと

コーディング課題は、解けたかどうかだけで評価されるわけではありません。

1つめ、課題文の要件を箇条書きにする。実装漏れを防ぐためです。提出前に、この箇条書きと突き合わせます。所要10分。

2つめ、期限の半分の時点で一度完成させる。残りの時間で整えます。最終日に実装していると、READMEを書く時間がなくなります。

3つめ、READMEに「実装しなかった機能」と「その理由」を書く。できなかったことを書くのは、隠すより評価されます。所要20分。

コードだけを提出するのと、READMEを添えるのとでは、面接での会話がまったく変わります。

この先、読むべき記事

• エンジニアの技術面接｜未経験・第二新卒が答えより見られている3つ（技術面接の対策）
• 未経験エンジニアのポートフォリオ｜第二新卒が評価されるのは「何を作ったか」ではない（制作物の作り方）

この記事を書いた人

木戸 悠介（きど ゆうすけ）／なぜキャリア？運営者。

23歳で上場企業子会社に新卒入社し、飲食・宿泊・レジャー領域のメディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた経験を持つ。2ヶ月で10社に応募し2社から内定。現在は自分の会社を経営している。