Bộ câu hỏi + đáp án mẫu cho dev, BA, tester ứng tuyển vào ngân hàng/fintech: core banking, ISO 8583, chuyển tiền nhanh 24/7, đối soát, VietQR. Đọc gọn, không phải khóa học 10 buổi.
Cảm ơn! Bộ đề đang hoàn thiện, chưa thu tiền. Bạn là một trong những người đầu tiên quan tâm.
10 câu mẫu miễn phí
Mỗi câu: ý người phỏng vấn muốn kiểm + đáp án mẫu gọn + điểm cộng.
DEV
1. Mô tả cấu trúc một message ISO 8583.
Kiểm: bạn đã từng chạm vào hệ thống thẻ/switch chưa.
Đáp án mẫu: gồm 3 phần — MTI (4 số: phiên bản, lớp, chức năng, nguồn; ví dụ 0200 yêu cầu tài chính, 0210 phản hồi, 0400 đảo giao dịch, 0800 quản lý mạng/echo), bitmap (64 bit cho biết trường nào có mặt; bit 1 bật thì có bitmap phụ cho trường 65–128), và các trường dữ liệu (DE2 số thẻ, DE3 mã xử lý, DE4 số tiền, DE11 STAN, DE37 RRN, DE39 mã phản hồi — 00 là chấp nhận).
Điểm cộng: nói được trường có độ dài cố định vs biến đổi (LLVAR/LLLVAR), và mỗi ngân hàng/switch có "spec" riêng dựa trên chuẩn.
2. Gửi giao dịch rút tiền sang switch nhưng hết thời gian chờ, không nhận phản hồi. Xử lý thế nào?
Kiểm: tư duy "trạng thái không rõ" — lỗi đắt nhất ngành.
Đáp án mẫu: không được coi là thất bại rồi trả tiền lại cho khách ngay, cũng không gửi lại lệnh mới. Gửi đảo giao dịch (0400/0420 — 0420 là advice, gửi lặp đến khi được xác nhận) tham chiếu giao dịch gốc qua STAN/RRN; trong lúc chờ để giao dịch ở trạng thái treo; cuối ngày đối soát với file của switch để chốt.
Điểm cộng: nhắc đến bảng trạng thái (KHỞI TẠO → ĐÃ GỬI → THÀNH CÔNG/THẤT BẠI/KHÔNG RÕ) và job quét giao dịch treo.
3. Vì sao không dùng double cho số tiền? Dùng gì?
Kiểm: lỗi cơ bản nhưng rất hay gặp.
Đáp án mẫu: số thực nhị phân không biểu diễn chính xác số thập phân (0.1 + 0.2 != 0.3) → lệch khi cộng dồn. Dùng BigDecimal (Java) / decimal (.NET) hoặc lưu đơn vị nhỏ nhất dạng số nguyên. Quy ước làm tròn phải ghi rõ (HALF_UP hay HALF_EVEN) và thống nhất toàn hệ thống.
Điểm cộng: khi so sánh BigDecimal dùng compareTo, không dùng equals (2.0 khác 2.00 về scale).
4. Khách bấm "Chuyển tiền" hai lần do mạng chậm. Làm sao để chỉ trừ tiền một lần?
Kiểm: idempotency.
Đáp án mẫu: client sinh mã idempotency cho mỗi lệnh; server lưu mã này với ràng buộc duy nhất (unique) trong cùng giao dịch DB với bản ghi lệnh. Lần gửi thứ hai trùng mã → trả lại kết quả của lần đầu, không xử lý lại. Trừ số dư bằng khóa dòng (SELECT ... FOR UPDATE) hoặc khóa lạc quan có cột version.
Điểm cộng: hạch toán theo bút toán kép (một bên nợ, một bên có, tổng bằng nhau) để mọi lệch đều dò ra được.
BA
5. Phân biệt ngày hạch toán (booking date) và ngày hiệu lực (value date). Cho ví dụ.
Kiểm: thuật ngữ core banking.
Đáp án mẫu: ngày hạch toán = ngày bút toán được ghi vào sổ; ngày hiệu lực = ngày số tiền bắt đầu có tác dụng (tính lãi, tính số dư khả dụng). Ví dụ giao dịch phát sinh sau giờ chốt sổ cuối ngày có thể được hạch toán vào ngày làm việc kế tiếp; lãi tiền gửi tính theo ngày hiệu lực.
Điểm cộng: biết core chạy cuối ngày (EOD) để tính lãi, phí, chuyển ngày làm việc (tên gọi tùy core; ở Temenos T24 gọi là COB — Close of Business).
6. Mô tả luồng chuyển tiền nhanh liên ngân hàng 24/7 từ góc nhìn nghiệp vụ.
Kiểm: hiểu luồng, không chỉ màn hình.
Đáp án mẫu: (1) khách nhập tài khoản/số thẻ người nhận → (2) truy vấn tên người nhận qua hệ thống chuyển mạch (NAPAS) → (3) khách xác nhận + xác thực (OTP/sinh trắc) → (4) ngân hàng chuyển trừ tiền, gửi lệnh qua NAPAS → (5) ngân hàng nhận ghi có cho người nhận và trả kết quả → (6) cuối ngày đối soát với NAPAS. Trường hợp không rõ kết quả → treo + tra soát.
Điểm cộng: phân biệt với chuyển tiền qua hệ thống thanh toán điện tử liên ngân hàng quốc gia do Ngân hàng Nhà nước vận hành (khuôn khổ Thông tư 37/2016/TT-NHNN) — đây là kênh khác với dịch vụ chuyển nhanh 24/7 của NAPAS; thời gian xử lý của nó theo quy định giờ/ngày làm việc của hệ thống, nên hỏi lại ngân hàng cụ thể.
7. Đối soát là gì? Có những loại lệch nào?
Kiểm: phần "không ai thích làm" nhưng ngân hàng nào cũng cần.
Đáp án mẫu: so khớp từng giao dịch giữa các bên (core ngân hàng, kênh/ứng dụng, file của switch/NAPAS) theo khóa chung (mã giao dịch, số tiền, thời điểm). Loại lệch: có bên này không có bên kia; lệch trạng thái (core thành công, switch báo thất bại hoặc ngược lại); lệch số tiền/phí. Mỗi loại có quy trình: hoàn tiền, ghi có bổ sung, hay mở tra soát.
Điểm cộng: đề xuất màn hình theo dõi tỉ lệ khớp mỗi ngày và hạn xử lý cho từng loại lệch.
TESTER
8. Liệt kê ca kiểm thử cho chức năng chuyển tiền trong app.
Kiểm: nghĩ quá "happy path".
Đáp án mẫu: số tiền biên (tối thiểu, tối đa/lần, vượt hạn mức ngày); số dư không đủ / vừa đủ (kể cả phí); tài khoản nhận không tồn tại/đã đóng; OTP sai, hết hạn, nhập lại quá số lần; bấm hai lần (trùng lệnh); mất mạng sau khi gửi; switch hết thời gian chờ → treo; giao dịch đúng lúc chạy cuối ngày; ký tự đặc biệt/tiếng Việt có dấu trong nội dung chuyển.
Điểm cộng: kiểm cả sau giao dịch — số dư, lịch sử, thông báo, bút toán đối ứng, file đối soát.
9. Kiểm thử mã VietQR thế nào?
Kiểm: biết QR thanh toán có cấu trúc, không chỉ "quét được là xong".
Đáp án mẫu: VietQR theo chuẩn EMVCo dạng TLV (mã trường 2 số – độ dài 2 số – giá trị); thông tin ngân hàng/tài khoản nằm trong trường 38. Kiểm: QR tĩnh vs động (động thường kèm số tiền và nội dung của từng giao dịch), thông tin ngân hàng/tài khoản người nhận đúng, số tiền và nội dung đọc ra khớp, CRC cuối chuỗi (trường 63, CRC16-CCITT tính trên toàn chuỗi gồm cả 6304) đúng — sửa một ký tự thì app phải từ chối.
Điểm cộng: thử QR bị cắt, QR của ngân hàng khác, QR có số tiền 0.
10. Log ứng dụng có in số thẻ đầy đủ. Bạn báo lỗi mức độ nào? Vì sao?
Kiểm: ý thức bảo mật (PCI DSS).
Đáp án mẫu: mức nghiêm trọng. Chuẩn PCI DSS yêu cầu che số thẻ khi hiển thị (thường chỉ hiện tối đa 6 số đầu + 4 số cuối) và không lưu dữ liệu xác thực nhạy cảm (CVV, PIN) sau khi cấp phép. Log là nơi hay rò rỉ vì nhiều người đọc được và lưu lâu.
Điểm cộng: đề xuất kiểm tự động — quét log tìm chuỗi giống số thẻ (đúng thuật toán Luhn).
Nội dung từ chuẩn/tài liệu công khai. Không dùng tài liệu nội bộ của bất kỳ ngân hàng nào.