Từ consultant sang FDE: hiểu khách hàng là lợi thế, nhưng tin tuyển đòi bạn tự viết code

Palantir đăng tin tuyển Forward Deployed Software Engineer cho mảng y tế và dân sự của chính phủ Mỹ. Tin viết rằng trách nhiệm của người được tuyển “trông giống của một CTO startup”. Chỉ vài dòng bên dưới là một yêu cầu cứng: code giỏi, có năng lực chứng minh được với Python, Java hoặc C++.

Hai dòng đó cho thấy vì sao kinh nghiệm tư vấn thôi chưa đủ. Ngồi với khách, gỡ rối bài toán, làm việc với các bên liên quan mới là nửa đầu công việc. Nửa sau là tự tay dựng giải pháp, và cả Palantir lẫn Anthropic đều ghi nửa này thành yêu cầu lập trình cụ thể trong tin tuyển.

Nếu bạn đang làm tư vấn, implementation hay solutions engineering và muốn chuyển sang FDE, lợi thế về khách hàng của bạn là có thật. Nhưng muốn nó được tính, bạn cần có code chạy production đi kèm. Vậy nên luyện gì trước? Câu trả lời nằm ngay trong các tin tuyển.

Ranh giới nằm ở thứ bạn bàn giao

Cách nhanh nhất để thấy khác biệt là nhìn thứ còn lại khi dự án kết thúc. Anthropic mô tả FDE của họ là người làm việc bên trong hệ thống của khách hàng để xây ứng dụng production với các model Claude. Họ kể tên cụ thể những thứ phải bàn giao: MCP server, sub-agent, agent skill.

Không thứ nào trong số đó là slide hay báo cáo. Dù vậy, Anthropic không đóng cửa với người có nền tảng consulting. Họ chỉ đặt kinh nghiệm ấy cạnh hai điều kiện khác: lập trình Python vững và từng ship ứng dụng production.

Pave, công ty dữ liệu lương thưởng, gọi FDE là kiểu lai giữa kỹ sư và consultant, làm việc tại chỗ cùng khách hàng và viết code riêng cho từng khách. Đọc kỹ thì “consultant” chỉ là một nửa cái nhãn đó. Nửa kia là kỹ sư, và kinh nghiệm khách hàng nhiều đến đâu cũng không thay được nửa này.

Vì sao công ty cần người tự viết code?

SD Times giải thích khác biệt giữa hai vai trò bằng tốc độ. Theo trang này, consultant triển khai thường chậm hơn và chuộng các giải pháp đã được kiểm chứng. FDE thì ngồi xuống tự dựng giải pháp cần thiết. Một FDE giỏi bắt đầu tạo ra giá trị chỉ sau vài tuần, với một đội nhỏ.

Thử hình dung một cơ quan y tế công cần gộp dữ liệu ca bệnh từ ba hệ thống cũ. Nếu làm theo lối tư vấn, đội dự án chạy workshop discovery, viết đề xuất kiến trúc, rồi giao cho một đội khác làm. Mỗi lần chuyển tay mất thêm thời gian, và ngữ cảnh rơi rụng dọc đường.

Nếu làm theo lối FDE, discovery vẫn diễn ra trong tuần đầu. Nhưng ngay tuần đó người kỹ sư đã viết pipeline Python nối được hai nguồn dữ liệu đầu tiên, đưa kết quả cho người dùng thật xem, nghe phản hồi rồi sửa luôn. Không có bước chuyển giao nào, vì người nghe yêu cầu cũng là người viết code.

Đó cũng là lý do Palantir nhấn mạnh việc sở hữu end-to-end các dự án quan trọng, trong những đội nhỏ mà mỗi người phải tự gánh nhiều trách nhiệm.

“Sở hữu” ở đây là chịu trách nhiệm đến khi hệ thống chạy thật, không dừng ở bản khuyến nghị. Một consultant không tự viết được code thì không thể sở hữu theo nghĩa đó, dù hiểu khách hàng đến đâu.

Biết code vẫn chưa đủ: code phải dùng lại được

Người từ consulting sang còn gặp một cái bẫy khó thấy hơn. Một bài luận của người trong nghề trên Substack cảnh báo: nếu vai trò FDE không tạo ra đầu ra kỹ thuật dùng lại được, công ty thực chất đang chạy một doanh nghiệp dịch vụ, chỉ là nhân viên được gọi là kỹ sư.

Nghề tư vấn quen may đo cho từng khách. Mang thói quen ấy vào FDE, bạn sẽ viết những script dùng một lần, mỗi khách một bản, và lặp lại đúng mô hình consulting dưới một chức danh mới. Code thì có, nhưng giá trị không tích lũy được.

Quay lại ví dụ cơ quan y tế. Một FDE có tư duy sản phẩm sẽ viết phần kết nối hệ thống cũ sao cho tách được thành một thành phần chung, và ghi chú rõ phần nào chỉ dành riêng cho khách này. Những thứ Anthropic liệt kê, như MCP server hay agent skill, đều là những khối có thể đóng gói và dùng lại.

Lợi thế của consultant nằm ở đâu, và luyện gì trước?

Đừng vì thế mà xem nhẹ thứ bạn đã có. Tin tuyển của Palantir mô tả việc của FDSE là làm việc trực tiếp với khách hàng để nhanh chóng hiểu những bài toán khó nhất của họ, rồi xây giải pháp cho chúng. Nửa đầu câu đó là thứ nhiều kỹ sư phần mềm thuần túy còn phải học, còn bạn đã luyện nhiều năm.

Việc cần làm là bù nửa sau bằng những thứ người tuyển dụng nhìn thấy được. Bảng dưới đây ghép các yêu cầu từ nhiều nguồn với bằng chứng bạn có thể chuẩn bị cho từng yêu cầu. Cột cuối là gợi ý luyện tập, không phải trích từ tin tuyển.

Yêu cầu	Ai nêu	Bằng chứng nên chuẩn bị
Hiểu nhanh bài toán khó nhất của khách rồi xây giải pháp	Palantir	Một case cũ (đã ẩn danh) kể từ lúc discovery đến thứ đã được xây
Code giỏi Python, Java hoặc C++	Palantir	Một repo tự viết, có test, đọc được
Python vững và từng ship ứng dụng production	Anthropic	Một ứng dụng đã deploy, có người dùng thật
Sở hữu end-to-end trong đội nhỏ	Palantir	Một dự án bạn tự làm từ dữ liệu đầu vào đến vận hành
Đầu ra kỹ thuật dùng lại được	Bài luận trên Substack	Một thành phần chung, ví dụ MCP server bọc một API thật

Nếu bạn đến từ tư vấn, hãy bắt đầu từ hai yêu cầu code giỏi và ship ứng dụng production, vì đó là phần kinh nghiệm khách hàng không thay được. Chọn một bài toán trong một dự án cũ, ẩn danh nó, rồi tự dựng bằng Python từ đầu đến cuối: lấy dữ liệu, xử lý, deploy, có người dùng thật.

Trong CV, động từ quyết định người đọc xếp bạn vào nhóm nào. “Tư vấn”, “đề xuất”, “điều phối” là chuyện của một consultant. “Xây”, “ship”, “vận hành”, kèm thứ đang chạy và ai đang dùng nó, là chuyện của một FDE. Kinh nghiệm khách hàng nên đi kèm những dòng đó để chúng thêm sức nặng, đừng để nó thay chỗ chúng.

Khi đọc tin tuyển, hãy tìm ba chữ: production, end-to-end, own. Một vị trí chỉ nói về workshop, cấu hình và quan hệ khách hàng có thể là tư vấn triển khai được đổi tên.

Khi phỏng vấn, hãy hỏi thẳng: code viết trong các đợt triển khai có được đưa ngược vào sản phẩm không? Câu trả lời cho bạn biết mình sắp vào một đội kỹ sư hay một doanh nghiệp dịch vụ.

Người chuyển từ consulting sang FDE thành công nhiều khả năng không phải người bỏ hẳn nghề cũ. Đó là người giữ được khả năng hiểu khách hàng, và lần đầu tiên tự tay đưa thứ khách cần lên production.