Phỏng Vấn Tech Lead: Vòng Leadership, Quyết Định Kỹ Thuật Và Mentoring

Mình từng ngồi cả hai phía bàn phỏng vấn cho vị trí Tech Lead và Lead Engineer, frontend lẫn fullstack. Cảnh quen nhất: ứng viên code sạch, system design chắc, nhưng tới vòng leadership thì trả lời như đang giải bài coding. Đưa ra “đáp án đúng”. Không bối cảnh. Không lựa chọn bị bỏ. Không cái giá.

Vòng này không hỏi bạn biết gì. Nó hỏi một câu khác: khi mọi thứ đổ vỡ lúc 2 giờ sáng, người khác có dám tin vào phán đoán của bạn không?

Vài chuyện dưới đây là tình huống tổng hợp, không thuộc về công ty hay cá nhân cụ thể nào. Con số chỉ để minh hoạ cách trình bày.

1. Người phỏng vấn leadership thực ra tìm gì

Qua nhiều buổi ngồi hai phía, mình thấy câu hỏi leadership nào rồi cũng quy về năm tín hiệu:

1. Ownership — khi có vấn đề, bạn nói “tôi” hay “họ”?
2. Phán đoán dưới bất định — bạn quyết thế nào khi thiếu thông tin?
3. Ảnh hưởng không dựa trên quyền hạn — Tech Lead thường không phải manager, vậy bạn thuyết phục người khác bằng gì?
4. Nhân rộng đầu ra của team — bạn làm người khác giỏi lên, hay tự biến mình thành nút cổ chai?
5. Tự nhận thức — bạn kể được một lần mình sai không?

Nắm được năm cái đó thì câu trả lời tự có hướng: mỗi câu chuyện mang đi nên chứng minh ít nhất một tín hiệu.

2. STAR, nhưng phải có số liệu

STAR (Situation, Task, Action, Result) quen tới mức ai cũng biết, mà đa số kể nhạt: 70% thời gian dồn cho Situation và Result, còn Result thì mơ hồ kiểu “kết quả là mọi người hài lòng”. Mình sửa lại một chút:

S - Bối cảnh (tối đa 2 câu): team bao nhiêu người, ràng buộc gì
T - Trách nhiệm CỦA BẠN (không phải của team)
A - Hành động (chiếm ~60% câu trả lời): bạn cân nhắc gì, bỏ phương án nào, vì sao
R - Kết quả có số đo: trước / sau, kèm cái giá phải trả
L - Bài học: lần sau bạn làm khác điều gì

Hai chỗ mình soi kỹ nhất:

• Phần “A” phải có lựa chọn bị từ chối. “Mình cân nhắc A và B, chọn B vì…” là phán đoán. Chỉ kể “mình làm B” thì không có gì để chấm.
• Phần “R” phải có số, hoặc nếu không đo được thì nói rõ bạn đánh giá bằng cách nào. “Thời gian review trung bình từ 2 ngày xuống dưới 1 ngày” cụ thể hơn “review nhanh hơn” nhiều. Nhưng đừng bịa số. Interviewer giỏi hỏi tiếp ngay “bạn đo bằng cách nào”, và một con số không nguồn sập tại chỗ. Không có số chính xác thì nói “mình ước lượng khoảng… dựa trên…” vẫn hơn là bịa.

Trước buổi phỏng vấn, mình viết ra 6-8 câu chuyện thật, mỗi chuyện gắn vài chủ đề — một sự cố có thể dùng cho cả incident ownership, bất đồng và bài học thất bại. Học xương sống chuyện thôi. Đừng học thuộc từng câu.

3. ADR và trade-off: ghi lại cách mình quyết

Câu hỏi điển hình: “Kể về một quyết định kỹ thuật khó mà bạn đã dẫn dắt.” Độ chín không nằm ở nội dung quyết định. Nó nằm ở cách bạn ghi lại và truyền đạt quyết định đó.

ADR (Architecture Decision Record) là thứ mình nhắc nhiều nhất trong ca này. Một trang thôi, thường có mấy mục:

# ADR-014: Chọn cách xử lý cache cho dữ liệu danh mục

Trạng thái: Accepted (2026-xx-xx)   Người quyết định: <tên/vai trò>
Bối cảnh:   Vấn đề, ràng buộc, số liệu hiện có
Phương án:  A) ...   B) ...   C) Không làm gì
Quyết định: Chọn B, vì ...
Đánh đổi:   Chấp nhận ... để đổi lấy ...
Hệ quả:     Việc phải làm theo, rủi ro còn lại
Điều kiện xem xét lại: Nếu <chỉ số> vượt <ngưỡng> thì mở lại quyết định

Nghe ứng viên nói về ADR, mình để ý ba thứ:

• Có phương án “không làm gì” trong danh sách. Người viết nó ra là người biết mọi thay đổi đều có chi phí.
• Có điều kiện xem xét lại — nói trước khi nào quyết định này hết đúng.
• Phân loại theo khả năng đảo ngược. “Cánh cửa hai chiều” là mấy thứ đổi lại dễ, ví dụ chọn thư viện nội bộ: quyết nhanh, ít họp. “Cánh cửa một chiều” là thứ khó quay lại, ví dụ chọn database hay định dạng dữ liệu công khai: dành thời gian, thu thập ý kiến, viết ADR.

Hai nhánh đó khác nhau ở cách tiêu thời gian:

flowchart TB
  Q["Quyết định kỹ thuật cần chốt"] --> R{"Có quay lại được không?"}
  R -- "Được: thư viện nội bộ" --> T1["Cánh cửa hai chiều<br/>quyết nhanh, ít họp"]
  R -- "Khó: database,<br/>định dạng dữ liệu công khai" --> T2["Cánh cửa một chiều<br/>dành thời gian, thu thập ý kiến, viết ADR"]

Còn đây là khung ngắn để trả lời câu “bạn ra quyết định thế nào”:

Bước	Câu hỏi tự hỏi
Xác định vấn đề	Đây có đúng là vấn đề cần giải, hay là triệu chứng?
Thu thập dữ kiện	Có số liệu, prototype, spike nhanh nào giúp giảm bất định?
Liệt kê phương án	Có ít nhất hai phương án thật, gồm cả “không làm”?
Đánh đổi	Chi phí, rủi ro, khả năng đảo ngược, tác động đến team?
Quyết định và truyền đạt	Ai cần được tham vấn, ai chịu ảnh hưởng, ghi ở đâu?
Đo và xem lại	Chỉ số nào cho biết ta đúng hoặc sai?

Một câu trả lời yếu: “Mình chọn công nghệ X vì nó mới và nhanh.” Một câu trả lời mạnh: “Mình chọn X dù team chưa quen vì chi phí đổi ngược thấp, mình giới hạn phạm vi trong một module để thử, và đặt tiêu chí đánh giá sau hai sprint.”

4. Bất đồng: hiểu trước, phản biện sau

“Kể về lần bạn bất đồng với đồng nghiệp hoặc cấp trên.” Câu này người ta hay trả lời lệch về hai cực: “mình thuyết phục được họ” nghe độc đoán, còn “mình nhịn” nghe thiếu chính kiến.

Mình kể theo thứ tự này:

1. Hiểu quan điểm bên kia trước. “Mình hỏi để hiểu vì sao họ ưu tiên giải pháp đó, và phát hiện họ lo deadline, còn mình lo khả năng bảo trì.”
2. Kéo tranh luận từ ý kiến sang tiêu chí. Thống nhất trước tiêu chí đánh giá — độ trễ, chi phí vận hành, thời gian triển khai — rồi mới so phương án.
3. Dùng dữ kiện thay vì quyền lực: spike nhỏ, benchmark, thử nghiệm giới hạn thời gian.
4. Disagree and commit. Quyết định không theo hướng bạn thì bạn vẫn làm nghiêm túc, và ghi lại điều kiện xem xét lại. Cái cần là người quyết cuối cùng biết rõ mối lo của bạn.
5. Giữ quan hệ. Xong việc thì vẫn ngồi cùng nhau bình thường.

Ví dụ tổng hợp: hai kỹ sư tranh nhau nên tách một module thành service riêng hay giữ trong monolith. Lead đề xuất cả hai ghi ra ba chỉ số đo thành công, làm một spike hai ngày cho cả hai hướng, rồi quyết theo kết quả. Cuối cùng giữ monolith, ghi ADR nói rõ ngưỡng tải mà tại đó sẽ tách. Người từng phản đối được giao dẫn dắt phần theo dõi ngưỡng đó. Người “thua” vẫn có phần trong kết quả.

Câu bẫy liên quan: “Nếu cấp trên bắt bạn làm điều bạn cho là sai thì sao?” Trả lời an toàn và thật: trình bày rủi ro bằng dữ kiện, đề xuất phương án thay thế hoặc giảm thiểu rủi ro, và nếu quyết định vẫn giữ nguyên, thì thực hiện kèm ghi lại rủi ro. Chỉ khi chạm vào vấn đề đạo đức, an toàn hoặc pháp lý thì mới là ranh giới đỏ để leo thang hoặc từ chối.

5. Tech debt: nói bằng ngôn ngữ rủi ro

“Bạn xử lý tech debt thế nào khi product luôn muốn thêm tính năng?” Trả lời kém: “mình xin thời gian refactor”. Trả lời được: quy tech debt ra rủi ro và chi phí, vì chỉ có thế nó mới được ưu tiên.

Cách mình phân loại:

Loại debt	Ví dụ	Cách xử lý
Có chủ đích, có kế hoạch	Làm tạm để kịp mốc, đã ghi ticket	Đưa vào backlog với hạn cụ thể
Vô ý do thiếu kiến thức	Thiết kế chưa tốt	Mentoring, review, tài liệu
Bit rot	Thư viện cũ, thiếu test	Làm đều đặn, nhỏ giọt
Rủi ro bảo mật/độ ổn định	Dependency có lỗ hổng, không có monitoring	Ưu tiên cao, trình bày như rủi ro

Cách làm mình thấy hiệu quả:

• Làm cho debt nhìn thấy được. Danh sách debt có người sở hữu, mô tả tác động — làm chậm bao nhiêu, gây lỗi loại nào — chứ không chỉ ghi “code xấu”.
• Quy đổi sang tác động kinh doanh. “Module này làm mỗi tính năng liên quan mất thêm khoảng 2-3 ngày và là nguồn của phần lớn bug hồi quy gần đây” thuyết phục hơn “code khó đọc” nhiều.
• Dành ngân sách cố định thay vì xin từng lần. Ví dụ thoả thuận một tỷ lệ năng lực mỗi sprint cho việc cải thiện nội bộ, chốt với product từ đầu. Con số tuỳ team, nhưng nguyên tắc là minh bạch và ổn định.
• Trả nợ gắn với việc đang làm (boy scout rule): chạm module nào thì dọn phần liên quan. Tránh dự án refactor lớn không gắn với giá trị.
• Biết khi nào KHÔNG trả. Code ít được chạm vào, sắp bị thay thế, thì sửa là lãng phí.

Red flag ở ứng viên: coi mọi debt đều phải trả, hoặc đề xuất “dừng tính năng hai tháng để viết lại”. Cả hai đều lệch khỏi cân bằng giữa kỹ thuật và kinh doanh.

6. Mentoring: kéo một mid lên senior

Đây là chỗ phân biệt Tech Lead với một senior giỏi. Câu hỏi: “Bạn đã giúp ai đó phát triển lên cấp cao hơn thế nào?”

Khoảng cách mid-senior ít nằm ở kỹ thuật thuần. Nó nằm ở phạm vi tác động và độ tự chủ. Mid làm tốt việc được giao. Senior tự xác định việc cần làm, quản rủi ro, và nâng người quanh mình lên.

Lộ trình mình hay kể:

Mid  ->  Senior
 │         │
 ├─ Giao việc có phạm vi mở rộng dần: task -> feature -> hệ thống nhỏ
 ├─ Để họ viết design doc, rồi review cùng, không viết thay
 ├─ Cho họ dẫn dắt một buổi review/chia sẻ, một sự cố nhỏ (có người hỗ trợ)
 ├─ Phản hồi cụ thể, kịp thời, dựa trên hành vi quan sát được
 └─ Thống nhất mục tiêu và tiêu chí thăng tiến rõ ràng

Mấy nguyên tắc mình nhấn khi trả lời:

• Giao việc có chút căng, kèm lưới an toàn. Quá dễ thì không lớn lên. Quá khó mà không ai đỡ thì mất tự tin.
• Đặt câu hỏi thay vì đưa đáp án. “Bạn đã cân nhắc những phương án nào?” là cách luyện tư duy trade-off, thứ senior cần.
• Phản hồi theo hành vi, tác động, đề xuất. Ví dụ: “Trong PR hôm qua bạn bỏ qua trường hợp danh sách rỗng (hành vi), nên màn hình trắng ở production (tác động). Lần sau thử liệt kê các trạng thái biên trước khi viết code (đề xuất).” Nói về việc, không nói về người.
• 1:1 đều đặn, và người được kèm là người đặt agenda.
• Thành công của mentoring đo bằng việc bạn dần bớt cần thiết. Mọi quyết định vẫn phải qua bạn thì bạn đang tạo phụ thuộc, không phải năng lực.

Câu bẫy: “Nếu một người trong team mãi không tiến bộ thì sao?” Đáp án trưởng thành: làm rõ kỳ vọng, tìm nguyên nhân (thiếu kỹ năng, thiếu động lực, thiếu bối cảnh, vấn đề cá nhân), thống nhất kế hoạch cải thiện có mốc cụ thể, và phối hợp với manager. Không nên né tránh hay “âm thầm làm thay”.

7. Code review: chỗ văn hoá lộ ra sớm nhất

Muốn biết văn hoá kỹ thuật của một team, đọc code review của họ nhanh hơn đọc mọi tài liệu. Câu hỏi: “Bạn xây dựng văn hoá review thế nào?”

Mấy thực hành mình dùng:

• Phân biệt mức độ nghiêm trọng của comment. Ví dụ quy ước tiền tố: blocker: (phải sửa), suggestion: (nên xem xét), nit: (chi tiết nhỏ, không chặn merge), question: (hỏi để hiểu). Có tiền tố thì tranh cãi về chi tiết nhỏ giảm hẳn.
• Tự động hoá những gì máy làm được: format, lint, type check, test. Người review về thiết kế, tính đúng đắn, khả năng bảo trì — không phải về dấu chấm phẩy.
• PR nhỏ. PR càng lớn thì chất lượng review càng giảm. Nhiều team đặt quy ước kích thước hợp lý và khuyến khích tách PR.
• SLA phản hồi review. Ví dụ cam kết phản hồi lần đầu trong một ngày làm việc, để review không thành nút cổ chai.
• Review là dạy và học hai chiều. Lead cũng nhận comment từ người trẻ hơn, và cách lead đón nhận định hình văn hoá.
• Khen cụ thể. “Cách bạn tách hàm này làm test dễ viết hơn nhiều” cũng là phản hồi quý.
• Giọng điệu: nhận xét về code, không về người. “Đoạn này có thể gây race condition khi hai request đến cùng lúc” thay vì “bạn viết sai rồi”.

Câu bẫy: “Đồng nghiệp senior thường xuyên merge mà không chờ review. Bạn làm gì?” Nói chuyện riêng trước để hiểu lý do (có thể do review chậm), sau đó dùng quy tắc nhánh được bảo vệ áp dụng cho mọi người, không nhắm vào cá nhân.

8. Estimate và thương lượng scope với product

“Product yêu cầu hoàn thành trong 4 tuần nhưng bạn ước lượng cần 8 tuần. Bạn làm gì?” Câu này cho biết Tech Lead có phải đối tác của product hay chỉ là người nhận việc.

Hai kiểu trả lời hỏng: gật đầu rồi để team làm thêm giờ, hoặc từ chối cứng. Hướng mình dùng:

1. Hiểu mục tiêu phía sau deadline. Hạn 4 tuần đến từ đâu: sự kiện, hợp đồng, hay chỉ là ước đoán? Thực ra cần đạt kết quả kinh doanh nào?
2. Ước lượng bằng khoảng và độ tin cậy, không phải một con số duy nhất: “tối ưu 5 tuần, khả năng cao 7 tuần, kèm các giả định và rủi ro lớn nhất”.
3. Tách phạm vi thành lớp:

Must-have   : đủ để đạt mục tiêu kinh doanh cốt lõi
Should-have : tăng giá trị nhưng có thể đến sau
Could-have  : có thì tốt, cắt đầu tiên khi trễ

4. Đưa lựa chọn thay vì chỉ đưa rào cản: “Trong 4 tuần, mình có thể giao phần A và B với chất lượng đầy đủ. Phần C cần thêm 3 tuần. Hoặc nếu cần cả ba, ta có thể giảm phạm vi của B, hoặc bổ sung người nhưng cần thời gian để họ nắm bối cảnh.”
5. Giao hàng theo lát mỏng (incremental delivery) để product thấy tiến độ thật, và rủi ro không dồn hết về cuối.
6. Theo dõi và cập nhật sớm. Giả định sai thì báo ngay, đừng chờ sát hạn.

Ước lượng sai phần lớn vì quên mấy thứ vô hình: review, test, triển khai, tích hợp, ốm nghỉ, họp. Kể được mấy cái đó thì người nghe biết bạn từng thực chiến. Còn ước lượng thì luôn có bất định. Việc của lead là quản bất định cho minh bạch, không phải giả vờ xoá nó đi.

9. Incident ownership: kể sự cố cho đúng

“Kể về một sự cố production bạn xử lý.” Chuyện tốt thường có ba giai đoạn:

Trong sự cố   : giảm thiểu tác động trước (rollback, tắt feature flag), giao tiếp rõ ràng
Sau sự cố     : post-mortem không quy lỗi (blameless), tìm nguyên nhân gốc rễ hệ thống
Dài hạn       : hành động phòng ngừa có chủ sở hữu và hạn, và có kiểm tra đã làm chưa

Những điểm cộng:

• Khôi phục dịch vụ trước, tìm nguyên nhân sau. Rollback trước, điều tra sau.
• Vai trò rõ ràng trong sự cố: một người điều phối (incident commander), một người giao tiếp với bên liên quan, còn lại điều tra. Tránh cả đám cùng chạy vào một chỗ.
• Giao tiếp đều đặn. Cập nhật theo nhịp cố định ngay cả khi chưa có tiến triển, để người ngoài cuộc không phải đoán.
• Blameless post-mortem: hỏi “hệ thống nào cho phép lỗi này lọt qua” thay vì “ai làm sai”. Nguyên nhân gốc ở đây không phải “dev quên kiểm tra” mà là “không có test hoặc cảnh báo bắt trường hợp này”.
• Action item cụ thể: có chủ sở hữu, có hạn, được theo dõi. Post-mortem mà action item không bao giờ được làm thì cũng chỉ là hình thức.
• Nhận trách nhiệm. Sự cố liên quan đến quyết định của bạn thì nói thẳng. Nhiều ứng viên bị trừ điểm ở đây vì biến câu chuyện thành “mình giải cứu mọi thứ” mà quên nói nguyên nhân do ai khởi đầu.

10. Câu hỏi bẫy tổng hợp

• “Điểm yếu lớn nhất của bạn?” Chọn một điểm yếu thật, không gây hại cho vai trò (không phải “quá cầu toàn”), kèm theo cách bạn đang cải thiện. Ví dụ: “Mình có xu hướng tự làm việc khó thay vì giao đi. Mình đang tập giao sớm hơn và nhận chi phí là việc ban đầu chậm hơn.”
• “Bạn có thích code hay quản lý hơn?” Tech Lead cần cả hai. Nói rõ bạn giữ mức thực hành code vừa đủ để hiểu hệ thống, và dành phần còn lại để nhân rộng đầu ra của team.
• “Kể về lần thất bại.” Chọn thất bại thật có hậu quả, nêu bạn đã học gì và đã thay đổi quy trình ra sao. Tránh thất bại “giả” kiểu “mình làm việc quá chăm”.
• “Nếu team phản đối quyết định của bạn?” Lắng nghe, kiểm tra lại dữ kiện, giải thích lý do, và nếu vẫn giữ quyết định thì nói rõ vì sao và khi nào sẽ xem lại.

11. Red flags: hai phía, hai danh sách

Từ phía ứng viên, người phỏng vấn sẽ để ý:

Red flag	Vì sao đáng lo
Luôn nói “tôi”, không bao giờ “chúng tôi”	Khó làm việc nhóm, nhận hết công
Luôn nói “họ”, không bao giờ “tôi”	Đổ lỗi, thiếu ownership
Chê đồng nghiệp/công ty cũ	Có thể sẽ lặp lại với công ty mới
Không có số liệu hay cách đo	Chuyện kể khó kiểm chứng
Không kể được lần mình sai	Thiếu tự nhận thức
Chỉ có câu chuyện kỹ thuật, không có chuyện con người	Chưa sẵn sàng cho vai trò dẫn dắt

Từ phía công ty, chỗ bạn cần để ý khi đi phỏng vấn:

• Mô tả vai trò là “Tech Lead” nhưng thực tế là ôm mọi thứ: code, quản lý, DevOps, hỗ trợ khách hàng, mà không rõ ranh giới.
• Người phỏng vấn không mô tả được tiêu chí thành công cho vai trò sau 6-12 tháng.
• Văn hoá “anh hùng”: sự cố nào cũng có một người giải cứu, không ai nói về post-mortem hoặc quy trình.
• Phản hồi mơ hồ về tech debt: “chúng tôi không có thời gian cho việc đó”.
• Quá nhiều vòng phỏng vấn mà không ai nói thật về thách thức của team.
• Tỷ lệ nghỉ việc cao mà không giải thích được.

12. Câu hỏi nên hỏi ngược lại

Hỏi ngược lại cũng là một phần của buổi đánh giá, và là cách bạn kiểm tra chính công ty. Danh sách mình hay chuẩn bị:

1. “Thành công của vị trí này sau 6 tháng, 12 tháng trông như thế nào? Đo bằng gì?” Cho thấy kỳ vọng có thực không.
2. “Quyết định kỹ thuật lớn gần nhất được đưa ra thế nào? Ai là người quyết định cuối?” Để hiểu quyền hạn thực tế của Tech Lead.
3. “Tech debt hiện đang được quản lý ra sao, có thời gian dành riêng không?”
4. “Kể về sự cố production gần nhất và team học được gì.” Câu trả lời cho biết văn hoá blameless hay đổ lỗi.
5. “Tech Lead ở đây dành bao nhiêu phần trăm thời gian cho code, review, họp, mentoring?”
6. “Quy trình thương lượng scope và deadline giữa engineering và product như thế nào?”
7. “Con đường phát triển nghề nghiệp từ vị trí này là gì: tiếp tục kỹ thuật hay sang quản lý?”
8. “Điều gì khó nhất ở team này mà bạn mong người mới giúp giải quyết?” Câu hỏi này thường nhận lại câu trả lời thật nhất.

Lắng nghe cả nội dung lẫn cách trả lời. Ngập ngừng hay né tránh cũng là dữ liệu.

Chuẩn bị, và mấy câu hỏi ngược

Chuẩn bị thật ra gọn: viết ra vài câu chuyện thật từ chính công việc của bạn, gắn mỗi chuyện với một trong năm tín hiệu ở mục 1, soi lại từng chỗ “R” xem đã có cách đo chưa, rồi nghĩ trước câu hỏi bạn muốn hỏi lại.

Người ngồi bên kia bàn cũng đang tự hỏi một câu: “Mình có muốn làm việc cùng người này lúc 2 giờ sáng, khi production gặp sự cố không?”