Phỏng vấn IT ngân hàng Làm 10 câu

Miễn phí, không cần đăng ký

Anh/chị biết ngay mảng nào cần ôn trước buổi phỏng vấn IT ngân hàng

10 câu hỏi kiểu người phỏng vấn ngân hàng và fintech hay hỏi dev, BA, tester: ISO 8583, giao dịch treo, idempotency, đối soát, VietQR. Trả lời trong đầu, mở đáp án mẫu, tự chấm. Cuối bài là danh sách những câu cần ôn lại.

Làm 10 câu ngay

Không lưu câu trả lời, không thu email hay tên. Trang chỉ đếm ẩn danh số lượt xem và lượt làm xong.

Xem thử một câu mẫu

Dành cho người chuẩn bị phỏng vấn vị trí IT ở ngân hàng, fintech
  • Dev, BA, Tester
  • Đáp án mẫu kèm điểm cộng
  • Không cần đăng ký

DEV

Thử ngay một câu

Vì sao không dùng double cho số tiền? Dùng gì?

Bước 1: tự trả lời trong đầu. Bước 2: mở đáp án mẫu. Bước 3: tự chấm "trả lời được" hoặc "chưa chắc".

Xem đáp án mẫu
  • Kiểm: lỗi cơ bản nhưng rất hay gặp.
  • Đáp án: 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) nên lệch khi cộng dồn. Dùng BigDecimal / decimal hoặc lưu đơn vị nhỏ nhất dạng số nguyên.
  • Điểm cộng: với BigDecimal, so sánh bằng compareTo, không dùng equals.

10 câu tự kiểm

DEV

1. Mô tả cấu trúc một message ISO 8583.

Xem đáp án mẫu
  • 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.

DEV

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?

Xem đáp án mẫu
  • 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.

DEV

3. Vì sao không dùng double cho số tiền? Dùng gì?

Xem đáp án mẫu
  • 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).

DEV

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?

Xem đáp án mẫu
  • 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ụ.

Xem đáp án mẫu
  • 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).

BA

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

Xem đáp án mẫu
  • 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ể.

BA

7. Đối soát là gì? Có những loại lệch nào?

Xem đáp án mẫu
  • 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.

Xem đáp án mẫu
  • 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.

TESTER

9. Kiểm thử mã VietQR thế nào?

Xem đáp án mẫu
  • 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.

TESTER

10. Log ứng dụng có in số thẻ đầy đủ. Bạn báo lỗi mức độ nào? Vì sao?

Xem đáp án mẫu
  • 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).

Cách dùng

  1. 1

    Tự trả lời

    Đọc câu hỏi, trả lời trong đầu hoặc nói to.

  2. 2

    Mở đáp án mẫu

    So với đáp án và phần điểm cộng.

  3. 3

    Tự chấm

    Làm đủ 10 câu để nhận danh sách cần ôn.

Nội dung soạn từ tài liệu và chuẩn công khai (ISO 8583, EMVCo QR, tài liệu công bố của NAPAS/NHNN). Không dùng tài liệu nội bộ của bất kỳ ngân hàng nào. Không cam kết đỗ phỏng vấn. Trang chỉ đếm ẩn danh số lượt (xem trang, làm xong bài, bấm nút) theo kênh; không lưu câu trả lời, không thu email hay tên.