Beginner Book

โหมดมืด

บทที่ 6 — Interview Strategy ​

← บทที่ 5 | สารบัญ

📌 สำหรับใครบ้าง — บทนี้เขียนตามมาตรฐาน Big Tech US (FAANG / Stripe / Coinbase ฯลฯ) ซึ่งใช้ rubric "Strong Hire / Hire / Lean Hire / No Hire" และเน้น whiteboard + back-of-envelope estimation ในเวลา 45-60 นาที — ถ้าคุณสมัครบริษัทไทย (Bank / Insurance / SCB Tech / KBTP / SCG ฯลฯ) รูปแบบมักต่างกัน: เน้นถาม design ระบบที่ทีมใช้จริง, ถาม trade-off เชิงปฏิบัติ และมักไม่มี rubric 4 ระดับชัดเจน — ใช้บทนี้เป็น "พื้นฐานทั่วไป" + ปรับตามบริษัทเป้าหมาย

🟢 มือใหม่ที่ยังไม่เคยทำ system-design interview สไตล์ US: บทนี้อาจรู้สึกแน่นและ jargon เยอะ ลองอ่านผ่าน ๆ รอบแรกเอา big picture ก่อน แล้วค่อยกลับมาเจาะแต่ละ section พร้อมฝึก mock interview จริงตามที่บอกใน § 15

📌 2026 trend: Big Tech interview เริ่มมีโจทย์ AI/LLM system design บ่อยขึ้น — design vector search, RAG architecture (Retrieval-Augmented Generation), LLM serving infrastructure, prompt caching — แนะนำให้คุ้นเคย concept จาก distributed-systems บทที่ 6 (LLM/AI infrastructure) ถ้าสมัคร AI-heavy company

ก่อนอ่าน — ต้องรู้อะไรมาก่อน? ​

บทนี้ต่อจาก บทที่ 0-5 — ควรเข้าใจ:

  • RADIO framework (บทที่ 0)
  • All scaling patterns (บทที่ 1-3)
  • Reliability patterns (บทที่ 4)
  • อย่างน้อย 3 worked examples จากบทที่ 5

หลังจบบท คุณจะ:

  • รู้วิธี approach system design interview
  • เข้าใจ scoring criteria ของ FAANG
  • หลีกเลี่ยง common mistakes
  • มี mock interview practice plan

1. Interview Format — รู้เกมก่อนเล่น ​

Length:    45-60 นาที
Format:    Whiteboard (in-person) หรือ online (Excalidraw — "เอ็กซ์-คา-ลิ-ดรอว์", เครื่องมือวาด whiteboard ออนไลน์ฟรี / Miro — "มิ-โร", เครื่องมือ whiteboard เชิงพาณิชย์)
Type:      Open-ended design problem

ตัวอย่าง prompt ที่เจอบ่อย ​

- "Design Twitter"
- "Design URL shortener"
- "Design Uber backend"
- "Design WhatsApp chat"
- "Design Netflix recommendations"
- "Design Google Drive"
- "Design Stripe-like payment"

Insight: ส่วนใหญ่เป็น "Design ระบบที่ใหญ่และดัง" — ฝึก 5-10 ระบบหลัก ก็พอ

2. สิ่งที่ Interviewer มองหา ​

ก่อนเตรียมตัว ต้องรู้ก่อนว่า interviewer ให้คะแนนอะไร — ไม่ใช่ "คำตอบที่ถูก" แต่เป็นวิธีคิด (methodical = เป็นขั้นเป็นตอน, ถามคำถาม), ความกว้าง+ลึกของความรู้, การสื่อสาร และ pragmatic judgment (เน้น practical ใช้งานจริง — ไม่ over-engineer = ไม่ออกแบบเกินจำเป็น) เข้าใจ 5 ข้อนี้แล้วจะรู้ว่าต้องโชว์อะไรในห้องสัมภาษณ์:

1. Problem-solving approach (วิธีแก้ปัญหา)
   - Methodical (เป็นขั้นเป็นตอน), ไม่ panic (ไม่ตื่นตูม)
   - Ask clarifying questions (ถามคำถามให้ชัด)
   - Break down complex into parts (แตกของซับซ้อนเป็นส่วน ๆ)

2. Technical breadth (ความรู้กว้าง)
   - รู้ multiple options (หลายทางเลือก)
   - เข้าใจ trade-offs (ข้อแลกข้อด้อย)

3. Technical depth (ความรู้ลึก — เมื่อถูก probe = เจาะถาม)
   - Drill into 1-2 parts (เจาะลึก 1-2 ส่วน)
   - Show real understanding (เข้าใจจริง ไม่ใช่ surface = ผิวเผิน)

4. Communication (การสื่อสาร)
   - Think aloud (คิดออกเสียง)
   - Engage in discussion (มีส่วนร่วม ไม่ใช่ตอบ one-way)
   - Listen to hints (ฟังคำใบ้ของ interviewer)

5. Pragmatic judgment (วิจารณญาณเชิงปฏิบัติ)
   - Don't over-engineer (ไม่ออกแบบเกินจำเป็น)
   - Match complexity to need (ความซับซ้อนต้องสมเหตุสมผลกับโจทย์)
   - Acknowledge what you don't know (ยอมรับสิ่งที่ไม่รู้)

3. Scoring Rubric (Big Tech Common) ​

📌 บริบทสำคัญ: ระบบ rubric "Strong Hire / Hire / Lean Hire / No Hire" เป็น มาตรฐานของ Big Tech US (Google, Meta, Amazon, Microsoft, Stripe, ฯลฯ) — บริษัทไทยส่วนใหญ่ (Bank / Insurance / SCG / PTT ฯลฯ) ใช้เกณฑ์ "ผ่าน / ไม่ผ่าน" แบบธรรมดา หรือ rubric ของบริษัทเอง ส่วนนี้สำหรับเตรียมตัวสมัครต่างประเทศหรือบริษัท US-style ในไทย (เช่น Agoda, LINE, Sea, Lazada)

interviewer ส่วนใหญ่ใน Big Tech ให้คะแนนตาม rubric 4 ระดับ (Strong Hire → No Hire) — รู้เกณฑ์นี้ช่วยให้เห็นว่าอะไรแยก "ผ่าน" ออกจาก "ตก" เช่น การระบุ trade-off และถามคำถามดี ๆ คือสิ่งที่ดึงคะแนนขึ้นจาก Hire เป็น Strong Hire:

Hiring Bar (each criterion):

Strong Hire (4):
✅ Clear architecture
✅ Addresses scale comprehensively
✅ Identifies trade-offs
✅ Knows multiple alternatives
✅ Asks great questions
✅ Handles ambiguity

Hire (3):
✅ Solid architecture
✅ Addresses basics
⚠️ Some trade-offs
⚠️ Few alternatives
⚠️ Some questions
⚠️ Some struggles

Lean Hire (2):
⚠️ Missing key components
⚠️ Misses scale
⚠️ Surface trade-offs
⚠️ Limited options
⚠️ Few questions

No Hire (1):
❌ Confused architecture
❌ No scale consideration
❌ No trade-offs
❌ Dive in too quick
❌ No questions

→ "Hire" = pass. "Lean Hire" = team debate. "No Hire" = reject.

4. Time Allocation (45 min) ​

interview มักมีแค่ 45 นาที การบริหารเวลาจึงสำคัญพอ ๆ กับเนื้อหา — แบ่งเวลาให้ครบทุกขั้น (clarify → estimate → high-level → deep dive → wrap up) อย่าหมดเวลาไปกับขั้นเดียว ตารางนี้คือ pacing ที่แนะนำ:

0-5 min:    Clarify requirements
5-10 min:   Estimate scale (back-of-envelope)
10-25 min:  High-level design (boxes + arrows)
25-40 min:  Deep dive (1-2 components)
40-45 min:  Wrap up + bottleneck discussion

Time-box yourself — ถ้า running long, interviewer จะ hint. ฟัง hint และปรับ pace

5. Step 1 — Clarify Requirements (Critical!) ​

ขั้นแรกและพลาดบ่อยสุด — อย่ารีบออกแบบ! ถามให้ชัดก่อนว่าโจทย์ต้องการอะไร (functional + non-functional + context) แล้ว "ทวนความเข้าใจ" ให้ interviewer ยืนยัน เพราะการสร้างระบบผิดตั้งแต่ต้น = เสียเวลาทั้งชั่วโมง ส่วนนี้รวมคำถามที่ควรถาม:

5.1 Questions to Ask ​

Functional:
- "What features are core vs nice-to-have?"
- "Multi-user หรือ single user?"
- "Auth needed?"
- "Mobile + web?"
- "What about edge cases?"

Non-functional:
- "What's the expected scale?"
- "Read/write ratio?"
- "Latency requirements?"
- "Availability target?"
- "Geographic distribution?"
- "Real-time หรือ eventual consistency?"

Context:
- "Greenfield หรือ existing system?"
- "Budget constraints?"
- "Time horizon?"
- "Team size?"

เขียน answer บน whiteboard — refer back later

5.2 Confirm Understanding (สำคัญ!) ​

"Let me confirm what I understood:
- Build URL shortener
- Public API + analytics
- 100M URLs/day, 1B redirects/day
- 99.9% availability
- 10-year URL retention
- Redirect p99 < 100ms

Did I miss anything?"

→ Avoid building wrong system → wasted time

6. Step 2 — Estimate Scale ​

6.1 ตัวเลขที่ต้องจำ ​

Time:
1 day = 86,400 sec ≈ 10^5
1 year = ~3 × 10^7 sec

Storage:
1 KB = 10^3 bytes
1 MB = 10^6
1 GB = 10^9
1 TB = 10^12
1 PB = 10^15

Reference scale (2026):
- Facebook DAU ~2B, Instagram ~2B, WhatsApp ~2B users
- Twitter/X DAU ~250-300M
- TikTok DAU ~1.5B
- Netflix subs ~270M (peak concurrent ~5-10M)
- Stripe ~thousands TPS sustained, ~50K peak Black Friday

6.2 Pattern คำนวณ ​

DAU = Daily Active Users = จำนวน user ที่ใช้งานในวันหนึ่ง ๆ (ตัวเลขมาตรฐานที่บริษัทใช้รายงาน scale เช่น "Facebook 2B DAU"). MAU = Monthly. สำหรับ system design interview ตัวเลขนี้คือจุดเริ่มของการประมาณ QPS ทั้งหมด

QPS (Queries Per Second — request ต่อวินาที):
   DAU × Actions per user per day / 86,400 = avg QPS
   avg × 5 = peak QPS    ← ดูคำอธิบาย "ทำไม 5x" ด้านล่าง

Storage:
   Events/day × bytes/event = storage/day
   × 365 × years = total storage

📌 ทำไม 5x ตอน peak? — เป็น heuristic (ค่าประมาณจากประสบการณ์ industry) — traffic จริงไม่กระจายเท่ากันตลอด 24 ชม. แต่กระจุกตัวช่วง prime time (เย็น-ค่ำ) และ event พิเศษ (Black Friday, ปีใหม่) — ค่าทั่วไปคือ peak ~3-5x ของ average ขึ้นกับประเภท app: app ที่ใช้ทั้งวัน (chat) peak ratio ต่ำ ~3x, app ที่ใช้เป็นช่วง (social, news) peak ratio สูง ~5-10x — ใน interview ใช้ "5x" เป็น default ที่ปลอดภัย

6.3 Example Calculation — Twitter ​

Given:
- 300M DAU (Daily Active Users)
- 2 tweets/user/day → 600M tweets/day
- Each tweet ~200 bytes

Write QPS (step-by-step):
- 600,000,000 tweets / 86,400 sec ≈ 6,944 → ~7,000/sec avg
- Peak: avg × 5 → ~35,000/sec   [heuristic — ดู § 6.2]

Storage (step-by-step):
- 600M tweets × 200 bytes = 120,000,000,000 bytes = 120 GB/day
- 120 GB × 365 = 43,800 GB/year ≈ 44 TB/year
- 44 TB × 5 years = ~220 TB
→ ต้อง sharded storage (เครื่องเดียวเก็บไม่ไหว)

Read QPS (step-by-step):
- 300M users × 100 tweets viewed/day = 30,000,000,000 views/day (30B)
- 30B / 86,400 sec ≈ 347,222 → ~350K/sec avg
- Peak: avg × ~4.3 → ~1.5M/sec (โจทย์ที่ scale นี้ peak ratio ต่ำลงเพราะ traffic เกลี่ยกว่า — บางสำนักใช้ 5x = 1.75M ก็ยอมรับได้)
→ Read-heavy! ต้อง cache

Numbers drive architectural decisions — ไม่ใช่เดา

7. Step 3 — High-Level Design ​

เคล็ดลับขั้นนี้คือ "เริ่มจากง่ายแล้วค่อยเติม" — วาด Client → Server → DB ก่อน แล้วเพิ่ม component ทีละชิ้นตาม requirement (scale→LB, read หนัก→cache, ไฟล์→object storage) ทำให้ interviewer เห็นวิธีคิดเป็นขั้น และได้ diagram ที่สะอาดอ่านง่าย:

7.1 Start Simple ​

[Client] → [Server] → [DB]

Then add per requirement:
- Scale → LB
- Multiple servers → stateless
- Heavy reads → cache
- Files → object storage
- Async work → queue
- Real-time → WebSocket
- Global → CDN

7.2 Components to Identify ​

1. Client (web / mobile / API)
2. Edge (CDN, DNS)
3. Load Balancer
4. API Gateway
5. App Server (stateless)
6. Cache (Redis)
7. Database (Postgres, NoSQL)
8. Object Storage (S3)
9. Queue (Kafka, SQS)
10. Worker
11. Search (Elasticsearch)
12. Analytics (BigQuery, ClickHouse)
13. ML Inference (TensorFlow Serving)

7.3 Draw Clear Diagram ​

✅ ทำ:
- Box per component
- Arrows show data flow
- Label every box
- Number for reference
- Group related (color, container)

❌ อย่า:
- Cluttered (กล่องเล็กมาก + ลูกศรเต็มไปหมด)
- Unclear flow direction
- Missing labels

8. Step 4 — Deep Dive ​

หลังวาดภาพรวมเสร็จ interviewer จะเจาะลึก 1-2 ส่วนเพื่อวัด "depth" ของคุณ — ต้องพร้อมลงรายละเอียดระดับ schema/code, เสนอทางเลือก และยอมรับ trade-off ส่วนนี้บอกว่าหัวข้อไหนที่มักถูก drill และต้องเตรียมอะไร:

Interviewer จะเลือก 1-2 ส่วน drill ลึก:

"Tell me more about the database design"
"How would you handle hot keys?"
"How does cache invalidation work?"
"What if region A goes down?"

Expect:

  • 15-20 min on chosen topic
  • Show real depth (schemas, code-level)
  • Discuss alternatives
  • Acknowledge trade-offs

8.1 Things to Be Ready to Deep Dive ​

1. Data model (schemas, indexes, sharding)
2. API design (endpoints, request/response)
3. Cache strategy (what, where, invalidation)
4. Bottleneck (scale specific component)
5. Reliability (failover, retry, idempotency)
6. Hot path optimization
7. Edge cases (race conditions, partial failure)
8. Security (auth, rate limit)

9. Step 5 — Identify Bottleneck + Scale ​

ขั้นนี้โชว์ว่าคุณคิดถึง scale จริง — ถามตัวเองว่า "ถ้า traffic 10x ส่วนไหนพังก่อน" แล้วเสนอวิธีแก้พร้อม trade-off การระบุ bottleneck ได้เอง(ก่อน interviewer ถาม) คือสัญญาณของ senior:

9.1 Question Yourself ​

"ถ้า 10x traffic — ส่วนไหนพังก่อน?"

Likely candidates:
- Database (write throughput)
- Specific endpoint (slow query)
- Cache size (memory limit)
- Network bandwidth
- ML inference latency

9.2 Pattern ตอบ ​

Identify → propose solution → discuss trade-off

ตัวอย่าง:
"DB write at 100K/sec จะ overload Postgres เดี่ยว
Solution: Shard by user_id (10 shards = 10K/sec each)
Trade-off: cross-shard queries ยาก, ต้อง 10 connections per app server"

10. Step 6 — Wrap Up ​

ปิดท้ายอย่างมืออาชีพ — สรุปสั้น ๆ ว่าออกแบบอะไร, trade-off หลักคืออะไร, และอนาคตจะปรับปรุงตรงไหน การ wrap up ที่ดีทำให้ interviewer จดจำ design ของคุณได้ชัดและเห็นว่าคุณมองภาพรวมออก:

"To summarize:
- I'd build [...] using [X, Y, Z]
- Key trade-offs are [...]
- Future improvements:
  - Multi-region (when going global)
  - ML for ranking
  - Stream processing for real-time analytics
- Bottlenecks to watch: [DB write, cache invalidation]"

Then: "Any questions you'd like me to dive deeper into?"

→ Sign-off professionally

11. Common Questions by Type ​

โจทย์ system design จัดกลุ่มได้ไม่กี่ประเภท และแต่ละประเภทมี "ความท้าทายเฉพาะ" ของมัน — รู้ว่าโจทย์ที่เจออยู่ในกลุ่มไหน (social, streaming, real-time, e-commerce, utility) ช่วยให้คุณดึง pattern ที่เกี่ยวข้องมาใช้ได้เร็ว ส่วนนี้แยก 5 กลุ่มพร้อมประเด็นหลักและโจทย์ฝึก:

11.1 Type A: Social App ​

Examples: Twitter, Facebook, Instagram

Key challenges:
- Feed generation (push/pull/hybrid)
- Graph (follower relationships)
- Search + ranking

Practice: Twitter, Instagram, Reddit, Threads

11.2 Type B: Streaming / Media ​

Examples: Netflix, YouTube, Spotify

Key challenges:
- CDN + adaptive bitrate
- Recommendation (ML)
- Massive content + global delivery

Practice: Netflix, YouTube, Twitch, TikTok

11.3 Type C: Real-time ​

Examples: WhatsApp, Discord, Uber, multiplayer game

Key challenges:
- WebSocket + connection scaling
- Presence + delivery
- Real-time matching (Uber)
- E2EE (WhatsApp)

Practice: WhatsApp, Slack, Uber, online game

11.4 Type D: E-commerce ​

Examples: Amazon, Shopify, Stripe

Key challenges:
- Catalog + search
- Cart + order
- Inventory + payment
- Recommendation

Practice: Amazon, eBay, Stripe, food delivery

11.5 Type E: Utility / Tool ​

Examples: URL shortener, password manager, Pastebin, Dropbox

Key challenges:
- Simple but scalable
- Storage cost optimization
- Hot/cold access pattern

Practice: TinyURL, Pastebin, Dropbox, GitHub Gists

12. Top Interview Questions (FAANG) ​

รวมโจทย์ system design ที่ถูกถามจริงใน FAANG จัดตามความถี่ — ฝึกกลุ่ม "very common" ให้คล่องก่อน (Twitter, URL shortener, Uber ฯลฯ) แล้วค่อยขยับไปกลุ่มที่เจอน้อยกว่า ใช้เป็นรายการเตรียมตัวก่อนสัมภาษณ์:

Very Common:
- Design Twitter / Instagram
- Design URL shortener
- Design Uber / Lyft
- Design WhatsApp / Discord
- Design Netflix / YouTube
- Design Google Drive / Dropbox

Common:
- Design Yelp (geo-search)
- Design TikTok (video feed + recommendation)
- Design Stripe (payment processing)
- Design Spotify
- Design rate limiter
- Design API gateway

Less Common (but possible):
- Design distributed file system (HDFS)
- Design Kafka
- Design DNS
- Design Elasticsearch
- Design Bitcoin / blockchain
- Design online judge (LeetCode)
- Design Google Calendar
- Design Tinder

Niche / Domain-specific:
- Design web crawler
- Design search engine
- Design ad serving (Google Ads)
- Design recommendation system
- Design game backend (Riot, Roblox)
- Design ML platform (training + serving)

13. Specific Tips ​

ระดับตำแหน่งที่สมัคร (mid/senior/staff) กำหนดว่า interviewer คาดหวัง depth แค่ไหน — junior เน้น basics, senior ต้อง deep dive + reliability + cost, staff ต้องคิดเชิงองค์กร ปรับ "ความลึก" ให้ตรงระดับเพื่อไม่ over/under deliver ส่วนนี้รวม tip เฉพาะแต่ละระดับ:

13.1 Calibrate Depth per Level ​

SDE I (entry):
- Not usually system design
- Focus: coding

SDE II / Mid (3-5 yr):
- 1 system design round
- Expected: solid basics
- Bar: address scale + clear trade-offs

Senior (5-8 yr):
- 1-2 system design rounds
- Expected: cross-functional knowledge
- Bar: deep dive + reliability + cost awareness

Staff (8+ yr):
- 2+ system design rounds
- Expected: holistic system thinking
- Bar: ambiguity, organizational design, scalability over time

Principal:
- Architecture review
- Bar: industry-level expertise

14. Online Whiteboard Tips ​

ปัจจุบัน interview ส่วนใหญ่เป็น online — การใช้ whiteboard tool ให้คล่อง (Excalidraw ฯลฯ) สำคัญพอ ๆ กับเนื้อหา เพราะถ้ามัวงมกับเครื่องมือจะเสียเวลาและดูไม่ smooth ฝึกวาด 5 ระบบบน tool ก่อนวันจริงจะช่วยมาก:

14.1 Tools ​

- Excalidraw ⭐ (most common — free)
- Miro
- CoderPad whiteboard
- Google Jamboard
- tldraw

14.2 Tips ​

- Practice before — be smooth with tool
- Use shapes consistently
- Group related (color-code)
- Have undo ready (Ctrl+Z)
- Save / screenshot

Before interview:
- Practice 5 designs on tool
- Be comfortable with keyboard shortcuts

15. Mock Interview ​

วิธีเตรียมตัวที่ได้ผลที่สุดคือ mock interview — ฝึกกับเพื่อน, แพลตฟอร์ม (Pramp/interviewing.io) หรือฝึกเองโดยจับเวลา 45 นาที พูดออกเสียง อัดวิดีโอแล้วรีวิว ทำสม่ำเสมอ 1-2 ครั้ง/สัปดาห์เป็นเวลา 4-6 สัปดาห์ก่อนสัมภาษณ์จริง:

15.1 Practice with ​

1. Peer (engineer friend)
2. Pramp.com (peer-to-peer, free)
3. Interviewing.io (paid, real interviewers)
4. Meetapro
5. Career coach

15.2 Frequency ​

- 1-2 mock per week for 4-6 weeks before interview
- Get feedback each time
- Track weakness → improve specific area

15.3 Self-Practice ​

- Pick problem
- Set 45 min timer
- Draw on whiteboard (no peeking at solution)
- Speak aloud as if interview
- Record video → review
- จด: what went well, what didn't

16. Common Mistakes — สิ่งที่ทำให้ interview fail ​

รวมความผิดพลาดที่ทำให้ตกสัมภาษณ์บ่อยสุด — กระโจนเข้า solution โดยไม่ถาม requirement, ข้ามการประมาณตัวเลข, over-engineer, พูดลอย ๆ (hand-wave) และลืม requirement ที่โจทย์ให้ แต่ละข้อมาคู่กับวิธีที่ถูกต้อง ดูไว้เพื่อไม่พลาดในห้องจริง:

16.1 ❌ Jump to Solution ​

Interviewer: "Design Twitter"
You: "OK, I'll use Postgres + Redis + Kafka + ..."

❌ ปัญหา: ไม่ถาม requirement → อาจออกแบบผิด

✅ ทางถูก:
You: "Before I design, let me understand the scope...
   - What features must we have?
   - What's the scale?
   - Any latency target?"

16.2 ❌ No Estimation ​

❌ Skip the numbers entirely
✅ "300M DAU × 2 tweets = 600M/day = 7K/sec avg, 35K peak"
   → numbers drive architecture

16.3 ❌ Over-engineer ​

❌ "Use Kafka, Cassandra, Kubernetes, microservices, blockchain"
   For "Design URL shortener" — way too much!

✅ Match complexity to actual need
   "Small scale → Postgres + Redis is fine"

16.4 ❌ Hand-wave ​

❌ "It scales horizontally"
   → How? Sharded by what? Hot key problem?

✅ "Shard tweets by user_id with consistent hashing.
   Celebrity tweets (>1M followers) handled separately.
   Use Redis for fanout cache..."

16.5 ❌ Miss Requirements ​

❌ Build amazing system but skip stated feature
✅ Re-read requirements during design
   "Did I cover all requirements? Let me check..."

16.6 ❌ No Trade-offs ​

❌ "I'll use Cassandra"
   → Why? Vs alternatives?

✅ "Cassandra: write-heavy, eventual consistency OK
   Alternative: DynamoDB (managed, more expensive)
   Picked Cassandra because [reason], but X is also reasonable"

16.7 ❌ Get Stuck ​

❌ 30 min on schema design, run out of time
✅ Time-box. If unsure, propose + move on
   "I'd use this schema, but we can refine later"

16.8 ❌ Wrong Pace ​

❌ Too fast → "we did URL shortener in 10 min, what next?"
❌ Too slow → only got to high-level by 40 min

✅ Pace yourself
   - Time-box each phase
   - Watch interviewer's body language

16.9 ❌ Defensive ​

❌ Interviewer suggests improvement, you defend
✅ "Good point. Yes, we can also...
   I picked X because... but Y is valid too"

16.10 ❌ Mute During Drawing ​

❌ Silent for 5 minutes while drawing
✅ Think aloud while drawing
   "I'm adding the cache here because read-heavy.
   For invalidation, we'll use TTL + explicit delete on write..."

17. Listen for Hints — สิ่งที่ interviewer พยายามบอก ​

interviewer มักไม่บอกตรง ๆ ว่าคุณพลาดอะไร แต่จะ "ใบ้" ผ่านคำถาม — เช่นถาม "hot key ล่ะ?" แปลว่าควรพูดเรื่อง hot key ตารางนี้แปลคำถามยอดฮิตเป็นสิ่งที่คุณควรทำ ฟัง hint แล้วปรับทันทีคือทักษะที่ดึงคะแนน:

Interviewer says:                You should:
"What about hot keys?"           → Address hot key problem
"What if 1 region fails?"        → Discuss multi-region
"Could this break?"              → Identify failure modes
"How would you monitor this?"    → Discuss observability
"What's the bottleneck?"         → Identify + propose solution
"What about security?"           → Discuss auth, encryption
"How does this fail gracefully?" → Talk about graceful degradation

Hints = areas you missed — ปรับเพื่อ address

18. Pre-Interview Prep (3-4 Weeks) ​

ถ้ามีเวลาเตรียม 3-4 สัปดาห์ นี่คือแผนที่ใช้ได้จริง — ไล่จาก fundamentals (สัปดาห์ 1) → component (2) → ออกแบบ 5 ระบบ (3) → mock interview (4) พร้อมเช็กลิสต์คืนก่อนและวันสัมภาษณ์ ทำตามนี้จะพร้อมแบบไม่ลนลาน:

Week 1: Fundamentals ​

- Read DDIA (chapters 1-4 minimum)
- ByteByteGo videos
- Practice estimation drills

Week 2: Components ​

- Database (SQL, NoSQL, sharding)
- Cache (Redis, CDN)
- Queue (Kafka, RabbitMQ)
- API patterns (REST, gRPC, WebSocket)

Week 3: Design 5+ Systems ​

- URL shortener
- Twitter
- Uber
- WhatsApp
- Netflix

Week 4: Mock Interviews ​

- 3-5 mocks
- Refine based on feedback
- Practice common questions

Night Before ​

✅ Sleep early
✅ Review your design template / framework
❌ Don't cram new material
❌ Don't try new tools

Prepare:
- Computer + 2nd monitor (whiteboard side)
- Water + paper handy
- Test camera + mic

Day Of ​

Morning:
- Eat well
- Light exercise
- Arrive/join Zoom early (10 min)

During:
✅ Think aloud
✅ Confirm understanding
✅ Pause when needed
✅ Ask clarifying questions

After:
✅ Thank interviewer
✅ Ask about their experience at company

19. Behavioral Questions (Follow-up) ​

หลังรอบ system design มักมีคำถาม behavioral ตามมา — เล่าระบบที่เคยออกแบบ, การตัดสินใจที่ยาก, ความขัดแย้งในทีม เตรียม STAR story (Situation/Task/Action/Result) ไว้ล่วงหน้าพร้อมตัวเลขผลลัพธ์จริง จะตอบได้กระชับและน่าเชื่อ:

System design มักตามด้วย behavioral:

"Tell me about a system you designed"
"Hardest tech decision you made?"
"How did you handle conflict with team?"
"Project failure — what learned?"

Prep — STAR Stories ​

Write 5-10 STAR stories:
- Situation
- Task
- Action
- Result

Tips:
- Numbers + concrete impact
- Show learning + growth
- Be honest about challenges

20. Junior → Senior Difference ​

สิ่งที่ interviewer คาดหวังต่างกันมากตามระดับ — junior แค่ต่อ cloud service ได้, mid เข้าใจ distributed basics, senior คิดระดับ architecture + cost + operation, staff คิดเชิงองค์กรและกลยุทธ์ระยะยาว รู้ว่าตัวเองสมัครระดับไหนแล้วโชว์ให้ตรง:

Junior:
- Use AWS / cloud services to glue together
- Don't deep into internals
- Acceptable: "use S3 for storage"

Mid:
- Understand basic distributed systems
- Discuss CAP, eventual consistency
- Trade-offs at component level

Senior:
- Architecture-level thinking
- Cost awareness ($$ implications)
- Operational concerns (monitoring, deploy, on-call)
- Multi-region, DR, compliance
- Lead team through design

Staff+:
- Holistic system + organization
- Long-term technical strategy
- Influence beyond own team
- Industry-level expertise

→ Calibrate depth to your level — Junior ไม่ต้องลึกเท่า Staff

21. Useful Phrases ​

คำพูดที่เตรียมไว้ช่วยให้สื่อสารลื่นและดูเป็นมืออาชีพในจังหวะสำคัญ — เปิดด้วยการถาม requirement, ระหว่างออกแบบให้ระบุ trade-off ชัด, ยอมรับเมื่อพลาด และปิดด้วยการสรุป ส่วนนี้รวมประโยคพร้อมใช้สำหรับแต่ละช่วงของ interview:

Opening ​

"Let me understand the requirements first..."
"What's the expected scale we should design for?"
"What are the must-have features vs nice-to-have?"

Designing ​

"Given X constraints, I'd choose Y because..."
"There's a trade-off here between A and B..."
"This component is the bottleneck — let me address that..."
"Let me draw this out..."

Acknowledging ​

"That's a great question. Let me think..."
"You're right, I missed [X]. Let me add..."
"I'm not 100% sure about [X], but my best guess is..."
"Let me reconsider..."

Wrapping ​

"To summarize..."
"Future improvements would include..."
"Other reasonable alternatives are..."
"Any aspects you'd like me to dive deeper into?"

22. Recovery from Mistake ​

Wrong design → realize mid-way

✅ "Hmm, looking at this again, I see a problem with [X].
   Let me adjust — actually a better approach is [Y]"

❌ Defend wrong design หรือ get flustered

→ Interviewer values willingness to update over rigid commitment

Lesson: ผิดได้ — แต่ต้อง recognize + correct. Senior engineer ทำผิดบ่อย แต่ recover เร็ว

23. Asking Interviewer (End of Interview) ​

ตอนท้าย interviewer มักเปิดให้ถามคำถาม — นี่เป็นโอกาสแสดงความสนใจจริงและประเมินบริษัท ถามเรื่องทีม/ความท้าทาย/on-call ได้ แต่อย่าถาม "ผมทำได้ดีไหม" หรือเรื่องเงินเดือน (เก็บไว้คุยกับ recruiter) ส่วนนี้แยกคำถามที่ดีกับที่ควรเลี่ยง:

✅ ดี:
"What's the team you're hiring for? What do they work on?"
"What's your favorite part about working here?"
"What's a recent technical challenge the team solved?"
"What's the next round in the process?"
"How does the team handle on-call?"

❌ อย่า:
"How did I do?" (น่ารำคาญ)
Generic questions you could Google
"What's the salary?" (เก็บไว้สำหรับ recruiter)

24. After Interview — Reflection ​

หลัง interview เสร็จ อย่าปล่อยให้ผ่านไปเฉย ๆ — ภายใน 1 ชั่วโมงให้จดว่าอะไรไปได้ดี อะไรติดขัด เพื่อปรับปรุงสำหรับครั้งหน้า แต่อย่าหมกมุ่นเล่นซ้ำทุกนาทีหรือพยายามเดาผล (คุมไม่ได้) ส่วนนี้แนะวิธี reflect ที่สร้างสรรค์:

Within 1 hour:
- Write down what went well
- What didn't
- Questions you struggled with
- New things you learned

Refine prep:
- Identify weak area
- Study before next interview

Don't:
- Replay every minute (anxiety)
- Predict outcome (you can't)

25. Mock Interview Script (Self-practice) ​

ถ้าหาคู่ซ้อมไม่ได้ ก็ฝึกเองได้ — เปิด Excalidraw, เลือกโจทย์, จับเวลา 45 นาที, อัดวิดีโอ แล้วพูดออกเสียงราวกับอยู่ในห้องสัมภาษณ์จริง จากนั้นดูวิดีโอย้อนหลังเพื่อหาจุดที่ติดขัด สคริปต์ด้านล่างช่วยจำลองบรรยากาศ:

Setup:
- Open Excalidraw
- Pick a problem (e.g., "Design Spotify")
- Set 45-min timer
- Record video (Loom, OBS)

Process (do alone):
1. "Today, let's design Spotify."
2. "Tell me what you understand and how you'd approach it."
3. (Speak as if interview)

(45 min later)

4. Watch replay:
   - Where did I freeze?
   - What was unclear?
   - What did I rush?

5. Self-feedback:
   - What you did well: [list]
   - What to improve: [list]
   - Score (1-4): [number]

Self-Review Checklist ​

Did you:
□ Ask clarifying questions?
□ Estimate scale?
□ Draw clear architecture?
□ Address scale + bottleneck?
□ Discuss trade-offs?
□ Mention real-world examples?
□ Communicate clearly throughout?
□ Stay within time?
□ Wrap up professionally?

26. Resources ​

รวมแหล่งเรียนต่อสำหรับเตรียม system design interview — หนังสือ (Alex Xu, DDIA), YouTube (ByteByteGo, Gaurav Sen), คอร์สออนไลน์, แพลตฟอร์มฝึก และ engineering blog เลือกตามสไตล์การเรียนของตัวเองและฝึกอย่างสม่ำเสมอ:

Books ​

- "System Design Interview Vol 1 + 2" (Alex Xu) ⭐ — must-read
- "Designing Data-Intensive Applications" (Kleppmann) — deeper
- "Building Microservices" (Newman) — architecture
- "The Pragmatic Engineer" newsletter (Gergely Orosz)

YouTube ​

- ByteByteGo — Alex Xu's channel ⭐
- Gaurav Sen — deep dives
- Tech Dummies — varied
- System Design Interview — examples
- Hussein Nasser — DB + protocols deep dive

Online Courses ​

- educative.io: "Grokking the System Design Interview" ⭐
- AlgoExpert: "SystemsExpert"
- Coursera: "Cloud Computing Specialization"

Practice Platforms ​

- pramp.com (free, peer-to-peer)
- interviewing.io (paid, real interviewers)
- meetapro
- TechMockInterview

Blog / Newsletter ​

- High Scalability (classic)
- ByteByteGo newsletter
- The Pragmatic Engineer (Gergely Orosz)
- Engineering blogs (Uber, Stripe, Netflix, Discord, Cloudflare)

27. Final Checklist — Are You Ready? ​

ก่อนเข้าห้องสัมภาษณ์ ลองเช็กความพร้อมด้วยคำถามเหล่านี้ — ถ้าอธิบาย CAP, sharding, cache strategy, RADIO ฯลฯ ได้คล่องทุกข้อ แสดงว่าพร้อม ข้อไหนยังตอบไม่ได้ก็กลับไปทบทวนบทนั้นก่อน:

Before interview, can you:

✅ Explain CAP theorem in 2 minutes?
✅ Describe difference: SQL vs NoSQL?
✅ Compare: sync vs async communication?
✅ Estimate: storage for 100M users with 10 KB/user?
✅ Design: rate limiter algorithm?
✅ Describe: cache strategy (write-through, cache-aside)?
✅ Explain: sharding by user_id vs by id?
✅ Discuss: REST vs GraphQL vs gRPC?
✅ Identify bottleneck in 5 different architectures?
✅ Apply RADIO to any problem?
✅ Talk about idempotency + retry?
✅ Discuss circuit breaker?
✅ Explain consistent hashing?

→ All yes? You're ready.

→ Some no? Review specific topic + practice

28. Confidence Tips ​

Imposter syndrome is common — especially before FAANG interview.

Truth:
- Interviewer WANTS you to succeed (hiring is hard for them too)
- "I don't know but here's how I'd find out" = acceptable
- Multiple valid solutions exist (no "right" answer)
- Trade-offs > one "right" answer

Mindset:
✅ "I have experience. Let me share my thinking."
✅ "I'll figure it out as I go — collaborate with interviewer."

❌ "I must know everything"
❌ "Any uncertainty = failure"

Reality: คนที่ผ่าน FAANG ส่วนใหญ่ไม่ได้รู้ทุกอย่าง — รู้พื้นฐานดี + communicate ดี

29. Negotiation (After Offer) ​

ได้ offer แล้วไม่ได้แปลว่าจบ — การต่อรองเป็นเรื่องปกติและคาดหวังได้ (ไม่หยาบคาย) ควรเข้าใจองค์ประกอบ comp ทั้งหมด (base, bonus, equity, sign-on), เทียบกับ levels.fyi และเสนอตัวเลขเฉพาะเจาะจง ส่วนนี้สรุปวิธีต่อรองอย่างมืออาชีพ:

ได้ offer? อย่า accept first number!

Compensation components:
- Base salary
- Annual bonus (10-20%)
- Equity / RSU (vest over 4 years)
- Sign-on bonus
- Relocation, other

Ask recruiter:
- "Can you walk me through the comp package?"
- "What's the total compensation over 4 years?"
- Compare with: levels.fyi, Glassdoor

Negotiate:
- "I have another offer at $X total comp" (if true)
- "I was hoping for $Y given my experience"
- Specific number > vague request

After 1-2 rounds:
- Accept หรือ politely decline
- Don't drag on

→ Negotiation = expected, ไม่ rude

30. Real Interview Story (Anonymized) ​

"I had system design interview at FAANG for senior role.

Question: Design Yelp-like service (restaurant reviews + geo-search)

What I did right:
✅ Asked clarifying questions (scale, features)
✅ Drew high-level architecture quickly
✅ Discussed geo-spatial indexing (geohash, S2, H3)
✅ Talked about caching popular searches
✅ Mentioned real examples (Foursquare uses S2)

What I struggled with:
❌ Got stuck on review schema design (10 min on something not asked)
❌ Didn't address abuse (fake reviews)
❌ Forgot to mention monitoring/alerts

Feedback:
- Strong technical depth (especially geo)
- Time management could improve
- Discuss operational concerns more

Result: Got senior offer (Hire). Some interviewers wanted Strong Hire."

Lesson: ไม่ต้อง perfect — แค่ "Hire" บางส่วน + กลาง ๆ ที่เหลือ ก็พอ

31. Checkpoint — ฝึกทำเอง ​

🛠️ Checkpoint 6.1 — Self-Diagnose
Rate yourself 1-4 ในแต่ละมิติ:

  • Requirements gathering
  • Scale estimation
  • Architecture drawing
  • Deep dive depth
  • Trade-off discussion
  • Time management
  • Communication

→ Focus practice on lowest scores

🛠️ Checkpoint 6.2 — Mock Schedule
3-4 weeks ก่อน real interview:

  • Week 1: 2 mocks
  • Week 2: 3 mocks
  • Week 3: 3 mocks
  • Week 4: 1-2 mocks + light practice

🛠️ Checkpoint 6.3 — Question Bank
Build:

  • 10 system design questions
  • Practice once each (45 min)
  • Refine answers
  • จด pattern ที่ใช้ซ้ำ ๆ

🛠️ Checkpoint 6.4 — Time-box Practice
Pick problem:

  • Set 45 min timer
  • Don't pause
  • Review สิ่งที่ covered

🛠️ Checkpoint 6.5 — Record + Review
Video yourself doing mock:

  • Watch back
  • จด "ums", silences, awkward phrasing
  • Iterate

32. สรุปบท ​

ทบทวนกลยุทธ์ทั้งบท — interview เป็นการวัด "วิธีคิด+สื่อสาร" ไม่ใช่คำตอบที่ถูก ทำตาม process (clarify → estimate → design → deep dive → wrap up), ฟัง hint, ฝึก mock เยอะ ๆ และเชื่อมั่นในตัวเอง เช็กลิสต์นี้คือสิ่งที่ต้องทำให้ติดเป็นนิสัยก่อนเข้าห้องจริง:

✅ Interview format: 45-60 min, open design problem
✅ Process: Requirements → Estimate → Architecture → Deep dive → Bottleneck → Wrap up
✅ Always clarify requirements first — ไม่ skip
✅ Estimate scale — drives architecture decisions
✅ Draw clear architecture, think aloud
✅ Discuss trade-offs — multiple options, ไม่ใช่ "right answer" เดียว
✅ Address bottleneck + scale strategy
✅ Wrap up: summary + future + invite questions
✅ Avoid: jump to solution, no estimation, over-engineer, hand-wave, miss requirements
✅ Listen for hints — pivot to address
✅ Practice: 5+ mocks ก่อน real — Pramp, peer, paid coach
✅ Resources: Alex Xu books, ByteByteGo, DDIA
✅ Confidence + calm > knowing everything

🎉 จบ System Design Book! ​

หลังจบบทที่ 0-6 คุณมี:

✅ System design mindset
✅ Scalability patterns
✅ Data layer strategies
✅ Communication patterns
✅ Reliability + resilience
✅ 5 worked examples (Twitter, Uber, Netflix, WhatsApp, URL shortener)
✅ Interview strategy

หัวข้อต่อยอด ​

ทำอะไรดูที่ไหน
Distributed Systems bookCAP, consensus (Raft, Paxos), event sourcing — go deeper
Microservices patternsSaga, event sourcing, CQRS deep dive
Domain-Driven DesignBounded context, aggregate, repository
Site Reliability EngineeringSLO/SLI deep, error budget, incident management
Cloud architectureAWS / GCP well-architected framework
Compliance + security at scalePCI, SOC 2, GDPR architecture
Real practitioner blogsSubscribe to Pragmatic Engineer, etc.

เส้นทางต่อ ​

1. Apply patterns ในงานจริง
2. Design system จริงในที่ทำงาน — ขออาสาทำ
3. Read engineering blogs ทุกสัปดาห์
4. Mock interview กับ peer หรือ paid
5. ติดตาม trend ใหม่ (vector DB, edge compute, serverless)

คำศัพท์เพิ่ม ​

คำศัพท์ความหมาย
RADIORequirements, Architecture, Data, Interface, Optimization
WhiteboardOnline drawing tool ใน interview
STARSituation, Task, Action, Result (behavioral)
Hiring barThreshold pass/fail (Strong Hire / Hire / Lean / No Hire)
Mock interviewPractice interview กับเพื่อน หรือ paid
Levels.fyiSalary research site
PrampFree peer interview platform
interviewing.ioPaid mock interview
TC (Total Compensation)Base + Bonus + Equity (4-year)
Sign-on bonusOne-time bonus at signing
RSURestricted Stock Units (equity)

← บทที่ 5 | ← สารบัญ System Design | ← สารบัญหลัก