STAR/STARR và story bank cho behavioral interview

Lan man là do bạn nghĩ câu chuyện ngay trong phòng. Cách sửa: chuẩn bị sẵn 6–8 câu chuyện theo khung STAR, mỗi câu 2 phút, rồi tái sử dụng cho nhiều câu hỏi.

1. Bài toán

Câu hỏi behavioral điển hình:
  "Tell me about a time you disagreed with your manager."
  "Kể lần bạn trễ deadline."
  "Kể về sự cố production nghiêm trọng nhất bạn xử lý."
Người phỏng vấn chấm: bạn làm gì, nghĩ gì, học được gì.

2. Vấn đề

• Kể quá nhiều bối cảnh, quá ít hành động của bạn.
• Dùng "chúng em" suốt, không rõ bạn đóng góp gì.
• Không có kết quả đo được, không có bài học.
• Câu chuyện "thất bại" mà thật ra là khoe ("em làm việc quá chăm").

3. Giải pháp: STAR / STARR

STARR thêm Reflection. Ở vòng senior, phần này rất được chú ý.

4. Story bank: template và ví dụ

Template một thẻ câu chuyện

Tên: ______________________   Dùng cho: conflict / failure / deadline / ...
S: (1-2 câu)
T: (1 câu, "em chịu trách nhiệm...")
A: 3 hành động chính, mỗi cái kèm "vì sao"
   1.
   2.
   3.
R: số liệu
R: bài học + thay đổi cụ thể sau đó

Story bank cho shop-app (6 câu chuyện phủ hầu hết câu hỏi)

Ví dụ đầy đủ: câu chuyện #2 (Failure)

🇻🇳 Tiếng Việt:

S: Ở shop-app, bảng orders có khoảng 20 triệu dòng. Em phụ trách thêm cột provider để chuẩn bị đổi payment provider.

T: Em viết migration Flyway và deploy trong giờ thấp điểm.

A: Em viết ALTER TABLE ... ADD COLUMN provider VARCHAR(20) NOT NULL DEFAULT 'A' và chỉ test trên staging có 50 nghìn dòng. Lên production, lệnh khóa bảng 8 phút, checkout bị timeout. Em báo ngay trên kênh incident, nhận đó là migration của em, và cùng DBA quyết định chờ chạy xong thay vì kill vì rollback còn lâu hơn. Sau đó em viết postmortem.

R: Khoảng 300 đơn thất bại, CS liên hệ lại. Không mất dữ liệu.

R (bài học): Em đổi cách làm: migration chia bước expand–contract (thêm cột nullable, backfill theo batch, rồi mới thêm constraint), thêm checklist "migration an toàn" vào PR template, và test trên bản sao dữ liệu production cỡ thật. Sáu tháng sau đó team không có incident nào do migration.

🇬🇧 English:

S: In shop-app, the orders table had about 20 million rows. I was responsible for adding a provider column ahead of a payment provider switch.

T: I wrote the Flyway migration and deployed it during off-peak hours.

A: I added the column as NOT NULL with a default and only tested on staging with 50k rows. In production it locked the table for 8 minutes and checkout timed out. I raised it immediately in the incident channel, owned that it was my migration, and decided with the DBA to let it finish, since killing it would have meant an even longer rollback. Then I wrote the postmortem.

R: About 300 orders failed and support contacted those customers. No data was lost.

R (reflection): I changed how we do migrations: expand–contract steps (nullable column, batched backfill, then the constraint), a safe-migration checklist in our PR template, and testing on a production-sized copy. In the following six months we had zero migration-related incidents.

Chi tiết kỹ thuật migration an toàn, xem chương Database.

Ví dụ ngắn: câu chuyện #3 (Tough deadline), dạng gạch đầu dòng để ôn

S: Hợp đồng Provider A hết hạn 30/11, còn 6 tuần.
T: Em lead 3 dev chuyển checkout sang B.
A: 1. Spike 3 ngày → ước lượng 5±1 tuần, báo PM rủi ro webhook
   2. Cắt scope: ví điện tử và refund đơn cũ để sau, giữ A cho refund
   3. Feature flag rollout 5% → 50% → 100%, rollback 1 phút
R: Lên 100% ngày 24/11, 0 incident, phí giảm 0.4%/giao dịch
R: Lần sau em làm spike trước khi đưa bất kỳ con số nào

Danh sách câu hỏi behavioral hay gặp

5. Cách hoạt động: một story cho nhiều câu hỏi

Câu hỏi ──> xác định nhóm (conflict? failure?) ──> chọn story trong bank
                                                        |
                                                        v
                                    Nhấn phần Action phù hợp câu hỏi
                                    (#1 kể cho "conflict": nhấn cách nói chuyện
                                     #1 kể cho "influence": nhấn dữ liệu + PR)
                                                        |
                                                        v
                                    2 phút → dừng → "Anh/chị muốn em đi sâu phần nào?"

6. So sánh

7. Khi nào nên / không nên

• Nên dùng câu chuyện thật, dù nhỏ. Người phỏng vấn hỏi sâu 2–3 lớp là lộ chuyện bịa.
• Nên giữ bí mật công ty: đổi tên hệ thống, bỏ số liệu nhạy cảm.
• Không nên chê công ty/sếp cũ, kể cả trong câu chuyện conflict.
• Không nên học thuộc từng chữ. Học thuộc khung và con số.

Bạn hiểu gần đúng, chỉ cần chỉnh một điểm: "lead" không có nghĩa là có người báo cáo cho bạn. Những chuyện này đều tính:

• Bạn chủ động đề xuất và dẫn một cải tiến (thêm alert, PR template, chuẩn retry).
• Bạn làm incident lead một lần.
• Bạn onboard người mới, kèm intern.
• Bạn điều phối với team khác để xong một tính năng.

Câu chuyện #1 (double charge) là một câu chuyện leadership hoàn chỉnh dù bạn không có chức danh gì.

Đúng rồi, chuyện này sẽ xảy ra. Ba cách, theo thứ tự ưu tiên:

1. Bẻ một story gần nhất: "Em chưa gặp đúng tình huống đó, nhưng gần nhất là lần…" rồi nhấn phần liên quan.
2. Trả lời giả định có nguyên tắc: "Nếu gặp, em sẽ… vì…", nói rõ là giả định.
3. Xin vài giây suy nghĩ: "Cho em 10 giây nghĩ ví dụ phù hợp nhé." Hoàn toàn bình thường.

Đừng bịa. Câu hỏi đào sâu ("lúc đó anh kia nói gì?", "sao không làm cách khác?") sẽ làm câu chuyện bịa sụp.

Q1. Kể về một lần bất đồng với đồng nghiệp (story #1).

🇻🇳 Tiếng Việt:

(S) Checkout của shop-app gọi payment service do team khác sở hữu. (T) Em phát hiện khoảng 2% đơn bị trừ tiền hai lần. (A) Ban đầu tech lead bên đó cho rằng lỗi ở phía bọn em retry. Thay vì tranh luận trên Slack, em gom 20 trace ID cho thấy họ trả 500 khi timeout dù đã charge thành công. Em hẹn 15 phút, hỏi ràng buộc của họ trước, rồi đề xuất trả 503 kèm idempotency key và nhận viết PR. (R) Hai tuần sau double charge về 0. (R) Em học được rằng dữ liệu và việc giảm công cho bên kia giải quyết bất đồng nhanh hơn tranh luận.

🇬🇧 English:

(S) shop-app's checkout called a payment service owned by another team. (T) I noticed about 2% of orders were charged twice. (A) Their tech lead initially thought our retries were the problem. Instead of arguing on Slack, I collected 20 trace IDs showing they returned 500 on timeouts even after a successful charge. I set up a 15-minute call, asked about their constraints first, then proposed returning 503 with idempotency keys and offered to write the PR. (R) Two weeks later double charges were at zero. (R) I learned that data and lowering the other side's cost resolve disagreements faster than debate.

Q2. Kể về lần bạn trễ deadline.

🇻🇳 Tiếng Việt:

(S) Lần đầu em ước lượng migrate payment, em nói hai tuần khi chưa đọc docs provider. (T) Em phải giao tính năng đó. (A) Tuần thứ hai em phát hiện webhook và refund đơn cũ phức tạp hơn nhiều. Em báo PM ngay, đưa ước lượng mới 4–6 tuần và ba lựa chọn cắt scope. (R) Bọn em ra mắt checkout trước, refund làm sau, tổng trễ 3 tuần nhưng không ảnh hưởng hợp đồng. (R) Từ đó em không bao giờ đưa một con số đơn lẻ: luôn có khoảng, giả định và spike trước.

🇬🇧 English:

(S) The first time I estimated a payment migration, I said two weeks before reading the provider's docs. (T) I owned delivering it. (A) In week two I found webhooks and old refunds were much more complex. I told the PM immediately, gave a new 4-to-6-week range and three scope options. (R) We launched checkout first and refunds later, three weeks late overall but without affecting the contract. (R) Since then I never give a single number: always a range, assumptions, and a spike first.

Q3. Kể về sự cố production bạn xử lý (story #4).

🇻🇳 Tiếng Việt:

(S) Chiều thứ Sáu, checkout lỗi khoảng 40%. (T) Em là incident lead. (A) Em giao một bạn viết comms mỗi 15 phút, còn em xem dashboard và thấy lỗi tập trung ở Provider B timeout. Thay vì debug tiếp, em tắt feature flag để route về Provider A trước, giảm ảnh hưởng. (R) Lỗi về bình thường sau 14 phút, khoảng 180 đơn bị ảnh hưởng và CS đã có danh sách liên hệ. (R) Postmortem thêm alert theo từng provider và timeout ngắn hơn có fallback.

🇬🇧 English:

(S) On a Friday afternoon, about 40% of checkouts failed. (T) I was the incident lead. (A) I had a teammate post updates every 15 minutes while I checked dashboards and saw errors concentrated on Provider B timeouts. Instead of debugging further, I turned off the feature flag to route back to Provider A, mitigating first. (R) Errors were back to normal in 14 minutes; about 180 orders were affected and support had the list to follow up. (R) The postmortem added per-provider alerts and shorter timeouts with fallback.

Cách nhớ ngắn gọn

• STARR: Action chiếm nửa thời gian, Reflection là điểm cộng senior.
• 6–8 story thật phủ: conflict, failure, deadline, incident, leadership, decision.
• 2 phút rồi dừng, mời hỏi sâu.
• "Em" cho hành động, có số cho kết quả.

Tổng kết chương 20