CV/CVCC Phát triển hệ thống Quản trị tài chính - K.CNTT

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
2. Code mới ghi vào cả cột cũ và mới.
3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
5. Contract: bỏ cột cũ ở một lần deploy sau.

Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

JOIN quyết định giữ lại những dòng nào khi ghép hai bảng theo điều kiện.

• INNER JOIN: chỉ giữ dòng khớp ở cả hai bảng.
• LEFT JOIN: giữ mọi dòng bảng trái; bảng phải không khớp thì cột thành NULL.
• RIGHT JOIN: ngược lại với LEFT, ít dùng vì có thể đổi chỗ bảng.
• FULL OUTER JOIN: giữ tất cả dòng của cả hai (MySQL không hỗ trợ trực tiếp, phải UNION hai LEFT JOIN).

Ví dụ tìm khách chưa từng đặt hàng:

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

Hay sai: đặt điều kiện lọc bảng phải trong WHERE (vd. WHERE o.status = 'paid') làm LEFT JOIN biến thành INNER JOIN; điều kiện đó phải để trong ON.

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.

BA là cầu nối giữa business và đội phát triển: hiểu vấn đề của khách hàng, chuyển thành yêu cầu rõ ràng để team làm đúng thứ cần làm.

• Thu thập và làm rõ yêu cầu (phỏng vấn, workshop, đọc tài liệu, quan sát quy trình hiện tại).
• Phân tích, mô hình hoá: quy trình nghiệp vụ, use case, user story, acceptance criteria.
• Viết tài liệu (BRD, SRS hoặc backlog trên Jira/Confluence), phối hợp làm wireframe.
• Giải đáp cho dev và tester, review kết quả, hỗ trợ UAT.
• Quản lý thay đổi yêu cầu.

Người phỏng vấn muốn nghe: bạn hiểu BA không phải "người ghi chép" mà là người đặt câu hỏi "tại sao" để tìm ra nhu cầu thật. Nếu bạn chuyển từ tester, dev hay ngành khác sang, nói rõ kinh nghiệm cũ giúp gì cho vai trò BA.

WHERE lọc từng dòng trước khi gom nhóm; HAVING lọc sau GROUP BY, nên dùng được hàm tổng hợp như COUNT, SUM.

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

SELECT department_id, AVG(salary) AS avg_salary
FROM employees
WHERE status = 'active'
GROUP BY department_id
HAVING AVG(salary) > 20000000;

• Vì SELECT chạy sau WHERE, bạn không dùng được alias của SELECT trong WHERE (đa số DB).
• Điều kiện không cần hàm tổng hợp thì nên để ở WHERE để giảm số dòng phải gom nhóm.

Người phỏng vấn muốn nghe: bạn hiểu thứ tự logic, từ đó giải thích được vì sao alias hoặc aggregate dùng sai chỗ bị lỗi.

Index là cấu trúc dữ liệu phụ (thường là B-Tree) giúp tìm dòng theo giá trị cột mà không phải quét cả bảng, đổi lại tốn dung lượng và làm chậm thao tác ghi.

• B-Tree hợp với so sánh =, <, >, BETWEEN, ORDER BY, LIKE 'abc%'.
• Mỗi INSERT/UPDATE/DELETE phải cập nhật thêm mọi index liên quan.
• Cột có độ chọn lọc thấp (vd. gender, is_deleted) đánh index riêng thường ít tác dụng.

Không nên đánh index tràn lan: chỉ thêm cho cột hay xuất hiện trong WHERE, JOIN, ORDER BY của các query quan trọng, rồi kiểm tra bằng EXPLAIN.

Hay sai: bọc cột trong hàm, vd. WHERE YEAR(created_at) = 2026 hoặc LOWER(email) = ..., khiến index thường trên cột đó không được dùng. Hãy viết lại thành khoảng thời gian hoặc dùng index trên biểu thức.

Transaction là một nhóm thao tác được thực hiện như một đơn vị: hoặc tất cả thành công (COMMIT), hoặc không có gì xảy ra (ROLLBACK).

• Atomicity: không có trạng thái làm dở dang.
• Consistency: sau transaction dữ liệu vẫn thoả ràng buộc (khoá ngoại, unique, check).
• Isolation: các transaction chạy đồng thời không thấy dữ liệu dở dang của nhau, mức độ tuỳ isolation level.
• Durability: đã commit thì không mất dù server sập (nhờ write-ahead log / redo log).

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;

Người phỏng vấn muốn nghe: một ví dụ thực tế như chuyển tiền hoặc trừ tồn kho, và bạn biết giữ transaction ngắn, không gọi API bên ngoài khi đang mở transaction.

Câu này kiểm tra bạn có tìm hiểu không hay chỉ rải CV. Nối ba thứ: công ty, vị trí, và bạn.

• Tìm hiểu trước: sản phẩm, khách hàng, công nghệ, tin tức gần đây, đánh giá của nhân viên cũ và hiện tại.
• Chọn một hai điểm cụ thể bạn thật sự quan tâm: sản phẩm bạn từng dùng, bài toán kỹ thuật, quy mô người dùng, văn hoá làm việc.
• Nối với kinh nghiệm hoặc mục tiêu của bạn.

Câu mẫu: "Em có dùng ứng dụng của bên mình và thấy phần thanh toán rất mượt. Trong JD có nói team đang mở rộng hệ thống xử lý giao dịch, đúng mảng em đã làm hai năm. Em nghĩ mình đóng góp được ngay và cũng học được nhiều ở quy mô lớn hơn."

Hay sai: "Vì công ty lớn, lương tốt" hoặc khen chung chung áp vào công ty nào cũng được.