Backend engineer chuyển sang FDE: mang theo gì, học thêm gì và kể lại kinh nghiệm ra sao
Hai năm viết code production đã cho bạn phần lớn hành trang. Nhiều người vẫn trượt vì một thói quen của dân backend: vẽ kiến trúc trước khi hỏi khách hàng thế nào là xong.
Tóm tắt nhanh
- Có từ hai năm viết backend production trở lên là bạn đã có phần lớn kỹ năng FDE cần, và debugging cùng observability là phần dùng lại được nhiều nhất.
- Ba khoảng trống chính là giao tiếp với khách hàng, hiểu cách hệ thống AI vận hành và scoping. Nhiều người trượt vì không làm được technical discovery chứ không phải vì code kém.
- Hãy kể lại kinh nghiệm theo kết quả mang lại cho khách hàng: chuyển từ 'tôi đã xây X' sang 'tôi đã triển khai X và giải quyết Y cho khách hàng Z'.
Thử hình dung một vòng phỏng vấn FDE. Người phỏng vấn đưa ra đề bài: một công ty logistics muốn dùng AI để xử lý email khiếu nại của khách hàng. Nếu bạn làm backend, phản xạ đầu tiên rất có thể là cầm bút vẽ queue, chọn database rồi phác API.
Nhiều người trượt đúng ở chỗ đó. Hướng dẫn chuyển nghề của fde.academy nhận xét rằng backend engineer hay rớt vòng này vì nhảy vào kiến trúc trước khi làm rõ tiêu chí thành công. Điều trớ trêu là cũng hướng dẫn ấy khẳng định ai đã viết backend production từ hai năm trở lên thì đã có phần lớn những gì một FDE cần.
Khoảng cách giữa hai vai trò hẹp hơn nhiều người nghĩ, nhưng nó nằm đúng ở mảng dân backend ít được luyện nhất. Đây cũng là lúc đáng để lấp nó: The Pragmatic Engineer ghi nhận nhu cầu tuyển FDE ở Google, OpenAI và Anthropic đang rất lớn.
Bạn mang theo nhiều hơn bạn nghĩ
Paraform mô tả bộ kỹ năng lõi của FDE gồm năm mảng: một ngôn ngữ backend, hạ tầng cloud, data engineering, applied AI và giao tiếp với khách hàng. Người làm backend vài năm thường đã nắm chắc ba mảng đầu, ít nhất ở mức đủ dùng.
Còn theo fde.academy, thứ dùng lại được nhiều nhất là observability và debugging. Ở chỗ khách hàng, bạn phải gỡ lỗi trong hệ thống do người khác xây, log thiếu, quyền truy cập hạn chế, trong khi ai cũng chờ bạn trả lời.
Những lần trực on-call lúc nửa đêm chính là bài tập cho tình huống đó.
Đọc tin tuyển dụng của Palantir và Anthropic, bạn sẽ thấy cùng một đòi hỏi. Palantir muốn FDSE tự lo trọn vẹn những dự án có rủi ro cao từ đầu đến cuối.
Tin tuyển FDE Applied AI của Anthropic yêu cầu ứng viên làm việc bên trong hệ thống của khách để dựng ứng dụng production trên các model Claude. Cả hai đều đòi một người ship được code chạy thật trong môi trường không phải của mình, và đó là việc backend engineer vẫn làm hằng ngày.
Ba khoảng trống bạn phải lấp
fde.academy chỉ ra ba khoảng trống: giao tiếp với khách hàng, hiểu biết về hệ thống AI/ML, và scoping một đợt deployment, tức là chốt tiêu chí thành công trước khi tính đến kiến trúc. Bài hướng dẫn của Scaler nói thẳng hơn: phần lớn kỹ sư không chuyển được sang FDE vì không làm nổi technical discovery, chứ không phải vì code kém.
Khoảng trống về AI chỉ thật sự lớn nếu bạn chủ yếu làm dịch vụ CRUD. Khi đó, theo fde.academy, bạn cần nắm được hệ thống AI vận hành khác đi như thế nào.
Với một API CRUD, cùng input thì cho cùng output và lỗi thì có stack trace. Một ứng dụng LLM có thể trả lời sai mà vẫn trôi chảy, nên bạn cần một bộ eval chứ unit test thôi là không đủ.
Ngoài ba khoảng trống ấy, tin tuyển dụng còn nêu thêm một yêu cầu đáng để tâm. Anthropic đòi hỏi tinh thần chủ động cao (high agency) và khả năng xoay xở trong sự mơ hồ của những tổ chức phức tạp. Ở công ty sản phẩm, ticket đến tay bạn khi đã có người làm rõ yêu cầu. Ở chỗ khách hàng, việc làm rõ đó là của bạn.
Một dự án, hai cách kể
fde.academy khuyên viết lại CV theo kết quả chứ không theo tính năng. Scaler gợi ý một khung kể chuyện cho phỏng vấn: chuyển từ “tôi đã xây X” sang “tôi đã triển khai X, giải quyết Y cho khách hàng Z”. Thử áp dụng cho một dự án giả định rất quen thuộc: service đồng bộ đơn hàng với hệ thống của một đối tác.
| Yếu tố | Kể kiểu builder | Kể kiểu FDE |
|---|---|---|
| Câu mở đầu | Xây service đồng bộ đơn hàng bằng Go, Kafka, Postgres | Đội vận hành phải nhập tay đơn từ hệ thống đối tác và thường xuyên lệch số liệu |
| Tiêu chí xong | Không nhắc tới | Thống nhất với trưởng nhóm vận hành: không còn đơn nào phải nhập tay |
| Phần khó | Retry và idempotency | API của đối tác trả trùng sự kiện. Thêm tracing để chứng minh lỗi nằm phía họ |
| Kết quả | Service chạy ổn định | [số liệu thật của bạn: giờ nhập tay tiết kiệm được, tỷ lệ lệch đơn trước và sau] |
Công nghệ bạn dùng vẫn nằm trong câu chuyện ở cột bên phải, nhưng nó phục vụ cho vấn đề của khách. Đừng bịa con số. Nếu chưa từng đo, hãy hỏi lại đội cũ hoặc nói rõ đó là ước lượng.
Bạn chưa từng có khách hàng bên ngoài? Một đội nội bộ dùng hệ thống của bạn cũng là khách hàng. Đội vận hành, đội tài chính hay đội data đều tính. Điều nhà tuyển dụng muốn nghe là bạn đã hỏi họ cần gì và đo xem họ có nhận được thứ đó không.
Mười phút đầu quyết định cả vòng decomposition
Theo techinterview.org, một ứng viên mạnh trong vòng decomposition dành mười phút đầu để đặt câu hỏi về người dùng và về định nghĩa của chữ “xong”.
Vòng này chấm khả năng chia nhỏ vấn đề có cấu trúc, sự thấu hiểu người dùng, cách lập luận với dữ liệu và cách scoping. Bài viết cảnh báo rằng nếu chỉ luyện thuật toán, bạn đang ôn phần ít quan trọng nhất của bài thi.
Quay lại đề bài email khiếu nại. Thay vì vẽ kiến trúc, bạn có thể mở đầu bằng vài câu hỏi như sau:
“Ai đang đọc những email này, và họ mất bao lâu cho mỗi email? Một tháng có khoảng bao nhiêu email, gồm những loại khiếu nại nào? Nếu sáu tuần nữa dự án thành công, anh/chị sẽ nhìn vào con số nào để biết?
Khi AI phân loại sai một khiếu nại nghiêm trọng thì hậu quả là gì? Email nằm ở hệ thống nào, và chúng ta được phép đưa dữ liệu ra ngoài tới đâu?”
Mỗi câu hỏi mở ra một quyết định kỹ thuật về sau. Hậu quả của việc phân loại sai cho bạn biết có cần một người duyệt lại hay không. Nơi lưu dữ liệu cho bạn biết model được chạy ở đâu. Chỉ khi đã có câu trả lời, bạn mới vẽ kiến trúc, và lúc đó bản vẽ của bạn có lý do cho từng ô.
Những lỗi hay gặp khi chuyển nghề
Lỗi đầu tiên là CV toàn tên công nghệ. Một danh sách Kafka, Kubernetes, gRPC cho thấy bạn biết công cụ, nhưng không cho thấy bạn đã giải quyết được vấn đề của ai.
Lỗi thứ hai là giấu đi các sự cố. Câu chuyện về lần bạn lần ra nguyên nhân một đợt outage là bằng chứng tốt nhất cho kỹ năng debugging, đúng thứ fde.academy đánh giá là dùng lại được nhiều nhất. Hãy kể sự cố đó kèm người dùng bị ảnh hưởng và cách bạn trao đổi với họ.
Lỗi thứ ba là thổi phồng kinh nghiệm AI. Nếu bạn mới chỉ làm CRUD, hãy dựng một dự án nhỏ có eval đàng hoàng rồi kể thật về nó. Một câu hỏi đào sâu về chuyện output không ổn định sẽ lộ ra ngay ai chưa từng làm.
Khi đọc tin tuyển dụng, hãy để ý những cụm như “end-to-end”, “customer systems” hay “ambiguity”. Với mỗi cụm, chuẩn bị sẵn một câu chuyện có thật của bạn.
Kỹ năng code đưa bạn tới được bàn phỏng vấn. Nhưng điều khiến người ta tin bạn đứng được trước khách hàng là bạn biết hỏi “xong nghĩa là gì” trước khi bắt tay vào xây.
Bài này có hữu ích không?
Cảm ơn bạn đã góp ý!
7 nguồn
- Backend Engineer to Forward Deployed Engineer: A Complete Transition Guide · 2026-06-02
- How to Transition from Software Engineer to Forward Deployed Engineer · 2026-08-24
- What the forward deployed engineer interview really tests · 2026-08-05
- What is a forward deployed engineer? A complete guide · 2026-09-03
- Forward Deployed Software Engineer (Palantir)
- Forward Deployed Engineer, Applied AI (Anthropic)
- The Pulse: Forward deployed engineering heats up again · 2026-05-14