Đây là kỹ năng nhiều Tech Lead còn thiếu: người trình bày giỏi không phải người trả lời nhanh nhất, mà là người hiểu đúng ý định của câu hỏi rồi mới trả lời.

Khi nhận một câu hỏi, đừng phản xạ ngay. Hãy đi theo quy trình.

Framework Q-CARE

                 Receive Question
                        │
                        ▼
             Q - Qualify the Question
       (Họ đang hỏi điều gì thật sự?)
                        │
                        ▼
            C - Clarify if Necessary
        (Có cần hỏi lại để hiểu rõ?)
                        │
                        ▼
            A - Analyze the Intent
      (Họ muốn gì? Thách thức? Học hỏi?)
                        │
                        ▼
             R - Respond Clearly
       (Trả lời có cấu trúc, không lan man)
                        │
                        ▼
             E - Extend Discussion
      (Có cần mở rộng hoặc follow-up?)

1) Q — Qualify: Xác định câu hỏi thật sự

Đừng chỉ nghe câu chữ. Hãy nghe mục đích.

Ví dụ:

Why didn’t you use GraphQL?

Thay vì nghĩ “họ đang chê”, hãy xem các khả năng:

  • Họ muốn hiểu tiêu chí lựa chọn.
  • Họ muốn so sánh giải pháp.
  • Họ muốn học từ context thực tế.
  • Họ từng có trải nghiệm khác.

Cùng một câu hỏi, nhưng ý định có thể rất khác.

2) C — Clarify: Hỏi lại nếu chưa rõ

Nếu câu hỏi mơ hồ, hãy hỏi lại để chốt scope:

That’s a great question.
Just to make sure I understand correctly,
are you asking about performance, developer experience, or scalability?

Lợi ích:

  • Có thêm vài giây để sắp ý.
  • Tránh trả lời lệch trọng tâm.
  • Người hỏi cảm thấy được tôn trọng.

3) A — Analyze: Phân loại ý định câu hỏi

Mình thường gom thành 6 nhóm:

                    Question
                         │
     ┌───────────────────┼────────────────────┐
     ▼                   ▼                    ▼
 Clarification      Technical            Challenge
     │                   │                    │
     ▼                   ▼                    ▼
 Experience         Opinion           Future / Scale

a) Clarification

Ví dụ: What is MCP?

→ Trả lời ngắn, rõ định nghĩa. Không cần đào quá sâu.

b) Technical Detail

Ví dụ: Why did you choose Kafka?

→ Trả lời theo: requirement → constraints → decision.

c) Challenge

Ví dụ: I think RabbitMQ could also solve this.

Đừng phản bác ngay. Nên phản hồi:

That’s a good point. RabbitMQ could work in many scenarios.
In our case, the deciding factor was…

d) Experience

Ví dụ: Did your team encounter any issues?

→ Đây là cơ hội vàng để chia sẻ bài học thật.

e) Opinion

Ví dụ: Do you think AI Agents will replace developers?

Đừng trả lời một chữ “Yes/No”. Hãy nêu điều kiện:

It depends on several factors…

f) Future / Scale

Ví dụ: Would you still choose this architecture today?

→ Nói rõ: nếu làm lại, cái gì giữ nguyên, cái gì thay đổi.

4) R — Respond: Trả lời theo cấu trúc STAR (rút gọn)

Situation
   ↓
Decision
   ↓
Reason
   ↓
Result

Ví dụ câu hỏi: Why Redis?

  • Situation: Database became the bottleneck.
  • Decision: We introduced Redis for caching.
  • Reason: Read traffic was much higher than write traffic.
  • Result: Response time dropped significantly.

Cấu trúc này giúp người nghe theo được mạch quyết định.

5) Nếu chưa biết câu trả lời

Đây là điểm nhiều người mất điểm.

Không nên:

I don’t know.

Nên:

That’s an interesting question.
I haven’t evaluated that option yet, so I don’t want to speculate.
I’ll look into it and follow up after the session.

Đây là cách phản hồi chuyên nghiệp: trung thực + có trách nhiệm.

6) E — Extend: Xác nhận sau khi trả lời

Sau khi trả lời, đừng chuyển chủ đề ngay. Hãy kiểm tra độ khớp:

Answer
   │
   ▼
Did they look satisfied?
   │
 ┌─┴─────────────┐
 │               │
 ▼               ▼
Yes             No
 │               │
 ▼               ▼
Move on      Ask follow-up

Câu hỏi hữu ích:

  • Did that answer your question?
  • Is that what you were asking?
  • Were you referring to another aspect?

Ví dụ trả lời hoàn chỉnh

Câu hỏi

Why didn’t your team use GraphQL?

Trả lời gợi ý

Thanks for the question.
If I understand correctly, you’re asking why we chose REST instead of GraphQL.
We evaluated both options during the design phase. Since our APIs were relatively stable and the frontend had predictable data requirements, REST gave us a simpler implementation with lower operational complexity. GraphQL offered more flexibility, but in our context that additional complexity wasn’t justified.
Does that address your question, or were you thinking about performance or developer experience?

Điểm mạnh của câu trả lời:

  • Xác nhận lại câu hỏi.
  • Trả lời theo bối cảnh và tiêu chí quyết định.
  • Không phủ nhận giải pháp còn lại.
  • Kết thúc bằng câu mở để đối thoại tiếp.

Checklist nhanh khi nhận câu hỏi

                   Question
                       │
                       ▼
          1. Listen without interrupting
                       │
                       ▼
          2. Identify the real intent
                       │
                       ▼
       3. Clarify if the question is unclear
                       │
                       ▼
       4. Think before answering (2–3 seconds)
                       │
                       ▼
      5. Explain the reasoning, not just the answer
                       │
                       ▼
          6. Confirm the answer was helpful

Nguyên tắc quan trọng cho Tech Lead

Đừng cố bảo vệ slide, hãy cố giải quyết sự tò mò của người hỏi.

  • Presenter mindset: “Mình phải chứng minh giải pháp của mình đúng.”
  • Tech Lead mindset: “Mình giải thích bối cảnh, tiêu chí, trade-off để mọi người hiểu vì sao team quyết định như vậy.”

Khi chuyển sang mindset thứ hai, Q&A sẽ trở thành thảo luận kỹ thuật có giá trị thay vì tranh luận thắng-thua.