Đi phỏng vấn IT Business Analyst, nhiều bạn Fresher không “fail” vì thiếu kiến thức.
Mà fail vì trả lời quá lan man.
Interviewer hỏi:
“Em từng xử lý stakeholder mâu thuẫn chưa?”
“Nếu dev nói không kịp timeline thì em làm gì?”
“Khi có change request giữa sprint, em xử lý ra sao?”
Và rất nhiều bạn bắt đầu kể kiểu:
“Dạ thì em nghĩ là mình nên giao tiếp với các bên, rồi cố gắng hiểu vấn đề, sau đó tìm cách giải quyết…”
Nghe không sai.
Nhưng không có cấu trúc, không có tình huống cụ thể, không có kết quả.
Đây là lúc bạn cần công thức STAR.
1️⃣ STAR là gì?
STAR là công thức trả lời câu hỏi tình huống gồm 4 phần:
S - Situation: Bối cảnh
Chuyện xảy ra trong tình huống nào?
Ví dụ:
“Trong mini project E-commerce, team em đang làm tính năng Checkout nhưng stakeholder marketing muốn thêm voucher vào phút cuối.”
T - Task: Nhiệm vụ
Vai trò của bạn trong tình huống đó là gì?
Ví dụ:
“Em cần làm rõ impact của thay đổi này và giúp team quyết định có đưa vào sprint hiện tại hay không.”
A - Action: Hành động
Bạn đã làm gì cụ thể?
Ví dụ:
“Em phân tích ảnh hưởng tới checkout flow, pricing rule, test case và effort của dev. Sau đó em đề xuất 2 option: đưa vào backlog sprint sau hoặc làm bản tối thiểu chỉ hỗ trợ 1 loại voucher.”
R - Result: Kết quả
Kết quả cuối cùng là gì?
Ví dụ:
“PO đồng ý chọn bản tối thiểu. Sprint vẫn hoàn thành đúng hạn, team không bị vỡ scope.”
2️⃣ Khi nào nên dùng STAR?
Bạn nên dùng STAR khi gặp các câu hỏi dạng:
“Hãy kể về một lần bạn…”
“Nếu gặp tình huống X, bạn sẽ xử lý thế nào?”
“Bạn từng làm việc với stakeholder khó tính chưa?”
“Bạn xử lý conflict ra sao?”
“Bạn làm gì khi requirement thay đổi?”
“Bạn từng thuyết phục team bằng dữ liệu chưa?”
Với Fresher chưa có kinh nghiệm thật, bạn vẫn dùng STAR được bằng cách lấy ví dụ từ:
Mini project tự làm
Bài tập nhóm
Case study trong khóa học
CLB / dự án sinh viên
Tình huống mô phỏng khi tự luyện portfolio
Quan trọng không phải bạn từng làm ở công ty lớn.
Quan trọng là bạn tư duy và hành động giống một BA thật.
3️⃣ Ví dụ 1: Stakeholder mâu thuẫn yêu cầu
Câu hỏi phỏng vấn:
“Nếu hai stakeholder đưa ra yêu cầu mâu thuẫn nhau, em sẽ xử lý thế nào?”
Trả lời theo STAR:
S - Situation
Trong một mini project Food Delivery, em gặp tình huống stakeholder phía Business muốn checkout thật ngắn để tăng tỷ lệ đặt hàng, còn stakeholder phía Operation lại muốn thu thêm nhiều thông tin địa chỉ để giảm lỗi giao hàng.
T - Task
Vai trò của em là làm rõ mục tiêu của hai bên và đề xuất phương án cân bằng giữa trải nghiệm người dùng và chất lượng vận hành.
A - Action
Em làm 3 việc:
Hỏi rõ mục tiêu của từng bên:
Business muốn giảm drop-off ở checkout
Operation muốn giảm đơn giao sai địa chỉ
Phân tích impact nếu làm theo từng hướng:
Form quá ngắn → dễ thiếu thông tin giao hàng
Form quá dài → user dễ bỏ đơn
Đề xuất giải pháp trung gian:
Chỉ giữ các trường bắt buộc ở checkout
Các thông tin phụ được đưa vào phần “Ghi chú giao hàng”
Thêm validation địa chỉ và gợi ý địa chỉ tự động
R - Result
Hai bên đồng ý với phương án này vì vẫn giữ checkout gọn nhưng giảm rủi ro giao sai. Em cũng cập nhật lại User Story và Acceptance Criteria để dev và QA hiểu rõ logic mới.
Câu chốt ăn điểm:
“Em không chọn phe nào, mà đưa cuộc thảo luận quay lại mục tiêu chung và impact business.”
4️⃣ Ví dụ 2: Dev nói không kịp timeline
Câu hỏi phỏng vấn:
“Nếu dev nói không thể hoàn thành tính năng trong timeline, em sẽ làm gì?”
Trả lời theo STAR:
S - Situation
Trong một mini project E-commerce, team cần hoàn thành tính năng áp voucher trong sprint 2 tuần. Tuy nhiên dev báo rằng rule voucher quá phức tạp, không kịp làm toàn bộ.
T - Task
Em cần hỗ trợ team giảm scope nhưng vẫn giữ được giá trị chính của tính năng.
A - Action
Em trao đổi với dev để hiểu phần nào phức tạp nhất. Sau đó em chia tính năng thành nhiều phần nhỏ:
Version 1: Chỉ hỗ trợ voucher giảm số tiền cố định
Version 2: Thêm voucher giảm theo phần trăm
Version 3: Thêm rule cộng dồn và giới hạn theo danh mục sản phẩm
Sau đó em làm việc với PO để xác nhận version 1 có đủ giá trị cho MVP không.
R - Result
PO đồng ý triển khai version 1 trước. Dev hoàn thành đúng sprint, QA test dễ hơn, và team có roadmap rõ ràng cho các rule nâng cao ở sprint sau.
Câu chốt ăn điểm:
“Em không chỉ báo lại là dev không làm kịp, mà cùng team tách nhỏ scope để vẫn deliver được value.”
5️⃣ Ví dụ 3: Change request giữa sprint
Câu hỏi phỏng vấn:
“Khi sprint đang chạy mà có change request, em xử lý thế nào?”
Trả lời theo STAR:
S Situation
Trong một sprint đang triển khai tính năng Checkout, stakeholder yêu cầu thêm phương thức thanh toán ví điện tử ngay giữa sprint.
T Task
Em cần đánh giá xem change request này có nên đưa vào sprint hiện tại không, và nếu đưa vào thì ảnh hưởng gì đến scope, effort và testing.
A - Action
Em thực hiện impact analysis:
Ảnh hưởng tới UI checkout
Ảnh hưởng tới Payment API
Cần thêm test case cho success, failed, timeout, callback
Có rủi ro ảnh hưởng đến flow thanh toán hiện tại
Sau đó em trình bày với PO 2 option:
Option 1: Đưa vào backlog sprint sau để không ảnh hưởng sprint goal hiện tại.
Option 2: Nếu bắt buộc làm ngay, cần bỏ một item ít quan trọng hơn ra khỏi sprint.
R - Result
PO quyết định đưa ví điện tử vào sprint sau. Sprint hiện tại hoàn thành đúng cam kết và team có thêm thời gian refine requirement cho payment method mới.
Câu chốt ăn điểm:
“Với change request, em không nhận ngay mà phân tích impact và trade-off trước khi quyết định.”
6️⃣ 3 lỗi Fresher hay mắc khi dùng STAR
Lỗi 1: Kể quá dài phần Situation
Nhiều bạn dành 70% thời gian để kể bối cảnh, nhưng không nói rõ mình đã làm gì.
Cách sửa:
Situation chỉ nên chiếm khoảng 20% câu trả lời.
Lỗi 2: Thiếu Result
Kể rất nhiều hành động nhưng không có kết quả.
Ví dụ yếu:
“Em trao đổi với team và cập nhật tài liệu.”
Cần sửa thành:
“Kết quả là team thống nhất scope mới, dev estimate lại được, sprint không bị delay.”
Result không nhất thiết phải là con số lớn.
Nhưng phải cho thấy hành động của bạn tạo ra tác động.
Lỗi 3: Không nói rõ vai trò của mình
Fresher hay nói “team em làm”, “nhóm em xử lý”, nhưng không rõ bạn đóng góp gì.
Cách sửa:
Dùng câu:
“Vai trò của em là…”
“Em đã chủ động…”
“Em chịu trách nhiệm…”
“Em đề xuất…”
Interviewer cần biết bạn làm gì, không chỉ team làm gì.
