Từ data scientist sang FDE: giữ tư duy debug, học làm chủ cả hệ thống

Thử hình dung thế này. Bạn train xong một model dự đoán khách rời bỏ, AUC đẹp, notebook gọn, rồi bàn giao cho team platform. Ba tuần sau model vẫn nằm yên đó, vì chưa ai nối nó vào hệ thống đăng nhập của khách hàng.

Ở vai trò FDE, người phải nối nó vào chính là bạn. Tin tốt là con đường này có thật: tài liệu hướng nghiệp của FDE Academy nêu tên ML engineer là một hướng chuyển sang Forward Deployed Engineering khả thi ở các công ty AI.

Một phân tích tin tuyển dụng năm 2026 trên Cloud Authority cũng ghi nhận nhiều vị trí FDE nhắc thẳng tới kinh nghiệm machine learning hoặc phát triển agent.

Tin khó hơn: theo hướng dẫn phỏng vấn FDE năm 2026 của Sundeep Teki, vòng phỏng vấn kiểm tra cùng lúc bốn thứ thường được đánh giá riêng rẽ. Đó là tách nhỏ vấn đề, viết code, thấu hiểu khách hàng và tinh thần làm chủ. Kỹ năng modeling chỉ là vé vào cửa. Câu hỏi thật sự là giữ lại gì và học thêm gì.

Những gì bạn mang theo đáng giá hơn bạn nghĩ

Nền tảng ML là lợi thế trực tiếp, nhất là khi các công ty AI cần người hiểu model, pipeline và ứng dụng LLM được deploy rồi tích hợp thế nào. Bạn biết vì sao một model tụt chất lượng, biết leakage trông ra sao, biết đọc phân phối dữ liệu. Đó là những phản xạ bạn đã có sẵn, không phải học lại từ đầu.

Thứ đáng giữ thứ hai là tư duy debug. Hướng dẫn chuyển nghề từ data engineer sang FDE của FDE Academy nói thẳng rằng tư duy debug mang sang được. Khi bạn truy ra vì sao một feature bỗng toàn null, bạn đang làm đúng việc một FDE làm khi tích hợp với hệ thống khách hàng bị lỗi: đặt giả thuyết, khoanh vùng, kiểm chứng.

Nhưng cũng hướng dẫn đó chỉ ra điểm khác biệt cốt lõi: dân data thường làm việc nội bộ, còn FDE làm việc trực tiếp với khách hàng. Tư duy debug giữ nguyên, nhưng số hệ thống bạn phải hiểu thì phải rộng ra nhiều lần.

Khoảng trống nằm quanh model, không nằm trong model

Cloud Authority, dẫn lại The Pragmatic Engineer, phân biệt hai vai trò khá gọn. Developer xây một năng lực cho nhiều khách hàng, còn FDE đi sâu vào một khách hàng với nhiều năng lực. Khi đứng về phía một khách hàng như vậy, train model chỉ còn là một việc trong số rất nhiều việc bạn tự tay làm.

Tin tuyển Forward Deployed Software Engineer của Palantir ở Warsaw mô tả công việc là làm trong nhóm nhỏ, ít người giám sát, và tự lo trọn từ đầu đến cuối những dự án có rủi ro cao. Cùng tin đó yêu cầu một người code giỏi, thành thạo các ngôn ngữ như Python, Java, C++. Kỹ năng thống kê không thay được yêu cầu này.

Một bài toán mơ hồ, tách từng lớp

Teki xếp tách nhỏ vấn đề là kỹ năng quan trọng nhất trong phỏng vấn FDE. Vòng technical deep dive kéo dài khoảng 60 phút, không viết code, xoay quanh một bài toán đời thực được nêu rất mơ hồ. Đây chính là chỗ dân ML hay vấp, vì phản xạ đầu tiên của người làm ML thường là chọn model.

Lấy một đề giả định: “Một chuỗi phòng khám muốn dùng AI để bệnh nhân bớt phải chờ.” Data scientist sẽ muốn nhảy ngay vào việc dự đoán thời gian chờ bằng gradient boosting. Người làm FDE thì tách bài toán theo thứ tự khác:

1. Người dùng: ai cảm thấy chờ lâu? Bệnh nhân, lễ tân hay bác sĩ?
2. Quyết định: ai sẽ hành động khác đi nếu có thông tin tốt hơn? (lễ tân xếp lịch lại? phòng khám mở thêm ca?)
3. Dữ liệu: lịch hẹn, giờ check-in, giờ khám nằm ở đâu? Ai được phép truy cập?
4.

Ràng buộc: dữ liệu y tế -> HIPAA, chạy trong VPC của khách,
   đăng nhập qua SSO sẵn có
5. Tuần đầu tiên: dashboard giờ chờ theo khung giờ, chưa cần model
6. Sau đó mới tới ML: dự báo tải theo giờ để gợi ý xếp lịch

Chú ý rằng model xuất hiện ở bước cuối. Lớp thứ tư cũng không phải ngẫu nhiên: Teki cho biết vòng system design của FDE gắn với hoàn cảnh từng khách hàng, với các chủ đề như VPC, SSO, HIPAA/SOC2.

Nếu trong phỏng vấn bạn nói ra được rằng dữ liệu này không được rời khỏi hạ tầng của khách, bạn đang trả lời đúng loại câu hỏi mà vòng system design này nhắm tới, thay vì chỉ vẽ kiến trúc model.

Khi deployment hỏng lúc 2 giờ sáng

Teki minh họa tinh thần làm chủ bằng một cảnh rất cụ thể: deployment hỏng lúc 2 giờ sáng, và bạn không mở ticket. Với người quen bàn giao model cho team khác, đây là thay đổi lớn nhất về tâm thế.

Tiếp tục ví dụ phòng khám, thử hình dung endpoint dự báo bỗng trả lỗi 401. Phản xạ cũ là báo team platform. Phản xạ FDE là tự lần theo: token SSO có vừa bị xoay vòng không, service account còn quyền đọc bảng lịch hẹn không. Sửa xong, bạn viết lại nguyên nhân và thêm cảnh báo để lần sau phát hiện sớm hơn.

Tư duy debug vẫn là của bạn, chỉ có phạm vi giờ là cả hệ thống.

Lộ trình luyện tập: thuật toán, một project thật, một CV mới

Đầu tiên là thuật toán. Teki mô tả vòng coding ở mức LeetCode medium nhưng được đặt trong tình huống khách hàng, và có ứng viên kể từng gặp bài BFS và graph ở Palantir. Notebook không luyện được phản xạ này, nên bạn cần giải bài đều đặn và tập nói to cách bạn nghĩ.

Thứ hai là một project end-to-end. FDE Academy khuyên xây project có cloud, API, authentication, database và monitoring. Cách nhanh nhất với dân ML là lấy chính một model cũ của bạn, bọc thành service có đăng nhập, ghi log dự đoán vào database, dựng dashboard theo dõi độ trễ và drift.

Thêm một lớp RAG nhỏ cũng đáng làm, vì danh sách kỹ năng Teki đưa ra gồm Python, LLM/RAG, cloud, SQL/pipeline và full-stack.

Thứ ba là CV. Theo Teki, khả năng ship end-to-end quan trọng hơn tên tuổi công ty. Với developer Việt Nam chưa từng làm ở công ty lớn, đây là tin tốt: mỗi dòng kinh nghiệm nên kể bạn giải vấn đề gì cho ai, ship hệ thống gì, chạy thật ra sao.

Khi đọc JD, hãy tìm các cụm như “end-to-end”, “customer-facing”, “minimal supervision” để biết vị trí đó đang cần đúng phần bạn vừa bổ sung.

Những cái bẫy quen thuộc của dân ML

Bẫy phổ biến nhất là mở đầu câu trả lời bằng tên model. Người phỏng vấn muốn nghe bạn hỏi lại về người dùng và quyết định, không phải nghe bạn so sánh XGBoost với transformer.

Bẫy thứ hai là portfolio toàn notebook. Notebook chứng minh bạn phân tích giỏi, nhưng không chứng minh được bạn deploy, xác thực người dùng hay theo dõi được một hệ thống. Bẫy thứ ba là xem nhẹ vòng thuật toán vì nghĩ mình “làm AI”. Vòng code vẫn ở mức LeetCode medium, và tin tuyển của Palantir vẫn yêu cầu một người code giỏi.

Bẫy cuối cùng là nói về accuracy thay vì nói về kết quả của khách hàng. Phòng khám không mua AUC, họ mua những buổi sáng bệnh nhân bớt phải chờ.

Bài tập cho tuần này: chọn một model bạn đã từng làm, viết ra sáu lớp tách nhỏ như ví dụ phòng khám cho một khách hàng tưởng tượng, rồi tự hỏi lớp nào bạn chưa từng tự tay làm. Lớp đó là thứ cần học tiếp.