ジュニアバックエンドエンジニア面接質問

ジュニアレベルで求められること

CRUD API、基本的なSQL、コアなデータ構造、範囲が明確なタスクが問われます。

バックエンドエンジニアの面接質問サンプル

• 技術面接NoSQLストアよりSQLデータベースを選ぶのはどんな時で、なぜですか？
  良い回答が押さえる点

  • リレーショナルモデルとACIDトランザクション
  • スキーマ強制とデータ整合性
  • JOINや集計が必要な複雑なクエリ
  • 強い一貫性の要件
  • インデックスによる高速なランダムアクセス

  サンプル回答を見る

  SQLデータベースを選ぶべき時は、データが強く関連しており、ACIDトランザクションによる原子性・一貫性・独立性・永続性が必要な場合です。例えば、金融システムでは、口座間の送金において、部分的な更新が許されないため、トランザクション保証が必須です。また、スキーマが固定されており、データの整合性をデータベースレベルで強制したい場合もSQLが適しています。複雑なJOINや集計クエリが必要な分析用途でも、SQLのリレーショナルモデルは強力です。一方、NoSQLは水平スケーラビリティや柔軟なスキーマが求められる場合に有利ですが、結果整合性やJOINの制限があります。従って、強い一貫性と複雑なクエリが必要な場面ではSQLを選択します。

• 技術面接データベースインデックスはどう機能し、トレードオフは何ですか？
  良い回答が押さえる点

  • B-Tree構造によるO(log n)検索
  • 主キーインデックスとセカンダリインデックス
  • クラスタ化インデックス vs 非クラスタ化
  • 書き込み性能の低下
  • ストレージオーバーヘッドとインデックス選定

  サンプル回答を見る

  データベースインデックスは、B-Treeやハッシュなどのデータ構造を用いて、検索を高速化します。B-Treeインデックスでは、ルートからリーフまでを辿ることでO(log n)の時間でレコードにアクセスできます。主キーにはクラスタ化インデックスが使われ、データ行がインデックス順に物理的に並びますが、セカンダリインデックスは別の構造を持ち、ルックアップに余計なI/Oが発生します。トレードオフとして、インデックスは書き込み操作（INSERT、UPDATE、DELETE）のたびに更新されるため、書き込み性能が低下します。また、ストレージ容量も消費します。多くのインデックスを張りすぎると、オプティマイザが誤ったインデックスを選択するリスクもあります。そのため、実際のクエリパターンに基づいてインデックスを慎重に設計する必要があります。

• 技術面接決済エンドポイントを冪等にする方法を説明してください。
  良い回答が押さえる点

  • 冪等性の定義と一意な冪等キー
  • リクエストの重複検出
  • データベースの一意制約と楽観的ロック
  • 冪等キーの有効期限とクリーンアップ
  • 決済処理自体の冪等性

  サンプル回答を見る

  決済エンドポイントを冪等にするためには、クライアントがリクエストごとに一意な冪等キー（Idempotency-Key）を送信する方式が一般的です。サーバー側では、このキーをキーに処理結果をキャッシュし、同じキーが再度来た場合は最初の応答を返します。例えば、データベースに冪等キーと処理結果のテーブルを作成し、キーにUNIQUE制約をかけて重複を防ぎます。初回のリクエストでは、トランザクション内でキーを挿入し（挿入が成功した場合のみ実際の決済処理を実行）、失敗した場合はエラーを返します。冪等キーには有効期限を設定し、古いキーは定期的に削除してストレージを節約します。また、決済処理自体も冪等に設計し、例えば同一の注文に対する二重課金を防ぐために、注文ステータスをチェックして既に完了していれば処理をスキップします。

• コーディングO(1)のgetとputを持つLRUキャッシュを実装してください。
  良い回答が押さえる点

  • 双方向連結リストとハッシュマップの組み合わせ
  • get/putにおけるノードの先頭移動
  • 容量超過時の末尾ノード削除
  • O(1)操作の実現
  • スレッドセーフではない注意

  サンプル回答を見る

  LRUキャッシュをO(1)で実装するには、双方向連結リストとハッシュマップ（辞書）を組み合わせます。ハッシュマップでキーからリストノードへの参照を保持し、リストで使用順を管理します。getでは、ノードをリストの先頭に移動します。putでは、キーが既存なら値を更新してノードを先頭に移動、新規ならノードを先頭に追加し、容量を超えたら末尾ノードを削除します。PythonではカスタムLinkedListとdictで実装可能です。時間計算量はget/putともにO(1)、空間計算量はO(capacity)です。マルチスレッド環境ではロックが必要です。

  class Node:
      def __init__(self, key, val):
          self.key = key
          self.val = val
          self.prev = None
          self.next = None
  
  class LRUCache:
      def __init__(self, capacity: int):
          self.cap = capacity
          self.cache = {}  # key -> Node
          self.head = Node(0, 0)  # dummy head
          self.tail = Node(0, 0)  # dummy tail
          self.head.next = self.tail
          self.tail.prev = self.head
  
      def _remove(self, node: Node):
          node.prev.next = node.next
          node.next.prev = node.prev
  
      def _add_to_front(self, node: Node):
          node.next = self.head.next
          node.prev = self.head
          self.head.next.prev = node
          self.head.next = node
  
      def get(self, key: int) -> int:
          if key in self.cache:
              node = self.cache[key]
              self._remove(node)
              self._add_to_front(node)
              return node.val
          return -1
  
      def put(self, key: int, value: int) -> None:
          if key in self.cache:
              node = self.cache[key]
              node.val = value
              self._remove(node)
              self._add_to_front(node)
          else:
              if len(self.cache) >= self.cap:
                  lru = self.tail.prev
                  self._remove(lru)
                  del self.cache[lru.key]
              new_node = Node(key, value)
              self.cache[key] = new_node
              self._add_to_front(new_node)

• コーディングイベントのストリームが与えられたとき、APIのレートリミッターを設計してください。
  良い回答が押さえる点

  • スライディングウィンドウアルゴリズム
  • RedisのSorted Setを使ったカウンター管理
  • 分散環境での一貫性確保
  • バーストトラフィックとトークンバケット
  • エラーレスポンス（429 Too Many Requests）

  サンプル回答を見る

  スライディングウィンドウアルゴリズムを採用し、RedisのSorted Setを使って各ユーザーのリクエストタイムスタンプを管理します。ウィンドウ内のリクエスト数が閾値を超えたら拒否します。トークンバケット方式も簡易ですが、バーストトラフィックを許容できる点がメリットです。分散環境では、Redisクラスターでデータを共有し、レート制限の一貫性を確保します。レートリミッターはミドルウェアとして実装し、リクエストごとにユーザーIDをキーにカウントをインクリメントします。制限を超えた場合はHTTP 429とRetry-Afterヘッダーを返します。また、レート制限のルールは設定ファイルで管理し、APIエンドポイントごとに異なる制限を適用できるようにします。スケーラビリティのために、RedisのパイプラインやLuaスクリプトを使って原子性を確保します。

• システム設計数十億回のリダイレクトを処理するURL短縮サービスを設計してください。
  良い回答が押さえる点

  • 短縮キーの生成（Base62エンコード）
  • 読み取り最適化（CDN、Redisキャッシュ）
  • データベースシャーディング
  • 分析トラッキングの分離（非同期書き込み）
  • 障害耐性（リージョン間レプリケーション）

  サンプル回答を見る

  短縮URLのキーは、一意なIDをBase62でエンコードして生成します。IDは分散ID生成器（Snowflakeなど）で生成し、衝突を防ぎます。データベースにはリレーショナルDBを使用し、短縮キーにインデックスを張ります。リダイレクトは読み取りが圧倒的に多いので、CDN（CloudFrontなど）とRedisキャッシュを活用し、キャッシュヒット率を高めます。データベースはキーによるシャーディングを行い、書き込みは書き込み専用のレプリカに送ります。分析データ（クリック数など）は別のデータベース（Cassandraなど）に非同期で書き込み、パフォーマンスを分離します。また、短縮URLの有効期限やカスタムエイリアス機能も考慮します。障害耐性のために、リージョン間でのレプリケーションとフェイルオーバーを設計します。全体として、読み取りはCDN+Redisでほぼキャッシュヒットさせ、書き込みはキューイングしてバッチ処理することで、数十億のリダイレクトを処理可能にします。

• 行動面接解決に貢献した障害と、その後に変えたことを教えてください。
  良い回答が押さえる点

  • STARメソッドの適用
  • 具体的な障害：データベースコネクションリーク
  • 根本原因分析とコードレビュー
  • 監視の強化と自動テスト追加
  • デプロイプロセスの改善

  サンプル回答を見る

  私がバックエンドエンジニアとして携わったプロジェクトで、データベースのコネクションリークが原因で本番サービスが約30分間ダウンする障害が発生しました。状況としては、ECサイトの在庫管理システムで、新機能リリース後にコネクションが解放されないバグが混入しました。タスクは、原因を特定し、再発防止策を講じることでした。行動として、まずコネクションプールの監視を強化し、アプリケーションのコードレビューでコネクションの確実な解放を徹底しました。また、自動テストにコネクションリーク検出テストを追加し、ステージング環境でも負荷テストを実施するようにしました。結果として、その後同様の障害は発生せず、デプロイプロセスにゲートチェックが追加されました。この経験から、監視とテストの重要性を再認識し、チームに自動テストの文化を根付かせました。

• 行動面接難しいデータ整合性のトレードオフを迫られた経験を教えてください。
  良い回答が押さえる点

  • 一貫性と可用性のトレードオフ（CAP定理）
  • 分散在庫管理システムの具体例
  • 楽観的ロックと補償トランザクション
  • ビジネス要件との調整
  • 問題検知と復旧プロセスの整備

  サンプル回答を見る

  私が経験したトレードオフは、分散在庫管理システムにおいて、在庫数をリアルタイムで正確に保つことと、システムの可用性を両立させる必要があった場面です。ECサイトの販売イベント時に、在庫の残数を正確に管理したいが、トランザクションを強くするとデータベースがボトルネックになり、負荷が高まるとダウンするリスクがありました。そこで、強い一貫性を緩め、在庫の予約を楽観的ロックで行い、在庫超過が発生した場合は後で補償トランザクションで調整する方式を採用しました。具体的には、注文時に在庫をまず減少させ、在庫がマイナスになった場合は注文をキャンセルし、補償処理を行います。この結果、通常時は高い可用性を維持し、在庫誤差は許容範囲内に収まりました。このトレードオフはビジネス要件と相談して決め、問題が起きた際の検知と復旧プロセスも整備しました。

面接官が評価するポイント

準備の進め方

• 設計の前に前提と制約を述べる — 面接官は範囲設定を評価します。
• コーディングの回答では必ず時間計算量と空間計算量を分析しましょう。
• システム設計では会話を主導しましょう：要件、API、データモデル、スケール、障害モード。

よくある質問