Product Owner - Khối Ngân hàng Số

Đầ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.

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.

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.

Không kết luận chỉ vì con số cao hơn; cần kiểm tra thiết kế thí nghiệm và ý nghĩa thống kê.

• Chỉ số chính và cỡ mẫu phải được định trước; không nhìn kết quả liên tục rồi dừng khi thấy đẹp (peeking).
• Kiểm tra sample ratio mismatch: tỷ lệ chia nhóm thực tế có khớp thiết kế không.
• Xem khoảng tin cậy và p-value, không chỉ chênh lệch trung bình.
• Chạy đủ chu kỳ (ít nhất trọn tuần) để tránh hiệu ứng ngày trong tuần, hiệu ứng mới lạ.
• Kiểm tra chỉ số bảo vệ (guardrail): doanh thu, tỷ lệ huỷ, tốc độ trang.
• Cẩn thận khi cắt quá nhiều phân khúc: dễ có kết quả "có ý nghĩa" do ngẫu nhiên.

Người phỏng vấn muốn nghe: phân biệt ý nghĩa thống kê với ý nghĩa kinh doanh.

INNER JOIN chỉ giữ dòng khớp ở cả hai bảng; LEFT JOIN giữ mọi dòng bảng trái, phía phải không khớp thì NULL; FULL OUTER JOIN giữ tất cả; CROSS JOIN ghép mọi cặp.

Dòng bị nhân bản khi khoá join không duy nhất ở một phía (quan hệ một-nhiều hoặc nhiều-nhiều). Ví dụ join orders với payments khi một đơn có nhiều lần thanh toán, rồi SUM(order_amount) sẽ bị cộng trùng.

• Kiểm tra độ duy nhất của khoá trước khi join.
• Gộp (aggregate) bảng chi tiết trước rồi mới join.

Hay sai: đặt điều kiện lọc bảng phải trong WHERE sau LEFT JOIN, vô tình biến nó thành INNER JOIN; nên đặt trong ON.

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."

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.

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.

WHERE lọc từng dòng trước khi gộp nhóm; HAVING lọc nhóm sau khi đã GROUP BY và tính hàm tổng hợp.

Thứ tự logic: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT.

SELECT customer_id, COUNT(*) AS orders
FROM orders
WHERE created_at >= DATE '2026-01-01'
GROUP BY customer_id
HAVING COUNT(*) >= 3;

Hay sai: dùng alias định nghĩa trong SELECT ngay ở WHERE (đa số hệ quản trị báo lỗi), hoặc lọc điều kiện dòng bằng HAVING làm truy vấn chậm hơn.

Đây là câu mở đầu gần như chắc chắn có. Dùng công thức Hiện tại – Quá khứ – Tương lai, gói trong khoảng 1–2 phút.

• Hiện tại: vị trí, số năm kinh nghiệm, mảng/công nghệ chính.
• Quá khứ: một hai dự án hoặc thành tích liên quan nhất tới vị trí đang tuyển.
• Tương lai: vì sao bạn quan tâm tới vị trí này.

Câu mẫu: "Em là backend developer, khoảng 3 năm kinh nghiệm, chủ yếu làm Java Spring cho hệ thống thanh toán. Ở dự án gần nhất em phụ trách module đối soát và tối ưu các truy vấn báo cáo chạy chậm. Em đang tìm môi trường làm sản phẩm lâu dài để đi sâu hơn về thiết kế hệ thống, nên rất quan tâm tới vị trí này."

Hay sai: kể từ quê quán, trường cấp ba, hoặc đọc lại nguyên CV.