Phỏng vấn senior khó vì câu trả lời thường không phải một fact hay một thuật toán. Interviewer muốn biết bạn ra quyết định thế nào khi requirement chưa đầy đủ, trình bày trade-off ra sao, và bạn có làm hệ thống cũng như những người xung quanh tốt hơn không. Bài này đi qua ba nhóm: nền tảng junior, trade-off ở mid-level, và design cùng khả năng dẫn dắt incident ở senior.
Cách đọc ví dụ: phần hướng dẫn là [ANALYSIS]. Mọi metric hoặc kết quả cá nhân trong dấu ngoặc kép đều là [ILLUSTRATIVE ASSUMPTION], không phải claim về một công ty hay hệ thống cụ thể. Hãy thay chúng bằng bằng chứng từ công việc của bạn. Một câu trả lời tốt giải thích quyết định, alternative bị loại, kết quả và guard ngăn lỗi tái diễn.
Junior: nền tảng
Q1. “Tell me about yourself.” Làm sao trả lời gọn?
[ANALYSIS] Dùng cấu trúc ba phần ngắn: scope và stack hiện tại, một outcome gần đây, và vì sao role này phù hợp. [ILLUSTRATIVE ASSUMPTION] “Tôi làm Java service và quan tâm đến reliability. Tôi giảm p99 của một service từ 800 ms xuống 120 ms. Role này phù hợp với các bài toán distributed system tôi muốn giải.” Tránh kể tiểu sử. Hãy mô tả problem bạn giải quyết, không phải mọi công nghệ từng chạm.
Q2. “Điểm yếu lớn nhất của bạn là gì?”
[ANALYSIS] Chọn một điểm yếu thật nhưng có thể kiểm soát, rồi nói về process giúp giảm tác động của nó. [ILLUSTRATIVE ASSUMPTION] “Tôi từng underestimate rủi ro migration. Hai trong năm release đầu bị rollback, nên giờ tôi prototype đường rủi ro trước; bốn migration gần nhất không rollback.” Đừng dùng một điểm mạnh giả dạng điểm yếu như “tôi làm việc quá chăm chỉ”.
Q3. “Bạn thấy mình ở đâu sau 5 năm?”
[ANALYSIS] Nói về scope và judgment thay vì title. [ILLUSTRATIVE ASSUMPTION] “Tôi muốn own các quyết định kiến trúc khó, dẫn một lần scale-up 10x mà vẫn giữ p99 dưới 200 ms, và mentor bốn engineer đạt scope tương tự.” Trọng tâm là leverage, không phải danh sách promotion.
Q4. “Vì sao bạn muốn công việc này?”
[ANALYSIS] Gắn role với problem domain, scale hoặc cách team làm việc mà bạn đã xác minh. Nếu không có một con số công khai đáng tin, đừng tự tạo ra. [ILLUSTRATIVE ASSUMPTION] “Domain payments cho tôi cơ hội đào sâu distributed consistency.” Nêu hai fact đã kiểm tra và giải thích vì sao chúng quan trọng với bạn.
Q5. “Hãy mô tả một bug bạn đã sửa.”
[ANALYSIS] Đi theo symptom, reproduction, root cause, fix và guard. [ILLUSTRATIVE ASSUMPTION] “Một lỗi cache làm p99 tăng từ 120 ms lên 800 ms. Stress test 200 dòng reproduce được lỗi; nguyên nhân là thiếu giới hạn expireAfterWrite. Tôi sửa, thêm alert kích thước cache, và p99 giữ dưới 130 ms trong sáu tháng.” Kết thúc bằng regression test, alert hoặc invariant bảo vệ fix.
Q6. “Bạn làm gì khi bị mắc kẹt?”
[ANALYSIS] Dùng quy trình escalation lặp lại được: timebox để tạo minimal reproduction, isolate biến bằng bisect hoặc đơn giản hóa, đọc error và source thật, rồi hỏi một câu cụ thể kèm bằng chứng. [ILLUSTRATIVE ASSUMPTION] “Tôi thử ba lần, mỗi lần 15 phút, rồi gửi minimal reproduction; phần lớn blocker được trả lời trong 10 phút.” Điều quan trọng là process, không phải ngưỡng cố định.
Q7. “90 ngày đầu trong role này sẽ thế nào?”
[ANALYSIS] Đưa ra milestone. [ILLUSTRATIVE ASSUMPTION] Trong 30 ngày đầu, đọc codebase, on-call rotation và hai incident review, sau đó deploy một thay đổi rủi ro thấp. Từ ngày 30 đến 60, shadow production traffic và sửa một bug tầm trung. Từ ngày 60 đến 90, own một feature end-to-end. Đừng chỉ nói “học stack”.
Q8. “Khi nào nên nhờ giúp đỡ?”
[ANALYSIS] Hỏi trước khi blocker trở nên đắt, nhưng phải mang theo bằng chứng. [ILLUSTRATIVE ASSUMPTION] Dành 15 phút tự thử, ghi lại điều thất bại, rồi hỏi một câu tập trung kèm reproduction ngắn. Một câu hỏi tốt có thể biến một giờ bế tắc thành 10 phút hướng dẫn.
Q9. “Ownership một bug nghĩa là gì?”
[ANALYSIS] Ownership gồm reproduction, remediation, bảo vệ khỏi regression và communication. [ILLUSTRATIVE ASSUMPTION] Một bug làm hỏng dữ liệu có thể mất sáu giờ để sửa và thêm hai giờ viết regression test, alert; công việc chỉ xong khi class bug đó được ngăn chặn, không phải khi ticket rời queue.
Q10. “Nói ‘I don’t know’ thế nào?”
[ANALYSIS] Nói thẳng, sau đó đưa verification plan và hypothesis có giới hạn. [ILLUSTRATIVE ASSUMPTION] “Tôi không nhớ điều đó từ đầu. Tôi sẽ kiểm tra X; ước lượng ban đầu là Y và sẽ verify trong 30 phút.” Đừng bluff.
Q11. “Một comment trong code review tốt là gì?”
[ANALYSIS] Comment tốt truyền đạt kiến thức hoặc chỉ ra risk. Hỏi thay vì viết lại code: “Vì sao map này không có giới hạn?” [ILLUSTRATIVE ASSUMPTION] Giữ review dưới 400 dòng, giới hạn 3–5 comment substantive và đo xem thời gian review có cải thiện không. Review là cơ chế dạy, không phải output của linter.
Q12. “Bạn viết bao nhiêu test?”
[ANALYSIS] Phân bổ test theo risk, không dùng một target coverage cho mọi code. [ILLUSTRATIVE ASSUMPTION] Money path có thể cần 100% branch coverage, core logic khoảng 80% unit coverage và mỗi critical flow một integration test; boilerplate có thể khoảng 20%. Coverage là risk budget.
Q13. “Bạn học một codebase lạ thế nào?”
[ANALYSIS] Trace một request từ entry point qua service layer, data layer đến response trước khi sửa code. [ILLUSTRATIVE ASSUMPTION] Theo một flow nhỏ mà user nhìn thấy qua 5–6 layer, vẽ map một trang và xác định 2–3 file rủi ro cao. Đọc cả test; chúng thường là documentation chính xác nhất.
Q14. “Bạn log gì và alert gì?”
[ANALYSIS] Log request ID, duration, error class và business value liên quan ở level phù hợp. Alert trên symptom người dùng thấy, không phải mọi cause có thể xảy ra. [ILLUSTRATIVE ASSUMPTION] Alert có thể fire khi error rate vượt 1% hoặc p99 vượt 300 ms trong năm phút. Hãy review alert noise và giữ signal actionable.
Q15. “Làm sao giữ commit dễ review?”
[ANALYSIS] Mỗi commit nên nhỏ, một mục đích và có subject rõ. [ILLUSTRATIVE ASSUMPTION] Một refactor 900 dòng có thể tách thành sáu commit có ranh giới hợp lý, mỗi commit dưới 200 dòng thay đổi khi khả thi. History dễ đọc giúp reviewer hiểu intent.
Q16. “Bạn estimate task thế nào?”
[ANALYSIS] Chia nhỏ công việc, estimate riêng bước rủi ro nhất và nêu confidence cùng dependency. [ILLUSTRATIVE ASSUMPTION] Bốn bước có thể tổng cộng năm ngày với biên độ một ngày, gồm hai ngày migration và một ngày cho rollback. Estimate không phải lời hứa không có assumption.
Q17. “Hãy kể một sai lầm.”
[ANALYSIS] Chọn sai lầm thật, nhận outcome và cho thấy thay đổi bền vững. [ILLUSTRATIVE ASSUMPTION] Một migration không có rollback đã làm hỏng 1.000 row và cần ba giờ khôi phục; sau đó postmortem và rollback được test cho 12 migration tiếp theo. Đừng đổ lỗi cho deploy system hay deadline.
Mid-level: trade-off và execution
Q18. “Mọi thứ đều urgent thì ưu tiên thế nào?”
[ANALYSIS] So sánh impact, số user bị ảnh hưởng và reversibility, rồi công bố thứ tự. [ILLUSTRATIVE ASSUMPTION] Lỗi hỏng dữ liệu ảnh hưởng 2 triệu user cao hơn UI cosmetic; thay đổi config reversible cao hơn thao tác xóa không thể đảo ngược. Dùng bucket như hôm nay, tuần này và sau đó.
Q19. “Bạn xử lý technical debt thế nào?”
[ANALYSIS] Làm debt visible, có owner, có budget và gắn với code đang được chạm. [ILLUSTRATIVE ASSUMPTION] Team có thể dành 20% capacity, xử lý năm hotspot trong một quý và giảm thời gian fix bug trung bình từ hai ngày xuống một. Allocation thật phụ thuộc team.
Q20. “Kể về bất đồng với đồng nghiệp.”
[ANALYSIS] Cho thấy bạn lắng nghe, tranh luận bằng evidence và commit sau khi quyết định. [ILLUSTRATIVE ASSUMPTION] Benchmark ở 1.000 message/giây với hai worker có thể cho thấy một queue library giữ p99 dưới 50 ms còn library kia lên 200 ms; bạn vẫn có thể dùng retry design của đồng nghiệp. Đừng kể như câu chuyện thắng-thua.
Q21. “Requirement mơ hồ hoặc thay đổi thì làm gì?”
[ANALYSIS] Viết các cách hiểu có thể có, chọn slice rẻ hơn để đảo ngược, ship rồi học. [ILLUSTRATIVE ASSUMPTION] Bản mỏng có thể ship trong ba ngày và cho thấy cách hiểu ban đầu sai, tránh hai tuần rework. Mục tiêu là tốc độ học.
Q22. “Quyết định kỹ thuật nào khiến bạn tiếc?”
[ANALYSIS] Giải thích bạn từng tin gì, evidence nào làm đổi quan điểm và hiện tại bạn làm khác ra sao. [ILLUSTRATIVE ASSUMPTION] Bốn lớp abstraction được dựng cho flexibility không dùng đến có thể mất ba tuần rồi bị gỡ. Ưu tiên design đơn giản nhất đáp ứng requirement hiện tại; chỉ thêm seam khi có nhu cầu thật.
Q23. “Cân bằng delivery và sức khỏe dài hạn thế nào?”
[ANALYSIS] Làm shortcut rõ ràng, có giới hạn và có follow-up. [ILLUSTRATIVE ASSUMPTION] Ship 80% để có thêm hai tuần runway, rồi schedule 20% còn lại trong một tháng. Shortcut không owner và deadline là debt không được quản lý.
Q24. “Stakeholder muốn feature hai tuần trong một tuần.”
[ANALYSIS] Đưa trade-off table: full scope trong hai tuần, reduced scope trong một tuần, hoặc full scope kèm risk reliability rõ ràng. [ILLUSTRATIVE ASSUMPTION] Slice 70% có thể vừa một tuần; full scope có thể thêm hai ngày incident debt và 40% bug risk ước tính. Để stakeholder chọn cái giá.
Q25. “Kể về một lần bạn mentor ai đó.”
[ANALYSIS] Cho thấy capability của người kia tăng, không phải bạn đã làm việc thay họ. [ILLUSTRATIVE ASSUMPTION] Pair hai giờ mỗi tuần trong ba tháng, để engineer own ba PR đầu của mỗi feature, rồi đo review cycle từ bốn ngày xuống một ngày. Dùng outcome thật của người được mentor.
Q26. “Delegate việc bạn làm nhanh hơn thế nào?”
[ANALYSIS] Delegate khi giá trị học hỏi và capacity tương lai lớn hơn chi phí ngắn hạn. [ILLUSTRATIVE ASSUMPTION] Người đạt 80% chất lượng của bạn trong thời gian bạn cần để làm 100% có thể là owner phù hợp. Review kết quả nhưng đừng giành việc lại, nếu không bạn vẫn là bottleneck.
Q27. “Biết sẽ trễ deadline thì làm gì?”
[ANALYSIS] Báo ngay khi biết risk và đưa ra lựa chọn. [ILLUSTRATIVE ASSUMPTION] Ở ngày thứ tám của kế hoạch 15 ngày, bạn có thể đề xuất bỏ analytics hoặc dời ngày một tuần. Thông tin sớm giữ lại lựa chọn; thông tin muộn làm mất lựa chọn.
Q28. “Nói không với request thế nào?”
[ANALYSIS] Giữ mục tiêu, nói rõ constraint và chỉ ra thứ phải dời. [ILLUSTRATIVE ASSUMPTION] “Mục tiêu này cần X, queue đã đầy ba tuần; item nào nên trượt?” Một câu no có lý là một phần của planning đáng tin cậy.
Q29. “Cân bằng process và output ra sao?”
[ANALYSIS] Giữ process thật sự giảm risk hoặc waste; bỏ process không tạo giá trị. [ILLUSTRATIVE ASSUMPTION] Deploy checklist có thể giảm rollback từ tám mỗi quý xuống một, trong khi rút stand-up 30 phút xuống 10 phút vẫn giữ đủ thông tin. Review ceremony định kỳ.
Q30. “Bạn xử lý rework thế nào?”
[ANALYSIS] Xem rework là signal của một bước bị thiếu ở trước đó. [ILLUSTRATIVE ASSUMPTION] Nếu 15% công việc bị làm lại và 80% bắt nguồn từ requirement mơ hồ, spec một trang trước khi code có thể giảm rework xuống 4%. Sửa requirement hoặc architecture trước khi đòi hỏi tốc độ.
Q31. “Cách tiếp cận monitoring và alerting của bạn?”
[ANALYSIS] Thiết kế alert actionable, symptom rõ và runbook cho mỗi page. [ILLUSTRATIVE ASSUMPTION] Gộp 40 alert thành tám alert dựa trên SLO có thể giảm page 70%. Alert fatigue là một operational defect.
Q32. “Bạn document decision thế nào?”
[ANALYSIS] Viết ADR khi quyết định được đưa ra: context, alternatives, constraint, evidence và consequence. [ILLUSTRATIVE ASSUMPTION] ADR một trang có thể so sánh hai option, trong đó một option tốn hơn 30% CPU nhưng giữ p99 dưới 200 ms. Document tại sao, không chỉ cái gì.
Q33. “Feature mất ba tuần nhưng user không cần thì sao?”
[ANALYSIS] Nhận miss, dừng đầu tư thêm và thay đổi cách validate. [ILLUSTRATIVE ASSUMPTION] Nếu chỉ 0,1% user dùng reporting page, hãy bỏ nó và thêm năm user interview trước các build sau. Bài học chỉ có giá trị khi workflow thay đổi.
Q34. “Làm sao tránh burnout?”
[ANALYSIS] Xem sustainable pace là một control của reliability. [ILLUSTRATIVE ASSUMPTION] Sau một tháng nhiều incident, giảm planned work 30% hoặc kéo sprint từ hai tuần thành ba; output có thể giữ nguyên nếu hotfix và rework giảm. Đừng coi làm thêm giờ là capacity plan.
Senior: design, incident và leverage
Q35. “Mô tả một production incident bạn dẫn dắt.”
[ANALYSIS] Đưa timeline: detection, containment, root cause, durable fix và follow-up. [ILLUSTRATIVE ASSUMPTION] Lúc 02:10, p99 là 800 ms và error 12%; trong 10 phút rollback và shed 30% traffic. Đến 03:00 xác định cache không giới hạn; bounded Caffeine cache cap 10.000 entry cùng alert kích thước đưa p99 về 120 ms. Postmortem hai trang và action được theo dõi có thể cải thiện MTTR từ 40 phút xuống 15.
Q36. “Trong incident, bạn communicate thế nào?”
[ANALYSIS] Cập nhật symptom, action và impact theo interval đều đặn. [ILLUSTRATIVE ASSUMPTION] Post status ba dòng mỗi 15 phút và chỉ định một người phụ trách communication: “Checkout error là 12%; đang rollback deploy 09:15; 2.000 khách hàng bị ảnh hưởng.” Responder tập trung xử lý còn stakeholder vẫn có thông tin.
Q37. “Systems thinking nghĩa là gì?”
[ANALYSIS] Trace toàn request path: client, gateway, service, database, cache và queue. Xem cả upstream lẫn downstream. [ILLUSTRATIVE ASSUMPTION] Thêm retry có thể làm queue depth của consumer tăng gấp đôi; circuit breaker có thể cô lập failure. Trước deploy, hãy model retry storm, timeout budget, fallback và backpressure.
Q38. “Thiết kế cho tải hiện tại lớn hơn 10x thế nào?”
[ANALYSIS] Thiết kế seam rõ ràng và đo bottleneck hiện tại; đừng xây architecture chưa được kiểm chứng cho một scale giả định. [ILLUSTRATIVE ASSUMPTION] Hệ thống đo được 100 request/giây có thể chuẩn bị cho 1.000 bằng cách cache 20% read nóng nhất và shard queue theo key. Thay đổi tương lai nên là config có kiểm soát hoặc tuning có mục tiêu, không phải rewrite được mặc định.
Q39. “Giải thích latency cho stakeholder non-technical thế nào?”
[ANALYSIS] Dịch latency thành tác động lên customer và business bằng dữ liệu đã verify. [ILLUSTRATIVE ASSUMPTION] “Ở 800 ms, checkout completion giảm khoảng 6%, tương đương gần 6.000 USD mỗi tháng; cache change hai tuần có thể đưa latency về 120 ms.” Không trình bày business conversion như fact nếu chưa đo.
Q40. “Kể về quyết định khi thông tin chưa đầy đủ.”
[ANALYSIS] Nói rõ điều đã biết, chưa biết, các lựa chọn, quyết định và cách giới hạn downside. [ILLUSTRATIVE ASSUMPTION] Với 45 phút và monitoring một phần, failover sang region dự phòng chỉ hợp lý nếu action reversible trong 10 phút và có instrumentation; kill switch có thể giới hạn downside ở 20 phút latency gấp đôi. Phương pháp là action reversible và feedback nhanh.
Q41. “Bảo vệ một architecture decision thế nào?”
[ANALYSIS] Dùng trade-off table, failure mode và measurement có thể lặp lại, không dựa vào seniority. [ILLUSTRATIVE ASSUMPTION] Option A có thể tốn hơn 30% CPU nhưng giữ p99 dưới 200 ms; option B rẻ hơn nhưng lên 900 ms khi tải. Test staging năm phút là evidence, không phải proof cho production.
Q42. “Đặt và enforce SLO thế nào?”
[ANALYSIS] Xem SLO là service contract chung với error budget. [ILLUSTRATIVE ASSUMPTION] Mục tiêu availability 99,9% theo tháng tương ứng error budget 43 phút mỗi tháng. Product và engineering cùng quyết định việc gì phải dời khi budget bị đốt; alert theo burn rate thay vì từng error.
Q43. “Chạy postmortem để hành vi thực sự thay đổi thế nào?”
[ANALYSIS] Giữ postmortem blameless, có tài liệu và theo dõi action: timeline, causal analysis như five whys, và 2–3 action có owner cùng deadline. [ILLUSTRATIVE ASSUMPTION] Bounded cache và alert kích thước có thể cùng ship trong hai tuần. Action không có owner không phải plan.
Q44. “Nâng level engineer xung quanh bạn thế nào?”
[ANALYSIS] Xây mechanism: đặt câu hỏi trong review, dùng design doc và review incident không đổ lỗi. [ILLUSTRATIVE ASSUMPTION] Design review một giờ mỗi tuần có thể giảm rework từ 15% xuống 5% trong sáu tháng. Thành công là team ra quyết định tốt mà không phụ thuộc vào comment của bạn.
Q45. “Làm sao để bản thân có thể thay thế?”
[ANALYSIS] Biến kiến thức riêng thành kiến thức của team qua documentation, runbook, ADR và shadowing. [ILLUSTRATIVE ASSUMPTION] Hai engineer nên có khả năng cover mỗi service bạn own; khi bạn vắng mặt hai tuần, không cần page bạn. Replaceability loại dependency và mở rộng scope.
Q46. “Kể về một lần cải thiện on-call.”
[ANALYSIS] Audit page, phân biệt cause với symptom, thêm runbook và tự động hóa remediation an toàn. [ILLUSTRATIVE ASSUMPTION] Nếu có 25 page mỗi tuần, 80% là cause-based và một nửa không có runbook, giảm còn tám alert dựa trên SLO có thể tạo ra mức giảm 70%. Đo cả noise lẫn response time.
Q47. “Lãnh đạo không có authority thế nào?”
[ANALYSIS] Làm evidence dễ kiểm tra và bắt đầu bằng pilot nhỏ. [ILLUSTRATIVE ASSUMPTION] RFC một trang, bốn one-on-one sớm và pilot trên một service có thể hỗ trợ chuyển ba service sang queue library mới. Benchmark như throughput 2x và p99 50 ms so với 200 ms chỉ hữu ích khi test reproduce được.
Q48. “Career growth của senior là gì?”
[ANALYSIS] Tăng scope và leverage bằng cách đào sâu technical domain hoặc mở rộng ảnh hưởng. [ILLUSTRATIVE ASSUMPTION] Một cache fix tiết kiệm 6.000 USD mỗi tháng ở một service có thể thành shared library cho ba team. Chọn IC hay management có chủ đích; thước đo là bán kính quyết định, không chỉ title.
Q49. “Xử lý ambiguity ở cấp tổ chức thế nào?”
[ANALYSIS] Biến mục tiêu mơ hồ thành câu hỏi, owner, deadline và thin plan. [ILLUSTRATIVE ASSUMPTION] Với yêu cầu “cải thiện reliability”, hãy hỏi cái gì hay vỡ nhất, cái gì tốn nhất khi vỡ và cái gì ship được trong một quý; kế hoạch SLO có thể ship hai trên ba item và giảm incident 50%. Nêu assumption rồi cập nhật khi có evidence.
Q50. “Senior nghĩa là gì trong một câu?”
[ANALYSIS] “Senior là đưa ra quyết định đúng đắn khi bất định, own outcome và nâng capability của những người xung quanh.” Hãy đỡ câu đó bằng một story ngắn có đo lường: cải thiện latency, giảm page hoặc một engineer giờ đã tự ship được. Ba signal chính là judgment, ownership và leverage.
Tự kiểm tra
- Junior: Tôi giới thiệu được scope, nói về một điểm yếu thật và mitigation, giải thích bug đến guard, mô tả cách thoát bí và nhận ownership cho một sai lầm.
- Mid-level: Tôi ưu tiên theo impact và reversibility, trình bày trade-off deadline, mentor có outcome, delegate để tạo growth và biến rework thành process fix.
- Senior: Tôi dẫn được incident, dịch technical impact thành business impact, đặt SLO và error budget, chạy postmortem có action tracking và nâng capability của team bằng mechanism.
- Tôi đánh dấu metric minh họa là assumption và thay bằng evidence từ công việc của mình.
- Tôi định nghĩa senior trong một câu và chứng minh bằng một story ngắn.