# FDE và solutions engineer: khác nhau ở chỗ ai phải dậy lúc 2 giờ sáng

> Cả hai đều ngồi cạnh khách hàng và cùng viết code, nhưng chỉ một bên còn chịu trách nhiệm về hệ thống khi hợp đồng đã ký xong từ lâu.

Bản gốc: https://fdetimes.net/vi/bach-khoa/forward-deployed-engineer-vs-solutions-engineer-what-is-the/

Trong cùng một tuần, bạn nhận hai lời mời phỏng vấn. Một tin tuyển "Solutions Engineer", tin còn lại tuyển "Forward Deployed Engineer". Tin nào cũng nhắc đến khách hàng, cũng đòi biết code, cũng hứa công việc "rất technical".

Bạn đọc lại mấy lần mà vẫn không chắc đây là hai nghề khác nhau hay cùng một việc mang hai cái tên.

Gergely Orosz của The Pragmatic Engineer ghi nhận hồi tháng 5/2026 rằng Google, OpenAI và Anthropic đang tuyển FDE với nhu cầu rất lớn. Ông cũng cho rằng phiên bản mới nhất của vai trò này trông giống công việc tư vấn.

Nhu cầu lớn kéo theo một rủi ro. Bạn có thể chọn nhầm việc, rồi một năm sau nhận ra mình rất giỏi làm demo nhưng chưa từng chịu trách nhiệm về một hệ thống nào khi nó gặp sự cố. Bài này đưa cho bạn một phép thử đơn giản để tách hai vai trò, kèm cách áp dụng nó khi đọc tin tuyển dụng và khi viết CV.

## Ranh giới thật sự nằm sau ngày ship

Một bài so sánh hai vai trò trên Scaler đưa ra phép thử dễ nhớ nhất. Nếu hệ thống sập lúc 2 giờ sáng, ba tháng sau khi triển khai, thì người lo khôi phục là FDE chứ không phải SE. Tất cả những khác biệt còn lại đều bắt nguồn từ chuyện ai sở hữu hệ thống.

SE làm việc trong chu kỳ bán hàng, với nhiệm vụ chứng minh rằng sản phẩm *có thể* chạy được cho khách. FDE được gửi thẳng vào bài toán của khách để đảm bảo sản phẩm *thực sự* chạy được trong production. Vì vậy SE thường ưu tiên cho khách thấy nhiều tính năng, còn FDE ưu tiên độ bền ở mức production.

Sản phẩm cuối cùng của hai bên cũng khác nhau. Bài phân tích trên Aced.io so FDE với solutions architect (SA). SA và SE là hai vai trò gần nhau, cùng thuộc khối pre-sales, nên phép so sánh này áp dụng được cho cả hai.

Theo Aced.io, SA chủ yếu làm proof-of-concept, còn FDE là người đã xây và đang duy trì hệ thống.

Code làm cho demo có thể bị bỏ đi sau buổi trình bày, còn code của FDE phải sống được qua nhiều tháng dữ liệu thật.

**Điểm mấu chốt:** Muốn phân biệt hai vai trò, hãy hỏi ai sẽ sửa hệ thống khi nó hỏng.

## Thời điểm vào cuộc có đáng tin không?

Tín hiệu thứ hai là thời điểm. Theo Aced.io, solutions architect tham gia từ giai đoạn cuối của quá trình bán hàng cho đến lúc triển khai. FDE xuất hiện khi hợp đồng đã ký, để sản phẩm tạo ra giá trị thật cho khách.

Tuy vậy, mốc thời gian không phải lúc nào cũng rạch ròi. Palantir, công ty đặt nền móng cho vai trò này, mô tả FDE là kỹ sư ngồi ngay bên khách hàng và sở hữu dự án từ đầu đến cuối, bắt đầu từ cuộc trò chuyện đầu tiên với khách. Nghĩa là ở một số nơi, FDE có mặt từ trước khi hợp đồng được ký.

Vì thế, đừng phân loại một công việc chỉ dựa vào việc bạn vào cuộc lúc nào. Hai tín hiệu bền hơn là sơ đồ tổ chức và cơ chế lương. FDE thuộc khối engineering lõi, trong khi SE thường thuộc khối bán hàng hoặc pre-sales.

FDE thường không gánh chỉ tiêu doanh số, còn gói thu nhập của solutions architect hay có một phần biến đổi chịu ảnh hưởng của doanh số. Người ta làm theo cách mình được trả lương, nên dòng này trong offer cho bạn biết nhiều hơn cả chức danh.

## Một dự án, hai người, ba tháng

Hãy thử hình dung một tình huống giả định. Một công ty logistics muốn dùng LLM để đọc hóa đơn của nhà cung cấp và đẩy dữ liệu vào hệ thống kế toán của họ.

Trong giai đoạn bán hàng, SE dựng một bản demo chạy trên vài chục hóa đơn mẫu sạch sẽ. Bản demo trích xuất đúng các trường, có giao diện đẹp và cho thấy sản phẩm còn làm được thêm vài việc khác. Câu hỏi SE cần trả lời là "có làm được không?", và câu trả lời thuyết phục được người mua. Hợp đồng được ký.

Đến lúc này FDE nhận một câu hỏi khác hẳn: "Nó có chạy được mỗi ngày không?" FDE nối pipeline vào hệ thống kế toán thật. FDE xử lý hóa đơn scan bị nghiêng, các trường bị thiếu và giới hạn tần suất gọi API.

Họ cũng thêm logging, cơ chế retry và một bộ eval chấm trên dữ liệu thật của khách, thay vì trên bộ mẫu dùng để demo.

Ba tháng sau, một nhà cung cấp lớn đổi mẫu hóa đơn, và pipeline bắt đầu trả lỗi hàng loạt. Người nhận cảnh báo là FDE, vì họ là người đã xây và đang duy trì hệ thống. Sửa xong lỗi, việc của FDE vẫn chưa hết.

Tin tuyển FDE của Anthropic nêu rõ một trách nhiệm hiếm khi xuất hiện trong mô tả công việc của SE: nhận diện những pattern triển khai lặp đi lặp lại, hệ thống hóa chúng và chia sẻ những gì học được với đội Product và Engineering.

Trong tình huống trên, đó là lúc FDE viết lại cách phát hiện sớm việc nhà cung cấp đổi mẫu hóa đơn, để khách hàng tiếp theo không gặp lại sự cố đó.

## Năm câu hỏi khi đọc tin tuyển dụng

Lần tới khi mở một tin tuyển dụng, hãy đọc nó như một FDE đọc tài liệu kỹ thuật của khách: tìm hành vi thật thay vì tin vào cái tên. Vì SA và SE cùng thuộc khối pre-sales, năm câu hỏi dưới đây dùng được cho cả hai chức danh.

1. Vị trí này báo cáo cho ai, engineering hay sales?
2. Bạn vào cuộc trước hay sau khi ký hợp đồng, và có ở lại sau go-live không?
3. Code bạn viết có lên production hay chỉ dừng ở POC?
4. Sau khi ship, ai trực khi có sự cố? Đây là câu quan trọng nhất.
5. Lương có phần biến đổi gắn với doanh số không?

Nếu tin tuyển không trả lời được, hãy hỏi thẳng trong vòng phỏng vấn đầu tiên.

Mức độ đi công tác cũng là một tín hiệu. Tin tuyển FDE của Anthropic yêu cầu đi công tác thường xuyên, khoảng 25-50% thời gian, để trực tiếp xây sản phẩm cùng khách ngay tại chỗ của họ. Con số đó cho thấy vai trò này đòi hỏi ngồi lâu bên khách, chứ không phải ghé qua cho một buổi demo.

## Những nhầm lẫn hay gặp

Nhầm lẫn phổ biến nhất là nghĩ FDE chỉ là một SE biết code nhiều hơn. Khác biệt không nằm ở lượng code. Nó nằm ở việc ai chịu trách nhiệm cho chỗ code đó sau ngày ship.

Nhầm lẫn thứ hai là đánh giá công việc qua chức danh. Một vị trí mang tên FDE nhưng báo cáo cho sales và gắn với quota thì về bản chất vẫn là pre-sales. Một vị trí mang tên khác mà bắt bạn trực production thì gần với FDE hơn nhiều.

Nhầm lẫn thứ ba nằm trong CV. Nếu bạn ứng tuyển FDE mà mọi dòng kinh nghiệm đều là "xây demo" hay "làm POC", người tuyển dụng sẽ không thấy được tín hiệu họ cần.

Hãy viết về hệ thống bạn đã đưa lên production, khoảng thời gian bạn duy trì nó, những sự cố bạn đã xử lý và một quy trình bạn rút ra rồi mang về cho đội mình.

Nhầm lẫn cuối cùng là coi FDE đơn thuần là tư vấn. Orosz nhận xét rằng phiên bản mới nhất của vai trò này trông giống tư vấn. Nhưng người tư vấn có thể ra về khi xong dự án, còn FDE ở những nơi như Anthropic phải mang bài học từ khách về cho đội sản phẩm.

Chức danh trên tin tuyển dụng có thể đổi theo từng mùa tuyển người. Nếu muốn làm FDE, hãy tích lũy những câu chuyện mà trong đó bạn chính là người được gọi khi hệ thống hỏng.

**Thử ngay tuần này:**

- Mở hai tin tuyển dụng, một ghi Solutions Engineer và một ghi Forward Deployed Engineer, rồi tìm câu trả lời cho năm câu hỏi trong bài ở từng tin
- Viết lại một dòng trong CV từ kiểu 'xây demo cho khách' thành một câu nói rõ bạn đã đưa gì lên production, đã duy trì nó bao lâu và đã xử lý sự cố nào
- Chọn một sự cố production bạn từng xử lý, rồi viết nửa trang mô tả pattern có thể tái dùng mà bạn sẽ gửi lại cho đội product

## Nguồn

- [Forward Deployed Engineer vs Solutions Engineer: What's the Difference?](https://www.scaler.com/topics/forward-deployed-engineer-vs-solution-engineer/)

- [Forward Deployed Engineer vs Solutions Architect: Key Differences (2026)](https://www.aced.io/blog/forward-deployed-engineer-vs-solutions-architect-key-differences-2026)

- [Forward Deployed Software Engineer (Palantir job posting)](https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850)

- [Forward Deployed Engineer (Anthropic, via Accel job board)](https://jobs.accel.com/companies/anthropic/jobs/93102649-forward-deployed-engineer)

- [The Pulse: Forward deployed engineering heats up again](https://newsletter.pragmaticengineer.com/p/the-pulse-forward-deployed-engineering)