ソフトウェアエンジニアの面接質問

回答の組み立て — 補数をハッシュ表に保存する

配列を一度走査します。各値xについてtarget − xが表にあれば、その添字と現在の添字を返します。なければxと添字を保存します。各要素を一度処理するため時間O(n)、空間O(n)です。解が一つだけか、同じ添字を再利用できるかを先に確認します。

回答の組み立て — 各文字の最終位置を使うスライディングウィンドウ

重複を含まない区間[left, right]と、各文字を最後に見た位置を保持します。現在の区間内で文字が再登場したら、leftをlastSeen + 1へ進めます。位置と最大長を更新し、leftは後退させません。時間O(n)、空間O(k)で、kは文字集合の大きさです。

回答の組み立て — 各単語から正規化キーを作る

各単語から正規化キーを作り、同じキーをハッシュ表でまとめます。キーには整列した文字列、または文字集合が固定なら文字頻度配列を使えます。整列なら時間O(n・m log m)、頻度ならO(n・m)で、mは単語長です。

回答の組み立て — previous、current、nextの三つのポインタ

prevをnull、currentを先頭にします。各反復でcurrent.nextを保存し、current.nextをprevへ向け、二つのポインタを進めます。終了時のprevが新しい先頭です。不変条件は、prevが常に反転済み部分を指すことです。時間O(n)、空間O(1)です。

回答の組み立て — 許容される下限と上限を再帰的に渡す

直下の子との比較だけでは不十分です。各ノードへ許容範囲を渡して再帰し、左では現在値を上限、右では下限にします。範囲を外れたノードがあれば無効です。重複値の規則も確認します。時間O(n)、再帰の空間O(h)です。

回答の組み立て — 距離ごとの幅優先探索

通行可能な各セルをノードとして開始地点から幅優先探索します。重複を避けるため、キューへ入れる時点で訪問済みにします。層ごとに進むため、目的地へ最初に到達した経路が最短です。経路自体を返すなら親を保存します。時間・空間ともO(行数・列数)です。

回答の組み立て — 元ノードから複製ノードへの対応表を作る

深さ優先または幅優先探索を使い、元ノードと複製ノードの対応表を保持します。初回訪問時に複製を作って先に保存し、その後で隣接ノードを複製します。先に保存することで循環を防ぎ、共有された隣接先も保てます。時間・空間ともO(V + E)です。

回答の組み立て — 各金額に対するボトムアップ動的計画法

dp[a]を金額aに必要な最小枚数と定義します。dp[0] = 0、他を無限大で初期化し、各金額とc ≤ aの硬貨についてdp[a] = min(dp[a], dp[a − c] + 1)と更新します。目標値が無限大なら作れません。時間O(金額・硬貨数)、空間O(金額)です。

回答の組み立て — 末尾位置ごとの動的計画法と二分探索による最適化

基本解ではdp[i]を位置iで終わる最長長とし、nums[j] < nums[i]を満たす各j < iから更新してO(n²)です。最適化では各長さに対する最小の末尾値を保持し、二分探索で置き換えることでO(n log n)にします。

回答の組み立て — 有効な接頭部分だけを生成する

文字列を一文字ずつ作ります。open < nなら開き括弧を追加でき、close < openの場合だけ閉じ括弧を追加できます。長さが2nになれば有効な組み合わせです。無効な接頭部分を一度も作らないため、探索空間を早期に枝刈りできます。

回答の組み立て — 要件 → API → ID生成 → 保存 → 転送 → 拡張

長いURLを送ると短いコードを返し、転送は高速であることを要件とします。主要APIは短縮URL作成と転送で、レコードにはコード、転送先、利用者、作成日時、有効期限、状態を保存します。 コードは連番IDをBase62化するか、衝突検出付きで無作為生成します。読み取りではDBの前にキャッシュを置き、状態と期限を検証して301または302を返します。分析はキューで非同期処理します。規模が増えればエッジキャッシュ、コード単位の分割、流量制限、不正利用対策を加えます。

回答の組み立て — 利用者 → 投稿 → 配信 → 順位付け → 読み取り → 一貫性

フォロー中アカウントのフィードを想定します。主要な実体は利用者、フォロー、投稿、メディア、フィード項目、反応です。投稿、ソーシャルグラフ、フィード、順位付けの各サービスを、キャッシュ、オブジェクトストレージ、キューと組み合わせます。 書き込み時配信は読み取りが速い一方、大規模アカウントには高コストです。読み取り時配信は書き込みを抑えますが遅延が増えます。通常アカウントは書き込み時、有名アカウントは読み取り時に処理する混合方式が妥当です。鮮度、プライバシー、キュー障害、キャッシュ無効化、スパムも扱います。

回答の組み立て — 接続 → メッセージ経路 → 保存 → 配信 → 信頼性

クライアントはゲートウェイとWebSocket接続を維持します。送信時にゲートウェイが認証し、冪等キーを確認し、メッセージを保存してイベントを発行し、接続中の宛先へ配信します。オフライン利用者にはプッシュ通知を送り、最後に確認した位置から同期します。 モデルには会話、参加者、メッセージ、配信、既読、端末を含めます。冪等キーで重複を防ぎ、会話ごとの連番で順序を保ち、確認応答と再試行で配信を保証します。添付はオブジェクトストレージに保存し、遅延、配信率、接続、再接続、キュー、書き込み失敗を監視します。

回答の組み立て — 信号を検証 → 範囲を特定 → 変更を確認 → 依存先を分解 → 緩和

複数の監視系で異常を確認し、p50、p95、p99と各エンドポイントを見ます。地域、ゾーン、バージョン、ホスト、クライアント、要求種別、依存先で分けて範囲を絞ります。 直近のデプロイ、設定、移行、流量、機能フラグ、キャッシュ、下流障害を確認します。トレースで遅延を分解し、DB、キャッシュ命中率、キュー、CPU、メモリ、GC、接続プールも見ます。利用者への影響があるなら、完全な原因証明を待たず、ロールバック、フラグ停止、増強、遅い依存先の切り離しで先に緩和します。

回答の組み立て — 通常例 → 境界 → 不正入力 → 不変条件

割引種別、組み合わせ、有効期限、最低額、対象条件、丸め、税、送料を確認します。単体テストでは割引なし、割合、固定額、最低額ちょうど・未満、期限切れ、対象外、併用を扱います。 価格が負にならない、割引が対象額を超えない、期限切れは適用されない、同じ入力は同じ結果になる、という不変条件を確認します。決済に影響するなら結合テストを加え、各判断理由を記録します。

回答の組み立て — 正確性 → 保守性 → リスク → 明快さ

正しく問題を解いているか、境界が明確で保守しやすいか、移行・並行処理・セキュリティ・性能・互換性・可観測性にどのリスクがあるか、テストが変更を覆っているか、の順で確認します。 必須修正と提案を区別します。正確性、セキュリティ、移行上の問題は差し止め理由になりますが、個人の好みはなりません。レビューは優位性を示す場ではなく、コードとチームの速度をともに改善する場です。

回答の組み立て — 背景 → 選択肢 → トレードオフ → 決定 → 結果

内製か購入か、SQLかNoSQLか、応急修正か再設計か、一貫性か可用性かなど、本当に複数の選択肢があった判断を選びます。背景、制約、選択肢を説明します。 流量、顧客期限、過去の障害、チーム能力、ロードマップなど、決定的だった証拠とトレードオフを示します。結果と学びで締め、現在なら変える点も率直に説明します。

回答の組み立て — 障害 → 影響 → 対応 → 原因 → 再発防止

何が壊れ、誰にどの程度影響したかから始めます。検知、切り分け、ロールバック、緩和、連絡、原因分析のどこを担当したか説明します。 障害中は理論の証明より復旧を優先します。ログ、指標、トレース、機能フラグ、ロールバック、依存先をどう使ったか示します。復旧後は責任追及ではなく、テスト、段階公開、監視、手順書などの再発防止策を説明します。

回答の組み立て — 共通目標 → 制約 → 選択肢 → トレードオフ → 決定

まずユーザーと事業の目標をそろえます。多くの対立は前提の違いから生じます。複雑さ、信頼性、日程、保守性、セキュリティ、性能などの技術的制約を具体的に説明します。 単に拒否せず、範囲を絞ったMVP、一時的な手動処理、機能フラグ、段階的な開発、より単純な設計を提案します。リスクが大きければ、選択肢、影響、推奨案を記録します。目的は開発側を勝たせることではなく、チームが十分な情報で決められるようにすることです。