2026年の今、Google のシニア SRE 面接に「LeetCode をひたすら解けば受かる」という時代は終わった。本記事は韓国エンジニアコミュニティでバズったツイートとその英語スレッドをもとに、2026年版の攻略ポイントをまとめたものだ。
元ツイートの要旨：
“2026年には、アルゴリズムパズルよりも「5PB のデータを 10Gbps で転送したら 46 日かかる」をすぐに暗算できる物理的感覚がはるかに重要。図を描く前に暗算をして、障害時は原因分析より先にシステムを安定化させる習慣が身についていないといけない。コーディングテストも連結リストの逆転ではなく、限られたメモリで数十 GB のログを処理する実践的な問題に変わっている。”
1. NALSD ラウンドは「アーキテクチャ」ではなく「物理」
NALSD（Non-Abstract Large Systems Design）ラウンドで最も多い失敗は、まず図を描いてしまうことだ。
典型的な落とし穴：
- 問題: 「4 時間 SLA で 5PB クラスターの DR を設計してください」
- NG 回答: きれいな active-passive 構成図を描く → 即アウト
なぜ即アウトか：
5 PB = 5 × 10^15 bytes
10 Gbps = 10 × 10^9 bps = 1.25 × 10^9 bytes/sec
転送時間 = 5 × 10^15 / 1.25 × 10^9 = 4,000,000 秒 ≈ 46 日これを暗算で弾ければ「この要件では 4 時間 SLA は物理的に不可能」とわかる。図を描く前に数字を出すのがシニア SRE の姿勢だ。
Jeff Dean のレイテンシ数値（Numbers Everyone Should Know）も丸暗記しておくこと。NALSD の問い方次第でそのまま使う場面がある。
2. 障害対応は「原因分析」より「ミティゲーション優先」
面接官が「EU リージョンの p99 レイテンシが 200ms → 800ms に急増、エラーは出ていない」と問うたとする。
- 弱い回答: すぐ原因を掘り始める
- 強い回答: まず安定化、その後に調査
「まず EU のトラフィックを部分的に他リージョンへフェイルオーバーします。
SLO を確認 — エラーバジェットは何%残っていますか？
安定化したら原因調査に入ります。」採点されているのは知識量ではなく 判断力。障害発生時に「エラーバジェットをどれだけ消費したか」をすぐ意識できるかが問われている。
3. コーディングラウンドは「本番を想定した実装」
2026 年のコーディング問題は競プロではなく、本番環境の制約を前提とした問題に移行している。
よくある出題例：
-
512MB RAM で 50GB のログをパース
→ 全量ロードは NG。ストリーミング I/O で行単位処理が正解 -
レート制限とタイムアウト付きの並列フェッチャー
→goroutine+semaphore+context.WithTimeoutのようなパターン
// 512MB RAM で 50GB ログを処理する例（Go）
scanner := bufio.NewScanner(file)
scanner.Buffer(make([]byte, 64*1024), 1024*1024) // 初期 64KB、最大 1MB（長い行に対応）
for scanner.Scan() {
line := scanner.Text()
process(line) // 1行ずつ処理
}「コンテストのトリック」ではなく「本番で安全に動くコード」を書けるかが採点基準だ。
4. Linux の深い知識は必須
「htop を使います」という回答は死亡フラグ。面接官が求めるのは コマンド → 意図 → シグナル の三段論法だ。
頻出トピック：
| トピック | 期待される回答レベル |
|---|---|
| メモリ回収（memory reclaim under pressure） | kswapd、oom-killer、vm.swappiness の関係 |
| TCP 再送スパイク（パケットロスなし） | ss -s、/proc/net/snmp、tcp_retrans_collapse |
ps のプロセス状態 | D（uninterruptible sleep）が何を意味するか |
# TCP 再送を確認する例
ss -s
cat /proc/net/snmp | grep -E "^Tcp"
# RetransSegs の増加を追う5. SRE の語彙をネイティブに話す
行動面接（behavioral round）では、SRE 用語を自然に使えるかが差になる。
| NG ワード | SRE ワード |
|---|---|
| ops / オペレーション | toil（トイル） |
| 問題が起きた | error budget を消費した |
| 影響範囲 | blast radius |
| 反省会 | blameless postmortem |
「ops」と言うだけで「SRE の文化を理解していない」と判断されることがある。
まとめ：2026年版攻略チェックリスト
- 大規模システムの物理計算（帯域・時間・ストレージ）を暗算できる
- Jeff Dean のレイテンシ数値を覚えている
- 障害対応はミティゲーション → 原因調査の順番が体に染み込んでいる
- 本番制約付きのコーディング（ストリーミング処理、並行制御）を書ける
- Linux のカーネル動作を
htop以外のコマンドで説明できる - エラーバジェット・ブラストラジアス・toil を自然に使える
Google 公式の NALSD 章（SRE Workbook: Non-Abstract Large System Design）は必読だ。モック面接を 8〜10 回こなして、プレッシャー下での思考の順序を鍛えておくことが最大の近道だ。