AI Software Engineer

Xây một bộ đánh giá (eval set) đại diện cho câu hỏi thật, chạy tự động như test hồi quy mỗi khi đổi prompt, mô hình hay cách truy xuất.

• Dữ liệu: câu hỏi thật đã ẩn danh, trường hợp khó, câu hỏi ngoài phạm vi, câu cố tình phá.
• Đánh giá truy xuất: tài liệu đúng có nằm trong top-k không (recall@k).
• Đánh giá câu trả lời: đúng sự thật, bám nguồn, đầy đủ, đúng định dạng; dùng kiểm tra bằng code khi được, LLM-as-judge có rubric rõ, và người chấm mẫu để hiệu chỉnh.
• Sau ra mắt: thu phản hồi người dùng, log và soi các ca thất bại để bổ sung bộ eval.

Hay sai: chỉ thử vài câu bằng tay rồi kết luận "ổn".

Đo trước: chi phí và độ trễ đến từ số token vào/ra, kích thước mô hình, số lần gọi trong một yêu cầu.

• Chọn mô hình: định tuyến, việc dễ cho mô hình nhỏ, việc khó mới gọi mô hình lớn.
• Giảm token: prompt gọn, truy xuất ít đoạn nhưng chính xác hơn (rerank), giới hạn độ dài đầu ra.
• Prompt caching cho phần prompt cố định lặp lại; cache câu trả lời cho câu hỏi trùng.
• Streaming để người dùng thấy chữ sớm, cải thiện độ trễ cảm nhận.
• Gộp việc không gấp thành batch.
• Tự host: quantization, batching động, engine suy luận tối ưu.

Người phỏng vấn muốn nghe: mọi tối ưu đều kiểm tra lại bằng bộ eval để chắc chất lượng không giảm.

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

Chọn theo mô hình truy cập dữ liệu, không theo xu hướng. SQL mạnh ở quan hệ, ràng buộc và transaction; NoSQL mạnh ở schema linh hoạt, mô hình dữ liệu đặc thù hoặc scale ngang dễ hơn.

• Document (MongoDB): dữ liệu dạng cây, đọc nguyên khối theo một khoá, schema thay đổi thường xuyên.
• Key-value (Redis): cache, session, rate limit, bộ đếm, hàng đợi nhỏ; dữ liệu chủ yếu nằm trong RAM.
• Wide-column, time-series, search engine: ghi khối lượng lớn, log, tìm kiếm full-text.

Trade-off: JOIN và transaction nhiều document hạn chế hoặc đắt hơn, ràng buộc dữ liệu chuyển sang tầng ứng dụng, và phải thiết kế theo query ngay từ đầu.

Người phỏng vấn muốn nghe: nhiều hệ thống dùng kết hợp, vd. PostgreSQL làm nguồn sự thật, Redis làm cache. PostgreSQL với JSONB cũng đủ cho nhiều nhu cầu "schema linh hoạt".

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.

Đo trước, tối ưu chỗ tốn nhất trước. Phần lớn trường hợp nút thắt là DB và gọi mạng, không phải tốc độ của Python.

1. Đo: APM hoặc tracing (OpenTelemetry) để biết thời gian nằm ở DB, API ngoài hay code. Profile bằng py-spy (gắn vào process đang chạy) hoặc cProfile.
2. DB: xử lý N+1, thêm index phù hợp, chỉ lấy cột cần (only, values), phân trang.
3. Cache: Redis cho dữ liệu đọc nhiều, ít đổi; nhớ chiến lược invalidate.
4. Việc nặng hoặc không cần trả ngay (gửi email, xuất file): đẩy sang Celery hoặc queue.
5. Gọi nhiều API ngoài: chạy song song, đặt timeout.
6. Cuối cùng mới tới tối ưu thuật toán, hoặc đưa đoạn nặng CPU sang thư viện C hay service khác.

Hay sai: viết lại sang async hoặc đổi ngôn ngữ trước khi biết thời gian thực sự bị tiêu ở đâu.

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.

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.

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.