技術面談・コーディングテストへの備え方｜形式の確かめ方と当日の進め方

技術面談やコーディングテストで見られるのは、正解にたどり着く速さより、考え方を言葉にしながら、筋道立てて進められるかです。備え方の基本は、事前に形式・時間・使える道具を確かめ、直近の業務を説明する準備と、手を動かす練習を分けて行うことです。

業務委託の面談は、参画してすぐに任せられるかを確かめる場です。そのため、技術の確認も、試験問題を解く力より、実際の業務に近い場面でどう動くかに寄せて行われることが多くあります。この記事では、確認の形ごとの準備と、当日の進め方を整理します。

業務委託の面談で行われる技術確認の形

技術の確認には、いくつかの形があります。どの形で行われるかで、準備することが変わります。

業務委託の面談では、口頭の技術質問と、過去の設計の説明が中心になることが多く、その場でコードを書く形は案件によって分かれます。面談そのものの流れは面談の流れの記事で解説しています。

事前に確かめておくこと

技術の確認があると分かったら、担当者や窓口を通じて、次のことを確かめます。

1. 形式：口頭か、コードを書くか、テストか。オンラインか対面か
2. 時間：面談全体の時間と、そのうち技術の確認にあてる時間
3. 範囲：言語、フレームワーク、扱う分野（アルゴリズム、設計、インフラなど）
4. 環境：自分の開発環境を使うか、指定のツールを使うか。画面共有の有無
5. 使ってよいもの：検索、公式ドキュメント、生成AIの支援ツールを使ってよいか
6. 見られる観点：完成させることか、進め方か

5つ目は、特に確かめておきたい点です。使ってよいかどうかは提出先ごとに違い、決まりが分からないまま使うと、評価に影響することがあります。分からないときは、当日の冒頭で確かめても構いません。

口頭の技術面談の準備

直近の案件を「構成・判断・結果」で話せるようにする

口頭の面談で最もよく聞かれるのは、直近の案件の技術的な中身です。次の3つを、図なしでも説明できるようにしておきます。

• 構成：どんな仕組みで動いていたか。主な部品と、そのつながり
• 判断：なぜその技術ややり方を選んだのか。ほかの選択肢と比べて何を重視したか
• 結果：うまくいったこと、困ったこと、それにどう対応したか

自分が決めたことと、チームや前任者が決めたことは分けて話します。全体の構成を自分が決めたように話すと、深く聞かれたときに答えられなくなります。

守秘に触れない言い方を用意する

直近の案件ほど、守秘の取り決めがあります。社名や固有のシステム名、未公開の数値は出さずに、構成や判断を説明できるように言い換えを用意しておきます。言い換えの型はスキルシートと守秘義務の記事で紹介しています。

知らないことを聞かれたとき

知らない技術について聞かれたら、知らないと正直に答えたうえで、近い経験や、調べるならどう進めるかを話します。

その技術は実務で使ったことがありません。似た役割のものとしては◯◯を使っていました。使うことになれば、まず公式のドキュメントで◯◯の違いを確かめるところから始めます。

分かったふりをして答えると、続く質問で崩れます。知らないことを素直に言える人のほうが、任せる側は安心できます。

コーディングテストの準備

環境を先に整える

自分の環境を使う形であれば、前日までに次のことを済ませておきます。

• 指定の言語の実行環境が動くか
• 画面共有で、エディタの文字が相手に読める大きさか
• 通知やチャットの表示を止めているか
• 画面に、ほかの案件の資料やコードが映らないか

最後の点は、守秘の面で特に大切です。画面共有の前に、関係のないウィンドウやタブを閉じておきます。

練習は「声に出して解く」形で

ライブコーディングでは、黙って書き続けるより、考えていることを話しながら進めるほうが評価されやすくなります。練習のときから、次の順番を声に出して進めます。

1. 問題の理解を確かめる（入力と出力、条件、例外の扱いを聞き返す）
2. 方針を先に話す（まずは素直な方法で書き、あとで改善する、など）
3. 書きながら、何をしているかを短く説明する
4. 書き終えたら、例を使って自分で動きを確かめる
5. 改善できる点（速さ、読みやすさ、例外の扱い）を話す

時間内に終わらないとき

時間内に完成しないこともあります。そのときは、どこまでできていて、残りをどう進めるつもりかを説明します。未完成でも、進め方が筋道立っていれば、評価はそこで決まりません。

当日の進め方

当日は、技術の確認に入る前の数分で、進め方をそろえておくと落ち着いて臨めます。

1. 冒頭で形式と時間を確かめる：事前に聞いていた内容と変わっていないか、何分くらいかを確かめます
2. 質問の意図が分からなければ聞き返す：「◯◯という意味でよろしいでしょうか」と確かめてから答えます。ずれたまま長く答えるより、早く伝わります
3. 答えは結論から話す：先に一言で答え、そのあとに理由や経験を足します
4. 時間の配分を意識する：一つの質問で話しすぎていると感じたら、「詳しくお話ししたほうがよいですか」と相手に委ねます
5. 最後に補足の機会を使う：答えきれなかった点があれば、短く補います

回線や音声の不調があったときは、無理に続けず、すぐに伝えて立て直します。オンラインの面談の環境づくりはオンライン面談の記事にまとめています。

職種によって変わる確認の中身

技術の確認の中身は、職種によって違います。

• インフラ・クラウド：構成の設計の理由、障害が起きたときの調べ方と対応の順番
• データ：データの取り込みから加工、利用までの流れ、品質の確かめ方
• テスト・品質：テストの観点の立て方、自動化する範囲の決め方
• PM・PMO：技術そのものより、課題の整理や進め方を問われるケースの質問が多い

PMやPMOの案件でも、技術的な判断が求められる場面について聞かれることがあります。開発の経験がある場合は、その経験が進め方の判断にどう生きたかを話せるようにしておきます。

持ち帰りの課題を出されたとき

持ち帰りの課題を出された場合は、取りかかる前に、次のことを確かめます。

• 想定されている作業の時間と、提出の期限
• 提出したものの扱い（評価だけに使うのか、業務で使われることがあるのか）
• 評価の観点（完成度か、書き方か、説明か）

想定より大きな作業や、実際の業務の一部のように見える課題を出された場合は、無償で引き受けてよいかを考える必要があります。線引きの考え方は課題の提出を求められたときの記事で解説しています。

終わったあとの振り返り

技術の確認が終わったら、記憶が新しいうちに、聞かれたことと自分の答えを書き出します。

• 答えられなかった質問と、正しくはどう答えればよかったか
• 説明が長くなった、または伝わらなかったと感じた場面
• 次に備えて調べておくこと

結果が見送りだった場合も、この記録があれば、次の面談で同じところでつまずかずに済みます。見送りの理由の聞き方は見送られる理由の記事、案件と並行した学習の時間の作り方は学習時間の記事にまとめています。

よくある質問

コーディングテストで生成AIの支援ツールを使ってもよいですか？

提出先の決まりによります。使ってよい場合も、禁止されている場合もあります。事前に担当者を通じて確かめ、分からなければ当日の冒頭で聞いてください。決まりが分からないまま使うのは避けます。

実務で使っていない言語で、テストを受けることになりました。

使える言語を選べるかを、先に確かめてください。選べない場合は、その言語の基本の書き方を練習したうえで、当日は実務で使ってきた言語との違いを意識していることを話しながら進めます。実務の経験がないことは、面談で正直に伝えます。

技術面談で答えられない質問が多く、手応えがありませんでした。

答えられなかった質問があっても、見送りになるとは限りません。知らないことを正直に伝え、どう調べるかを話せていれば、評価される場合もあります。結果を待つ間に、答えられなかった点を調べて記録しておくと、次の面談に生かせます。