FDE PulseViệc làm FDE đang mở 449Mới trong 7 ngày 24Công ty đang tuyển 52Nhận làm từ xa 25%Lương trung vị (Mỹ) $216kTuyển nhiều nhất Databricks 125
EN

Tờ báo của nghề Forward Deployed Engineer

Phân tích

FDE và Sales Engineer: khác nhau ở người nhận cuộc gọi lúc 2 giờ sáng

Khi hợp đồng được ký, một vai bắt đầu rút lui, còn vai kia mới bắt đầu phần việc chính.

Kỹ sư ngồi trước laptop trong văn phòng tối vào ban đêm, hoặc một phòng máy chủ về khuya.
Ảnh: One Idea LLC / CC0

Tóm tắt nhanh

  • Ranh giới giữa hai vai trò là thời điểm ký hợp đồng: việc chính của sales engineer gần như xong, còn việc chính của FDE mới bắt đầu.
  • FDE viết code production ngay trên hạ tầng và công cụ của khách, nên phải chịu trách nhiệm cho kết quả ở đó.
  • Chức danh FDE đang bị gắn cho cả những vai thiên về bán hàng, vì thế hãy đọc phạm vi công việc trong JD thay vì chỉ nhìn tên gọi.
Chia sẻLinkedInFacebookX
Trục thời gian ngang. Bên trái, dải Sales Engineer (demo, prototype) kéo dài qua chu kỳ bán hàng rồi thu hẹp dần sau mốc ký hợp đồng được tô cam. Từ mốc ký trở đi, dải FDE (code tích hợp production) kéo dài qua go-live tới sự cố lúc 2 giờ sáng, nơi FDE sở hữu việc phục hồi.
Solutions engineer làm việc trong chu kỳ bán hàng. Phần việc chính của FDE bắt đầu sau khi ký và kéo dài qua go-live. Nguồn: Scaler, Christian & Timbers, FDE Academy.

Ba tháng sau khi triển khai, hệ thống sập lúc 2 giờ sáng. Ai phải dậy xử lý? Bài so sánh FDE với solutions engineer trên Scaler trả lời không do dự: người sở hữu việc phục hồi là FDE, không phải SE.

Câu trả lời ấy gói lại gần như toàn bộ khác biệt giữa hai nghề hay bị gộp làm một. Hai vai đều làm việc với khách hàng, đều phải hiểu kỹ thuật, và đều phải nói chuyện được với người không viết code.

Nếu bạn đang muốn chuyển sang FDE, hoặc đang làm mà chưa rõ ranh giới công việc của mình, câu hỏi nên đặt ra không phải là “có gặp khách không”. Câu hỏi đúng là: khi hệ thống chạy thật rồi gặp sự cố, ai là người bị gọi dậy?

Ranh giới nằm ở chữ ký

Hai vai cùng đứng trước khách hàng, nhưng phần việc chính của mỗi bên rơi vào hai giai đoạn khác nhau: trước và sau chữ ký. Solutions engineer làm việc trong chu kỳ bán hàng, còn phần việc chính của FDE chỉ bắt đầu sau khi hợp đồng được ký, như Scaler mô tả.

FDE Academy vẽ ranh giới tương tự: FDE hoạt động chủ yếu khi sản phẩm đã bán xong, SE ở giai đoạn trước bán hoặc đầu triển khai.

Christian & Timbers nói thẳng hơn: việc cốt lõi của sales engineer, tức chứng minh sản phẩm giải quyết được bài toán của khách, phần lớn đã xong khi khách ký. Trách nhiệm của FDE thì kéo dài tới tận kết quả chạy trên production.

Thứ đổi tay vào lúc ký vì thế không phải khách hàng, mà là trách nhiệm với hệ thống chạy thật. Christian & Timbers đặt luôn điều đó vào tiêu đề bài phân tích của họ: khác biệt nằm ở quyền sở hữu production.

Vì sao demo chạy mà production lại hỏng

The Pragmatic Engineer nhấn mạnh FDE làm việc thực tế hơn nhiều so với các vai bán hàng: họ viết code trực tiếp trên hạ tầng của khách và dùng công cụ của khách. Đó là nơi khoảng cách giữa demo và production lộ ra.

Thử hình dung một agent đọc tài liệu nội bộ để trả lời câu hỏi của nhân viên. Trong demo, nó đọc một thư mục tài liệu mẫu, trả lời trơn tru, và khách gật đầu. Lên production thì agent phải tôn trọng phân quyền, để nhân viên phòng A không đọc được hợp đồng của phòng B.

Trong kịch bản ấy, tài liệu còn nằm trong một hệ thống quản lý văn bản đã chạy nhiều năm, với API chẳng ai còn nhớ cách dùng. Đội bảo mật của khách muốn biết dữ liệu đi đâu, log lưu ở đâu. Rồi một ngày có người tải lên một file scan không có lớp chữ, và câu trả lời của agent sai hoàn toàn.

Paraform mô tả FDE là người đưa code production vào chạy trong môi trường của khách và chịu trách nhiệm cho kết quả ở đó. Một demo chỉ cần chạy được một lần trước mặt khách. Code mà FDE đứng tên phải chạy được cả vào ngày không ai để ý tới nó.

Ai giữ lời hứa sau khi bán?

Nếu sales engineer bán một lời hứa, phải có người biến lời hứa ấy thành hệ thống, và có người giữ nó chạy về lâu dài. Paraform, khi tư vấn startup nên tuyển vai nào, tóm chuỗi này trong ba nhịp: SE bán tầm nhìn, FDE xây nó, CE (customer engineer) duy trì nó.

Vị trí ở giữa chuỗi giải thích vì sao FDE không đơn giản là một sales engineer biết code hơn. Theo The Pragmatic Engineer, dấu hiệu riêng của FDE là vừa làm việc với khách hàng vừa đóng góp ngược vào chính sản phẩm, điều các vai phía bán hàng không làm.

Ở công ty khai sinh ra mô hình này, vai triển khai không phải ngách nhỏ. Valletta Software đếm tin tuyển dụng đang mở của Palantir ngày 8/9/2026 và thấy 77 trên 310 vị trí là forward deployed, khoảng một phần tư.

Năm câu hỏi dưới đây cho thấy hai vai tách nhau ở đâu:

Câu hỏi Sales / Solutions Engineer FDE
Phần việc chính diễn ra khi nào? Trong chu kỳ bán hàng, trước khi ký hoặc đầu triển khai Sau khi ký, kéo tới kết quả trên production
Phần việc kỹ thuật nhằm làm gì? Chứng minh sản phẩm giải quyết được bài toán của khách Viết code production trên hạ tầng và công cụ của khách
Trách nhiệm kết thúc ở đâu? Phần lớn xong khi khách ký Kéo dài tới kết quả chạy thật
Hệ thống sập sau triển khai thì sao? Việc cốt lõi đã xong từ lúc ký Sở hữu việc phục hồi
Vị trí trong chuỗi bán, xây, duy trì Bán tầm nhìn Xây nó, rồi CE duy trì

Chức danh không còn đủ để tin

Hệ quả thực tế nhất của ranh giới này nằm ở tin tuyển dụng. Bloomberry, sau khi phân tích 1.000 tin, ghi nhận số tin FDE tăng 1.165% so với năm trước, phần lớn ở công ty nhỏ. Getperspective thấy làn sóng tuyển đã lan từ các frontier lab sang startup AI theo ngành dọc và các hyperscaler như Google.

Khi chức danh nóng, nó bị gắn vào nhiều việc khác nhau. Getperspective ghi nhận nhà tuyển dụng lặng lẽ đổi tên các vị trí solutions architect thành FDE để tranh cùng một nguồn ứng viên, và kết luận rằng câu chữ mô tả phạm vi công việc quan trọng hơn chức danh.

Christian & Timbers nhìn từ phía công ty: tuyển nhầm người thường bắt nguồn từ bản mô tả vị trí, trước khi lộ ra trong danh sách ứng viên. Khi JD mô tả việc của sales engineer dưới nhãn FDE, người nộp đơn cũng bị dẫn sai theo.

Vì thế hãy tìm những chữ như go-live, production, integration, on-call, hay “own end-to-end”. Nếu JD chủ yếu nói về demo, POC, hỗ trợ đội sales và tỷ lệ chốt deal, nhiều khả năng đó là một vai sales engineer dù tên gọi là gì. Vai đó không xấu, nhưng nó luyện một bộ kỹ năng khác.

Viết lại một dòng CV

Trong CV, đừng viết “làm việc trực tiếp với khách hàng”, vì câu đó sales engineer cũng viết được. Lấy lại agent tra cứu tài liệu giả định ở trên làm ví dụ. Câu mà ai cũng viết là:

Trước: “Làm việc trực tiếp với khách hàng để triển khai giải pháp AI.”

Sau: “Đưa agent tra cứu tài liệu nội bộ lên production, tích hợp với hệ thống quản lý văn bản cũ và phân quyền theo phòng ban; trực on-call sau go-live, tự xử lý sự cố file scan không có lớp chữ khiến câu trả lời sai.”

Nếu bạn từng đóng góp ngược vào sản phẩm lõi từ một bài toán ở phía khách, hãy thêm một vế nữa, vì đó chính là điểm The Pragmatic Engineer dùng để tách FDE khỏi các vai bán hàng.

Câu hỏi nên mang vào buổi phỏng vấn

Đến vòng cuối, hãy hỏi người phỏng vấn một câu duy nhất: ba tháng sau go-live, nếu hệ thống của khách sập lúc 2 giờ sáng, ai nhận cuộc gọi, và người đó có quyền sửa code trên hạ tầng của khách không?

Nếu câu trả lời là sự cố sẽ được chuyển cho một đội khác xử lý, bạn sẽ không phải người sở hữu production, dù chức danh ghi gì. Nếu câu trả lời là “bạn”, kèm quyền truy cập để tự sửa, thì đó mới là chỗ ngồi của một FDE.

Bài này có hữu ích không?

Dùng cùng trợ lý AIHỏi Claude ↗Hỏi ChatGPT ↗
9 nguồn
Đọc tiếp trên lộ trình · Chặng 1: Nền tảngDelta, Echo hay Applied AI: sáu công ty gọi nghề FDE theo sáu kiểuĐọc tên chức danh thì không biết được bạn sẽ viết code hay đi họp, nên hãy đọc JD theo hai câu hỏi: ai sở hữu bản build và ai sở hữu kết quả.