01Bạn hãy giải thích Scrum: các vai trò, sự kiện và artifact chính.Junior
Gợi ý trả lời
Scrum là framework làm việc theo sprint ngắn (thường 1–4 tuần), mỗi sprint tạo ra phần sản phẩm dùng được.
- Vai trò: Product Owner (giá trị sản phẩm, ưu tiên backlog), Scrum Master (giúp team làm Scrum hiệu quả, gỡ vướng mắc), Developers (cả dev, tester, designer cùng tạo ra increment).
- Sự kiện: Sprint Planning, Daily Scrum, Sprint Review (demo cho stakeholder), Sprint Retrospective (cải tiến cách làm). Refinement là hoạt động thường xuyên.
- Artifact: Product Backlog, Sprint Backlog, Increment; kèm cam kết là Product Goal, Sprint Goal, Definition of Done.
Hay sai: coi Daily là buổi báo cáo cho PM, hoặc nói Scrum Master là "sếp" của team. Nếu dự án bạn làm "Scrum kiểu riêng", cứ nói thật và giải thích vì sao.
02Scrum và Kanban khác nhau thế nào? Khi nào chọn cái nào?Junior
Gợi ý trả lời
Scrum làm theo nhịp sprint cố định với cam kết đầu sprint; Kanban là luồng liên tục, giới hạn số việc đang làm (WIP limit) và tối ưu thời gian hoàn thành.
- Scrum hợp với phát triển sản phẩm có lộ trình, cần nhịp demo và lập kế hoạch đều đặn.
- Kanban hợp với việc đến liên tục và khó dự đoán: vận hành, hỗ trợ, bảo trì, xử lý ticket khách hàng.
- Chỉ số: Scrum thường nhìn velocity, burndown; Kanban nhìn lead time, cycle time, throughput.
- Nhiều team kết hợp: sprint cho tính năng, một làn Kanban cho bug gấp.
Người phỏng vấn muốn nghe: bạn chọn theo bản chất công việc, không theo sở thích. Ví dụ: "Team maintain hệ thống cho khách, yêu cầu đến mỗi ngày, em chuyển sang Kanban với WIP limit và cam kết thời gian phản hồi theo mức ưu tiên."
03Bạn estimate công việc cho team như thế nào? Story point khác ước lượng theo giờ ra sao?Junior
Gợi ý trả lời
Estimate là việc của cả team, không phải PM tự đặt rồi giao xuống.
- Story point: đo độ lớn tương đối (khối lượng, độ phức tạp, rủi ro), so với một story mẫu. Hay dùng planning poker với dãy gần Fibonacci để cả team thảo luận chỗ hiểu khác nhau.
- Giờ/ngày công: cần khi báo giá dự án outsourcing, hợp đồng fixed-price hoặc lập kế hoạch nguồn lực.
- Với dự án lớn: chia nhỏ (WBS), estimate theo khoảng (lạc quan, khả dĩ, bi quan), cộng buffer cho rủi ro, tích hợp, test, sửa bug.
- Dùng dữ liệu cũ (velocity, dự án tương tự) để kiểm tra lại.
Hay sai: đổi story point ra giờ một cách cứng nhắc, hoặc dùng velocity để so sánh hiệu suất giữa các team.
04Bạn dùng Jira (hoặc công cụ tương tự) để theo dõi tiến độ dự án như thế nào?Junior
Gợi ý trả lời
Công cụ chỉ hữu ích khi team cập nhật thật và bạn nhìn đúng chỉ số.
- Cấu trúc: Epic cho tính năng lớn, Story/Task cho việc trong sprint, Bug riêng; có quy ước đặt tên và trạng thái thống nhất.
- Board phản ánh đúng workflow của team (To Do, In Progress, Code Review, Testing, Done).
- Theo dõi: burndown/burnup của sprint, việc bị kẹt lâu ở một cột, số bug mở theo mức độ.
- Dashboard hoặc báo cáo định kỳ cho khách hàng/sếp: tiến độ theo milestone, rủi ro, quyết định cần họ đưa ra.
- Kết hợp Confluence hoặc wiki cho tài liệu, biên bản họp.
Người phỏng vấn muốn nghe: bạn dùng dữ liệu để phát hiện vấn đề sớm (ví dụ ticket nằm ở cột Testing quá lâu là dấu hiệu thiếu tester), không chỉ để báo cáo.
05Giữa sprint, bạn thấy team khó hoàn thành sprint goal. Bạn làm gì?
Gợi ý trả lời
Phát hiện sớm, nói thật sớm, và chọn phương án cùng team và PO.
- Tìm nguyên nhân: estimate sai, phát sinh việc ngoài kế hoạch, bị block bởi bên khác, có người nghỉ.
- Gỡ block trước: liên hệ team khác, khách hàng, xin môi trường, quyết định nhanh các điểm chờ.
- Cùng PO thương lượng phạm vi: giữ những gì quan trọng nhất cho sprint goal, đẩy phần còn lại sang sprint sau.
- Thông báo cho stakeholder kèm kế hoạch mới, không đợi tới ngày review.
- Retrospective: tìm nguyên nhân gốc để điều chỉnh planning lần sau.
Hay sai: bắt team OT để kịp mà không đổi gì về phạm vi. Làm một lần có thể được, nhưng lặp lại thì chất lượng giảm và người giỏi sẽ nghỉ.
06Khách hàng liên tục thêm yêu cầu nhỏ (scope creep). Bạn kiểm soát thế nào?
Gợi ý trả lời
Mỗi yêu cầu "nhỏ" cộng lại thành trễ hạn. Cần quy trình tiếp nhận thay đổi rõ ràng từ đầu dự án.
- Chốt phạm vi bằng tài liệu hoặc backlog đã thống nhất, kèm định nghĩa hoàn thành.
- Mọi yêu cầu mới đi qua một kênh: ghi nhận, đánh giá effort và ảnh hưởng tới mốc bàn giao.
- Đưa lựa chọn cho khách: đổi lấy hạng mục khác, dời mốc, tính thêm chi phí, hoặc để giai đoạn sau.
- Dự án fixed-price: dùng change request có ký duyệt. Dự án time & material: minh bạch ảnh hưởng tới ngân sách.
- Dặn team không nhận yêu cầu trực tiếp từ khách mà không qua PM/PO.
Người phỏng vấn muốn nghe: bạn vẫn giữ được quan hệ tốt với khách. Nói "có, và đây là cái giá" thay vì chỉ nói "không".
07Trong team có một thành viên thường xuyên trễ việc, ảnh hưởng cả nhóm. Bạn xử lý ra sao?
Gợi ý trả lời
Nói chuyện riêng, sớm và dựa trên sự việc trước khi kết luận.
- Chuẩn bị ví dụ cụ thể (task nào, trễ bao lâu, ảnh hưởng gì), tránh nhận xét chung chung kiểu "em làm chậm".
- Hỏi để hiểu nguyên nhân: việc quá sức, thiếu kiến thức, yêu cầu không rõ, vấn đề cá nhân, hay mất động lực.
- Cùng thống nhất kế hoạch: chia task nhỏ hơn, ghép cặp với người kinh nghiệm, check-in thường xuyên hơn, hỗ trợ đào tạo.
- Theo dõi và phản hồi định kỳ. Nếu không cải thiện, phối hợp với line manager/HR theo quy trình của công ty.
Hay sai: góp ý trước cả team, hoặc lẳng lặng giao việc cho người khác làm thay. Cách đó làm người giỏi kiệt sức và vấn đề không được giải quyết.
08Product Owner ưu tiên backlog dựa trên gì?
Gợi ý trả lời
PO ưu tiên theo giá trị mang lại so với chi phí và rủi ro, gắn với mục tiêu sản phẩm.
- Mục tiêu sản phẩm/công ty trong giai đoạn này: tăng người dùng mới, giữ chân, doanh thu, hay giảm chi phí vận hành.
- Dữ liệu: số liệu sử dụng, phản hồi người dùng, ticket hỗ trợ, kết quả phỏng vấn người dùng.
- Effort và rủi ro do team ước lượng; phụ thuộc kỹ thuật; nợ kỹ thuật cần trả.
- Ràng buộc bắt buộc: quy định pháp lý, cam kết hợp đồng, hạn chót của đối tác.
- Framework hỗ trợ: RICE, MoSCoW, Kano, value/effort.
Người phỏng vấn muốn nghe: ví dụ một lần bạn từ chối hoặc hoãn một yêu cầu từ sếp/khách lớn nhờ dữ liệu, và cách bạn giải thích để họ đồng ý.
09Dự án outsourcing có khách hàng nước ngoài, lệch múi giờ. Bạn giữ giao tiếp hiệu quả thế nào?Senior
Gợi ý trả lời
Tận dụng giờ làm trùng nhau cho việc cần trao đổi trực tiếp, phần còn lại làm bất đồng bộ có tài liệu.
- Thống nhất lịch họp cố định trong khung giờ trùng (daily hoặc vài buổi mỗi tuần), có agenda và biên bản.
- Câu hỏi gom lại, viết rõ ràng kèm ngữ cảnh và phương án đề xuất, để khách trả lời được ngay trong một lần.
- Báo cáo định kỳ: đã làm, sẽ làm, rủi ro, quyết định cần khách đưa ra.
- Demo cuối sprint để khách thấy sản phẩm thật; ghi hình nếu khách không tham gia được.
- Lưu ý khác biệt văn hoá: một số khách cần nói thẳng, một số cần trang trọng; chủ động báo tin xấu sớm.
Hay sai: để team chờ câu trả lời của khách cả ngày mà không có việc dự phòng.
10Bạn quản lý rủi ro dự án như thế nào? Kể một rủi ro bạn đã xử lý.Senior
Gợi ý trả lời
Quản lý rủi ro là xác định sớm, đánh giá, có kế hoạch ứng phó và theo dõi liên tục.
- Lập danh sách rủi ro (risk register) ngay từ đầu: nhân sự, công nghệ mới, phụ thuộc bên thứ ba, yêu cầu chưa rõ, hạ tầng.
- Đánh giá khả năng xảy ra và mức ảnh hưởng, ưu tiên rủi ro cao.
- Chọn cách ứng phó: tránh, giảm thiểu, chuyển giao, chấp nhận; mỗi rủi ro có người chịu trách nhiệm theo dõi.
- Xem lại trong các buổi họp định kỳ, cập nhật khi tình hình thay đổi.
Ví dụ theo STAR: "API của đối tác chưa sẵn sàng (S), em cần giữ tiến độ tích hợp (T). Em đề xuất team làm mock theo tài liệu API, đồng thời hẹn mốc kiểm tra với đối tác hàng tuần (A). Khi API thật có, phần tích hợp chỉ mất vài ngày điều chỉnh (R)."
11Dự án đã trễ đáng kể so với kế hoạch. Bạn báo cáo với khách hàng/ban lãnh đạo và kéo dự án lại thế nào?Senior
Gợi ý trả lời
Đầu tiên là minh bạch: báo sớm, kèm nguyên nhân và phương án, không chỉ báo tin xấu.
- Đánh giá lại thực trạng: còn bao nhiêu việc, velocity thực tế, đường găng (critical path).
- Đưa các phương án với đánh đổi rõ ràng: cắt bớt phạm vi cho đợt đầu, dời mốc, bổ sung nguồn lực (lưu ý người mới cần thời gian làm quen), song song hoá một số việc.
- Đề xuất một phương án bạn khuyến nghị và lý do.
- Sau khi chốt: kế hoạch mới, mốc kiểm tra gần hơn, báo cáo thường xuyên hơn để lấy lại niềm tin.
- Tìm nguyên nhân gốc để không lặp lại.
Người phỏng vấn muốn nghe: bạn không giấu, không đổ lỗi cho team hay khách, và biết rằng thêm người vào dự án đang trễ thường không giúp kịp ngay.
12Bạn đo thành công của một dự án hay một sản phẩm bằng gì?Senior
Gợi ý trả lời
Không chỉ "đúng hạn, đúng ngân sách", mà còn giá trị mang lại và sức khoẻ của team.
- Dự án: tiến độ theo mốc, chi phí so với ngân sách, phạm vi bàn giao, chất lượng (bug sau release, số lần hotfix), mức hài lòng của khách hàng.
- Sản phẩm: chỉ số gắn với mục tiêu như người dùng hoạt động, tỷ lệ chuyển đổi, tỷ lệ giữ chân, doanh thu, chi phí vận hành giảm.
- Team: tốc độ ổn định, ít OT kéo dài, tỷ lệ nghỉ việc thấp, retrospective có cải tiến thật.
Ví dụ: "Dự án trước bàn giao trễ hai tuần so với kế hoạch ban đầu nhưng khách đã đồng ý từ sớm vì đổi phạm vi; sau go-live ít lỗi nghiêm trọng và khách ký tiếp giai đoạn 2. Em coi đó là thành công."
Hay sai: chỉ nói về output (số tính năng) mà không nói outcome.
Gặp câu hỏi khác khi phỏng vấn? Kể lại ẩn danh để người sau ôn đúng trọng tâm, hoặc xem câu hỏi thật hay gặp ở nhiều công ty.