ライブデバッグ面接の対策：当てずっぽうではなく調査手順を見せる

ライブデバッグでは、初見のコード、失敗している動作、限られた時間が与えられます。すぐにバグを当てることより、別のエンジニアが調査を追い、仮定を問い、最終修正を信頼できるかが重要です。

最初に期待動作、使えるツール、制限時間、テストやログ確認の可否を聞きます。日本語・英語・併用のどれで進めるかも確認し、長い説明ではなく短い文で考えを共有します。

観測は「APIは200を返すが一覧が空」のような事実です。仮説は「日付フィルターのタイムゾーンが違う」のような説明です。テストは、その仮説と別の説明を区別できる必要があります。最後の確認では、症状が消えたことと周辺動作が壊れていないことを示します。

事実、仮説、テスト、結果の4列だけのメモを残します。同じ案を試し直すのを防ぎ、面接官にも判断の流れが見えます。

JSTの0時10分に作った記録が日次レポートに出ないとします。境界の内側と外側に一件ずつデータを作り、どこで日付が時刻に変わるかを追います。ローカル日付がUTCへ二重変換されていると考えたら、境界だけを再現する最小テストを書きます。

「失敗が日付境界に集中しています。まず直列化の前後で時刻を比べ、正しければDBの条件式へ進みます」と話せば、次の行動と理由を短く共有できます。

仮説が外れること自体は問題ではありません。複数行を同時に変えて偶然通すのではなく、結果から何を除外できたかを言い、次に情報量の多い観測を選びます。

止まったら、入力、変換、保存、出力に分け、値が最後に正しかった場所を探します。ヒントを求める場合も、試した内容を先に要約します。

自分が書いていない小さなリポジトリを使います。5分で失敗と入口を読み、20分で調査し、10分で修正とテスト、5分で原因説明、残り5分で回帰リスクと次の改善を話します。

一度録音し、事実から結論への飛躍、同じテストの繰り返し、長すぎる独り言を探します。問題、仮説ログ、最終説明を面接ノートに残し、次回は実際の弱点を練習します。

話し続ける必要はありません。次のテストと目的を言い、コードを読む時間は黙って構いません。最適化は、まず修正を確認し、設問で求められた場合に行います。AIや検索は、開けるかではなく、明示された利用ルールに従います。

環境が壊れている場合は、コマンド、エラー、制御した再試行を示し、環境修復を続けるかコード上の推論へ移るか確認します。