FDE ở Cursor: không phải demo, mà là PR được merge

Bạn mở tin tuyển dụng Forward Deployed Engineer, EMEA mà Cursor (công ty Anysphere) đăng cho vị trí ở London ngày 4/6/2026. Trong tin có một câu khá thẳng: đây không phải vai trò làm demo, bạn chịu trách nhiệm về những hệ thống phải chạy được ngoài đời thật.

Hãy giữ câu đó trong đầu khi đọc phần còn lại. Nhiều kỹ sư đọc tin tuyển dụng như danh sách từ khóa để nhét vào CV. Với vị trí này, cách đọc đúng là coi mỗi dòng như một việc bạn sẽ phải làm ở chỗ khách hàng trong tuần đầu tiên, rồi tự hỏi mình đã từng làm việc đó chưa và có bằng chứng gì không.

Tin tuyển dụng thực ra mô tả một engagement

Đọc hết các yêu cầu, bạn sẽ thấy tin của Cursor kể một vòng công việc khá hoàn chỉnh. Bạn làm discovery cùng các kỹ sư của khách hàng, xây workflow Cursor cho những việc như refactor, migration, vòng review PR, hay đi từ incident đến bản sửa.

Sau đó bạn tự chịu trách nhiệm về eval, tracing và đánh đổi chi phí, rồi đóng gói thứ vừa xây thành pattern dùng lại được.

Về kỹ năng, Cursor hỏi kinh nghiệm xây workflow AI ở mức production, khả năng làm end-to-end từ frontend, backend, hạ tầng đến lặp prompt, độ tin cậy khi vận hành, cùng Python và TypeScript/JavaScript vững.

Trang tổng hợp việc làm của Exponent ghi mức kinh nghiệm kỳ vọng là từ 5 năm trở lên, trong đó ít nhất 2 năm làm việc trực tiếp với khách hàng.

Cách Cursor đặt vị trí này trong tổ chức cũng đáng đọc kỹ. Công ty mô tả FDE là người ngồi cùng các tổ chức engineering doanh nghiệp, có thể làm từ xa, và trang của Exponent nhận xét Cursor đang xây cả một tổ chức FDE đầy đủ chứ không phải một bộ phận hỗ trợ.

Điều này ảnh hưởng trực tiếp tới cách bạn kể chuyện khi phỏng vấn: bạn là người đưa sản phẩm vào chạy thật, không phải người ngồi xử lý ticket.

Một đội FDE ở Cursor được mô tả ra sao?

Tin tuyển dụng Forward Deployed Strategist mà Cursor đăng ngày 24/7/2026 cho thấy cách một nhóm được tổ chức. Mỗi pod gồm một Strategist và 1–2 FDE; FDE ngồi cùng đội của khách hàng và xây các hệ thống production sâu hơn. Tin này cũng nhắc lại sứ mệnh của công ty: tự động hóa việc viết code.

Ở cấp lãnh đạo, Cursor tuyển Regional Director of Forward Deployed Engineering, vị trí đăng ngày 22/7/2026, để dẫn dắt và phát triển một đội 6–8 FDE làm các dự án chiến lược.

Người này cần từ 8 năm kinh nghiệm dẫn dắt đội kỹ thuật ship hệ thống production, đứng ra làm người bảo trợ kỹ thuật cấp lãnh đạo với khách hàng, và xây các playbook dùng lại được để cả tổ chức FDE giỏi lên theo thời gian.

Từ đó có thể rút ra một mẹo chuẩn bị. Khi cấp lãnh đạo của tổ chức FDE được giao xây playbook dùng chung, một FDE biết biến việc làm cho một khách hàng thành thứ áp được sang khách hàng tiếp theo nhiều khả năng sẽ được đánh giá cao.

Bạn nên mang theo bằng chứng cho cả hai tầng: một khách hàng chạy tốt, và một pattern người khác dùng lại được.

Ví dụ: một dự án migration có số đo thật

Thử hình dung một khách hàng giả định muốn chuyển hàng trăm service từ một thư viện logging cũ sang thư viện mới. Đây đúng loại việc tin tuyển dụng nhắc tới. Một buổi discovery tốt với tech lead phía khách hàng có thể đi như sau.

FDE: Một PR migration thế nào thì đội anh sẵn sàng merge mà không cần sửa tay? Tech lead: CI xanh, không đổi format log mà hệ thống alert đang đọc, và mỗi PR chỉ đụng một service. FDE: Ai review, và mỗi tuần họ có bao nhiêu giờ cho việc này? Tech lead: Hai người, mỗi người vài giờ.

Ba câu trả lời đó định nghĩa luôn eval của bạn: CI xanh, format log không đổi, phạm vi một service. Câu cuối định nghĩa ràng buộc thật: năng lực review của con người, chứ không phải tốc độ sinh code.

Giờ làm một phép tính giả định. Workflow sinh 200 PR, 150 PR qua CI, reviewer merge 120. Tỷ lệ merge là 60%, chứ không phải 75% như con số CI gợi ý. Nếu tổng chi phí model cho cả đợt là C, thì chi phí thật trên mỗi PR được merge là C chia 120, không phải C chia 200.

Đây là chỗ tracing phát huy giá trị. Khi lưu trace cho từng PR, bạn xem được 30 PR qua CI nhưng bị từ chối hỏng vì đâu: có thể đổi format log, có thể đụng hai service một lúc.

Mỗi nguyên nhân có thể thành một check tự động, chạy trước khi PR tới tay reviewer. Nhờ vậy, hai người review chỉ còn phải đọc những PR thực sự có cơ hội được merge.

Biến dự án thành hồ sơ ứng tuyển

Bảng dưới đây ghép từng yêu cầu trong tin tuyển dụng với bằng chứng bạn có thể tự tạo ra từ một dự án như trên.

Yêu cầu trong tin	Bằng chứng nên có
Discovery với kỹ sư phía khách hàng	Một trang ghi lại câu hỏi đã hỏi và tiêu chí merge rút ra
Xây workflow Cursor (migration, review PR)	Repo với chuỗi PR có thật, mỗi PR một phạm vi
Eval, tracing, chi phí	Bảng tỷ lệ merge, nguyên nhân bị từ chối, chi phí trên PR được merge
End-to-end, Python và TypeScript	Script điều phối bằng Python, một dashboard nhỏ bằng TypeScript
Pattern dùng lại được	Playbook một trang mà người khác làm theo được

Trong CV, hãy viết theo kết quả: một dòng nêu workflow, tỷ lệ merge, và check nào bạn thêm vào sau khi đọc trace. Nếu bạn chưa đủ 2 năm làm với khách hàng, hãy kể những lần bạn ngồi với đội khác để gỡ một vấn đề production, vì đó là chất liệu gần nhất với công việc này.

Những lỗi hay gặp khi chuẩn bị

Lỗi phổ biến nhất là mang demo đi phỏng vấn cho một vị trí tự nhận không phải demo. Một video agent sửa code đẹp mắt không trả lời được câu hỏi: nó chạy trên repo thật bao nhiêu lần, hỏng bao nhiêu lần, và bạn đã làm gì khi nó hỏng.

Một lỗi khác là bỏ qua chi phí. Tin tuyển dụng ghi rõ FDE sở hữu đánh đổi chi phí, nên nếu không nói được một PR tốn bao nhiêu, bạn đang bỏ trống một phần việc được giao thẳng cho mình. Cũng đừng chỉ kể chuyện code: người phỏng vấn muốn nghe bạn đã hỏi khách hàng điều gì trước khi viết dòng đầu tiên.

Lỗi cuối là dừng lại ở một lần chạy thành công. Ở một tổ chức mà cấp lãnh đạo được giao xây playbook, câu hỏi tiếp theo gần như chắc chắn sẽ là: người khác có làm lại được việc này mà không cần bạn không?

Tuần này, chọn một repo mã nguồn mở và migrate 20 file bằng Cursor. Hai mươi PR kèm một bảng số trung thực sẽ thuyết phục hơn bất kỳ bản demo nào.