コードレビュー面接の対策：リスクを見つけ、伝わる指摘を書く

面接ではdiff、リポジトリ、短い関数などが渡され、共有画面上でコメントを書く場合があります。要件、言語バージョン、本番制約、求められる深さを確認し、この変更が何を実現するかを要約します。

テストと公開インターフェースを早めに読みます。実装を一行ずつ追うより、意図した契約が早く分かることがあります。情報がなければ仮定を明示し、質問として残します。

動作とデータ整合性、セキュリティとプライバシー、障害時の運用、テスト、保守性、スタイルの順で見ます。命名の好みを考えている間に、削除処理のデータ損失を見逃す事態を防げます。

各指摘について、発生する入力、影響する人、結果の重大さ、解消に必要な証拠を考えます。「堅牢でない」という評価より、具体的な失敗条件が役に立ちます。

コメントは優先度、観測、影響、依頼の順にします。例：「必須修正：残高の読み取りがトランザクション開始前です。同時リクエストが両方とも判定を通り、残高を超えて利用できます。読み書きを一つのトランザクションへ移し、並行実行テストを追加できますか」。

人ではなくコードについて書きます。「あなたがキャッシュを忘れた」より「この分岐では古い値が返る可能性がある」の方が明確です。任意なら提案やNitと示し、承認を止めないと伝えます。

面接記録をIDで削除する新しいAPIがあり、正常系テストだけがあるとします。命名より先に、その記録が現在のユーザーのものか、関連データをどう扱うか、再削除の挙動、監査や応募状態との整合性を確認します。

最後に、所有者確認の必須修正、関連データに関する質問、冪等性テストの提案を一つずつ要約します。すべてを同じ重さで並べるより、判断力が伝わります。

公開PRか、意図的に問題を入れた30行ほどの変更を20分でレビューします。観点の広さ、優先順位、具体性、表現、必須指摘に再現可能な影響があるかを採点します。

必要なら日本語・英語でもう一度行います。日本語面接でも複雑な敬語は不要です。「確認です」「この条件では」「必須修正と考えます」のように、重大さを隠さない言葉を使います。

すべてのバグを見つける必要はありません。再現できるレビュー手順と高いリスクの発見を見せます。小さなコード案は修正意図を説明できますが、全体を書き直しません。言語に詳しくない場合は、契約、データの流れ、障害、テストを確認し、言語固有の不確かさを正直に示します。

最後に、チームが何を必須修正とするか、対立をどう解決するか、レビュー担当がどの本番指標まで持つかを質問すると、入社後の開発方法も確認できます。