[HCM] Bridge System Engineer - AI Solutions (N1)

Tách lỗi theo từng khâu của pipeline, kiểm tra từ dưới lên.

1. Dữ liệu: tài liệu đã được nạp chưa, trích xuất từ PDF/bảng có bị vỡ không, có phiên bản cũ mâu thuẫn không.
2. Chunking: thông tin cần thiết có bị cắt đôi giữa hai chunk không.
3. Truy xuất: log các chunk lấy về cho câu hỏi đó; đúng chunk có nằm trong top-k không. Thử hybrid search, rerank, viết lại câu hỏi.
4. Sinh: chunk đúng đã có trong prompt mà vẫn sai thì xem prompt, thứ tự đặt ngữ cảnh, quá nhiều ngữ cảnh nhiễu.
5. Thêm ca này vào bộ eval để tránh tái diễn.

Người phỏng vấn muốn nghe: có tracing để xem từng bước, không đoán mò.

Agent cho LLM tự quyết định gọi tool theo nhiều bước, nên lỗi và rủi ro tăng theo số bước; cần giới hạn quyền và kiểm soát chặt.

• Tool rõ ràng: mô tả và schema tham số chặt, kiểm tra đầu vào bằng code trước khi thực thi.
• Quyền tối thiểu: tool chỉ đọc khi có thể; thao tác ghi, xoá, chuyển tiền cần người xác nhận.
• Prompt injection: nội dung lấy từ web, email, tài liệu là dữ liệu không tin cậy; không để nó điều khiển tool nhạy cảm.
• Giới hạn số bước, timeout, ngân sách token; xử lý lỗi tool và cho phép thử lại có kiểm soát.
• Log và tracing toàn bộ chuỗi hành động để audit.
• Đánh giá theo tỷ lệ hoàn thành tác vụ trên bộ kịch bản.

Người phỏng vấn muốn nghe: workflow cố định thường đủ; chỉ dùng agent tự do khi thật cần.

Overfitting là mô hình học thuộc cả nhiễu của tập train nên kém trên dữ liệu mới; underfitting là mô hình quá đơn giản, kém ngay cả trên tập train.

Phát hiện: so sánh lỗi train và validation. Train tốt mà validation kém là overfit; cả hai đều kém là underfit.

Khắc phục overfitting:

• Thêm dữ liệu, data augmentation.
• Regularization (L1/L2, dropout, weight decay), early stopping.
• Giảm độ phức tạp mô hình, bớt đặc trưng nhiễu.

Khắc phục underfitting: mô hình mạnh hơn, đặc trưng tốt hơn, train lâu hơn, giảm regularization.

Người phỏng vấn muốn nghe: liên hệ với bias-variance trade-off và dùng cross-validation khi dữ liệu ít.

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.

OSI có 7 tầng: Physical, Data Link, Network, Transport, Session, Presentation, Application. Thực tế người ta hay dùng mô hình TCP/IP 4 tầng, nhưng vẫn gọi tên theo OSI.

• Switch (L2): chuyển frame theo địa chỉ MAC; switch L3 có thêm định tuyến.
• Router (L3): định tuyến gói theo địa chỉ IP giữa các mạng.
• Firewall: lọc ở L3/L4 (IP, port); firewall thế hệ mới đọc được tới L7 (ứng dụng, URL).
• TCP/UDP ở L4; HTTP, DNS ở L7.

Người phỏng vấn muốn nghe: dùng OSI để khoanh vùng sự cố, ví dụ "ping được nhưng không mở được web" là vấn đề từ L4 trở lên.

Train để học tham số, validation để chọn mô hình và siêu tham số, test để ước lượng hiệu năng thật lúc cuối và chỉ dùng một lần.

Data leakage là khi thông tin không có ở thời điểm dự đoán lọt vào lúc train, khiến kết quả offline đẹp nhưng chạy thật thì kém.

Ví dụ hay gặp:

• Chuẩn hoá hoặc chọn đặc trưng trên toàn bộ dữ liệu trước khi chia tập.
• Dữ liệu chuỗi thời gian chia ngẫu nhiên thay vì theo thời gian.
• Đặc trưng chứa thông tin từ tương lai hoặc từ chính nhãn (như "ngày huỷ hợp đồng" khi dự đoán khách rời bỏ).
• Cùng một người dùng xuất hiện ở cả train và test.

Hay sai: tinh chỉnh nhiều lần dựa trên tập test, biến nó thành validation.

Precision là trong các ca mô hình báo dương, bao nhiêu ca đúng; recall là trong các ca dương thật, mô hình bắt được bao nhiêu; F1 là trung bình điều hoà của hai chỉ số.

Ví dụ phát hiện gian lận với 1% giao dịch gian lận: mô hình đoán "không gian lận" cho mọi giao dịch đạt accuracy 99% nhưng recall bằng 0.

• Ưu tiên recall khi bỏ sót đắt (bệnh, gian lận); ưu tiên precision khi báo nhầm đắt (chặn nhầm giao dịch).
• Dùng PR-AUC thay vì chỉ ROC-AUC khi lớp dương rất hiếm.
• Chọn ngưỡng quyết định theo chi phí nghiệp vụ, không mặc định 0.5.

Người phỏng vấn muốn nghe: gắn metric với hậu quả kinh doanh.

"In three to five years, I see myself as a senior engineer who can design and own a major part of the system. I'd also like to mentor junior developers, because I enjoyed doing that in my current team. To get there, I'm studying system design and taking on more responsibility in technical discussions. I hope to grow in that direction with a company like yours."

Mẹo: dùng "I see myself…", "I'd like to…", "I hope to…". Mục tiêu nên thực tế và liên quan tới công việc đang ứng tuyển. Người Việt hay nói "I want to become a leader" quá chung chung; nên nói rõ leader làm việc gì.

Chọn sai lầm thật, có hậu quả vừa phải, nhận trách nhiệm rõ ràng, và nhấn mạnh việc bạn đã thay đổi sau đó.

Cấu trúc: chuyện gì xảy ra, phần lỗi của bạn, bạn khắc phục ngay thế nào, bài học và thay đổi lâu dài.

Câu mẫu: "Có lần em deploy một thay đổi cấu hình lên production vào chiều thứ Sáu mà không kiểm tra kỹ trên staging, làm một tính năng lỗi khoảng một giờ. Em báo ngay cho lead, rollback và viết báo cáo sự cố. Sau đó em đề xuất checklist trước deploy và quy ước hạn chế deploy cuối tuần; team áp dụng tới giờ."

Hay sai: kể một "thất bại" thực ra là khoe, đổ lỗi cho người khác, hoặc nói mình chưa từng thất bại.