Engineering Manager (Banking/Fintech)

Đây là bài toán lost update. Có hai hướng chính, chọn theo mức độ tranh chấp:

• Optimistic locking: thêm field @Version. Khi update, Hibernate kèm điều kiện where version = ?; nếu người khác đã sửa trước, bạn nhận OptimisticLockException và có thể retry hoặc báo lỗi. Hợp khi tranh chấp ít.
• Pessimistic locking: @Lock(LockModeType.PESSIMISTIC_WRITE) sinh SELECT ... FOR UPDATE, giữ khoá đến hết transaction. Hợp khi tranh chấp nhiều, đổi lại throughput giảm và có nguy cơ deadlock.
• Đơn giản nhất cho tồn kho: update có điều kiện ngay trong DB:

UPDATE product SET stock = stock - 1
WHERE id = ? AND stock > 0;

Kiểm tra số dòng bị ảnh hưởng: bằng 0 nghĩa là hết hàng.

Hay sai: dùng synchronized trong code Java. Nó vô dụng khi chạy nhiều instance, và cũng không bảo vệ được dữ liệu ở DB.

IoC container của Spring tạo và quản lý các bean, rồi "tiêm" phụ thuộc vào class cần dùng, thay vì class tự new. Nhờ vậy code ít phụ thuộc cứng, dễ thay implementation và dễ test.

Constructor injection được khuyên dùng vì:

• Field có thể là final, object luôn ở trạng thái đầy đủ sau khi tạo.
• Test unit không cần Spring: chỉ cần new OrderService(mockRepo).
• Constructor quá nhiều tham số là dấu hiệu class đang ôm nhiều việc.
• Class chỉ có một constructor thì không cần ghi @Autowired.

Nên nói thêm về scope: mặc định bean là singleton (một instance cho cả context), ngoài ra có prototype, request, session.

Hay sai: để state thay đổi được (ví dụ biến đếm, list) trong bean singleton. Nhiều request chạy song song sẽ dùng chung và gây race condition.

Spring tạo proxy bao quanh bean. Khi gọi method có @Transactional qua proxy, proxy mở transaction, gọi method thật, rồi commit hoặc rollback.

Những lý do hay gặp khiến nó "không ăn":

• Self-invocation: method A trong cùng class gọi this.b() có @Transactional, lời gọi không đi qua proxy.
• Method là private hoặc final: proxy không chặn được lời gọi.
• Mặc định chỉ rollback với unchecked exception và Error. Checked exception vẫn commit, trừ khi khai báo rollbackFor = Exception.class.
• Exception bị catch và nuốt bên trong method.

Nên biết thêm propagation (REQUIRED, REQUIRES_NEW) và readOnly = true cho các truy vấn chỉ đọc.

Người phỏng vấn muốn nghe: bạn giải thích được bằng cơ chế proxy, không chỉ liệt kê lỗi.

Star schema là mô hình dữ liệu cho phân tích: một bảng fact ở giữa nối với nhiều bảng dimension xung quanh, giúp truy vấn đơn giản và nhanh.

• Fact: ghi các sự kiện đo đếm được (đơn hàng, lượt xem), chứa số đo (số tiền, số lượng) và khoá ngoại tới dimension. Thường rất nhiều dòng.
• Dimension: mô tả ngữ cảnh (khách hàng, sản phẩm, ngày, cửa hàng), ít dòng, nhiều cột thuộc tính.
• Phải xác định rõ grain: mỗi dòng fact là gì (một đơn hay một dòng sản phẩm trong đơn).

Hay sai: trộn nhiều grain trong một bảng fact, dẫn đến cộng trùng khi tổng hợp.

SCD là cách xử lý khi thuộc tính của dimension thay đổi theo thời gian, ví dụ khách hàng chuyển thành phố hoặc đổi hạng thành viên.

• Type 1: ghi đè giá trị cũ. Đơn giản nhưng mất lịch sử; báo cáo quá khứ hiển thị theo giá trị mới.
• Type 2: thêm dòng mới cho mỗi thay đổi, kèm valid_from, valid_to, is_current và surrogate key. Giữ được lịch sử, fact trỏ đúng phiên bản tại thời điểm phát sinh.

Chọn Type 2 khi nghiệp vụ cần phân tích theo trạng thái lúc xảy ra (doanh thu theo hạng khách hàng lúc mua).

Hay sai: join fact với dimension Type 2 mà quên điều kiện thời gian hoặc is_current, làm nhân bản dòng.

Bắt đầu từ cách rẻ và nhanh nhất, chỉ nâng cấp khi đo được là chưa đủ.

• Prompting: thử đầu tiên; chỉ dẫn rõ, ví dụ mẫu (few-shot), định dạng đầu ra có cấu trúc.
• RAG: khi mô hình thiếu kiến thức (tài liệu nội bộ, dữ liệu thay đổi thường xuyên), cần trích dẫn nguồn.
• Fine-tuning: khi cần đổi hành vi ổn định (văn phong, định dạng, tác vụ hẹp lặp lại), hoặc muốn dùng mô hình nhỏ rẻ hơn thay mô hình lớn. Kỹ thuật như LoRA giảm chi phí.

Fine-tuning không phải cách tốt để nhồi kiến thức mới hay thay đổi liên tục; RAG hợp hơn.

Người phỏng vấn muốn nghe: có bộ đánh giá trước để so sánh các phương án bằng số liệu.

N+1 xảy ra khi bạn lấy N bản ghi bằng 1 query, rồi mỗi lần truy cập quan hệ lazy lại phát sinh thêm 1 query. Ví dụ lấy 100 đơn hàng, rồi gọi order.getCustomer() trong vòng lặp là thành 101 query.

Cách xử lý:

• JOIN FETCH trong JPQL: select o from Order o join fetch o.customer.
• @EntityGraph(attributePaths = "customer") trên method của repository.
• @BatchSize hoặc hibernate.default_batch_fetch_size để gom lazy load thành câu IN (...).
• Với màn hình chỉ đọc, trả thẳng DTO projection thay vì entity.

Phát hiện bằng cách bật log SQL (spring.jpa.show-sql hoặc log của Hibernate) khi dev, hoặc dùng thống kê của Hibernate.

Hay sai: đổi sang FetchType.EAGER cho xong. Cách này chỉ đổi chỗ lỗi và làm mọi truy vấn khác nặng hơn. Fetch join nhiều collection cùng lúc cũng dễ gây tích Descartes.

Hai vùng chính: stack (mỗi thread một stack, chứa biến cục bộ và tham chiếu) và heap (chứa object, dùng chung). Ngoài ra có Metaspace chứa thông tin class.

• GC tìm các object không còn được tham chiếu từ "GC roots" (biến trên stack, field static...) và thu hồi.
• Heap chia theo thế hệ: object mới nằm ở young generation, sống lâu thì được chuyển lên old generation.
• G1 là GC mặc định; ZGC hợp khi cần pause rất ngắn với heap lớn.

Java vẫn leak khi object không dùng nữa mà vẫn còn tham chiếu:

• Cache hoặc static Map chỉ thêm, không bao giờ xoá.
• ThreadLocal không remove() trong thread pool.
• Listener đăng ký mà không huỷ.

Người phỏng vấn muốn nghe: phân biệt được OutOfMemoryError: Java heap space với lỗi Metaspace, và biết dùng heap dump để tìm ai đang giữ object.

Virtual thread là thread nhẹ do JVM quản lý, được gắn lên một số ít platform thread (carrier). Khi gặp I/O blocking, nó nhả carrier để chạy việc khác, nên bạn có thể có hàng trăm nghìn thread mà vẫn viết code blocking dễ đọc.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    ids.forEach(id -> executor.submit(() -> callApi(id)));
}

• Hợp với tải nhiều I/O (gọi DB, HTTP). Không giúp gì với tác vụ nặng CPU.
• Spring Boot 3.2+ bật bằng spring.threads.virtual.enabled=true.
• Không đưa virtual thread vào pool: tạo mới cho mỗi task là cách dùng đúng.
• Giới hạn tài nguyên (connection pool DB) vẫn là giới hạn thật; dùng Semaphore nếu cần.
• Trên Java 21, blocking bên trong synchronized có thể "pin" carrier; các bản JDK mới hơn đã cải thiện. Cẩn thận với ThreadLocal chứa object lớn.

Người phỏng vấn muốn nghe: virtual threads tăng throughput, không làm từng request nhanh hơn.

Người phỏng vấn muốn biết bạn tự quản lý được và giao tiếp chủ động khi không ngồi cạnh team.

• Cập nhật tiến độ thường xuyên trên công cụ chung (ticket, kênh chat của team), không để người khác phải hỏi.
• Viết rõ ràng: câu hỏi có ngữ cảnh, ghi lại kết quả thảo luận.
• Có khung giờ làm việc ổn định, phản hồi trong giờ làm, báo trước khi vắng.
• Dùng ngày lên văn phòng (nếu hybrid) cho thảo luận, brainstorm, gặp gỡ team.

Câu mẫu: "Team cũ của em làm hybrid hai ngày ở văn phòng. Những ngày remote em cập nhật trạng thái task mỗi sáng và cuối ngày, vướng gì thì gọi nhanh 10 phút thay vì nhắn qua lại."