FDE ở Baseten: tin tuyển dụng đòi hỏi gì và chuẩn bị thế nào

Bạn đang đọc tin tuyển Forward Deployed Engineer của Baseten và gặp một dòng lạ: ứng viên phải vừa là kỹ sư, vừa là project manager, vừa là product manager. Phản xạ dễ có nhất là viết vào CV những chữ như “giao tiếp tốt”, “làm việc với khách hàng”. Hiểu như vậy là sai trọng tâm.

Baseten mô tả rất rõ vai trò này nằm ở đâu. Theo bài viết về đội FDE trên blog của công ty, FDE ngồi trong khối engineering và thường xuyên đóng góp vào sản phẩm. Tin tuyển engineering manager cho đội này còn nói thẳng: FDE ở Baseten không phải một chức năng sales.

Vì thế, chuẩn bị cho vị trí này không phải là luyện kỹ năng thuyết trình. Bạn cần chứng minh mình là một kỹ sư có thể nhận một mục tiêu kinh doanh còn mù mờ và trả lại một dịch vụ chạy thật, đo được, và đủ tổng quát để công ty biến thành tính năng.

Tin tuyển đang thực sự kiểm tra điều gì?

Nhiệm vụ của đội, theo cách Baseten tự viết, có hai vế: giúp khách hàng sớm thấy giá trị thực, đồng thời xây sản phẩm và công cụ đưa nền tảng Baseten tiến xa hơn. Vế thứ hai là thứ phân biệt FDE ở đây với một kỹ sư tích hợp thông thường.

Con số cụ thể nhất nằm ở mục tiêu dài hạn của đội: 70% những gì được xây trong FDE phải được tích hợp vào sản phẩm. Hiểu theo công việc hằng ngày, nếu bạn viết một script benchmark độ trễ cho khách A, đội sẽ muốn script đó về sau dùng được cho khách B, C, rồi thành một công cụ trong sản phẩm.

Tiêu chí tuyển đầu tiên mà blog nêu ra là nền tảng kỹ thuật phần mềm cực kỳ vững. Bài viết cho rằng sự thấu cảm và khả năng giao tiếp có thể được huấn luyện ở một kỹ sư giỏi kỹ thuật. Cách đọc hợp lý là: phần kỹ thuật là thứ bạn phải mang theo sẵn.

Tiêu chí thứ hai, cũng trên blog, là sự tò mò ở mọi tầng của stack, từ ML xuống hạ tầng và networking.

Tin đăng trên Built In thêm phần cụ thể hơn: viết code chất lượng production bằng một ngôn ngữ đa dụng, và quen với pipeline AI/ML cùng vòng đời phát triển, triển khai model.

Bản ở Mỹ yêu cầu từ 2 năm kinh nghiệm trong môi trường tăng trưởng nhanh; bản ở London (EMEA) yêu cầu từ 1 năm. Nghĩa là cửa không đóng với kỹ sư còn trẻ, miễn hồ sơ chứng minh đúng thứ cần.

Từ “nhanh hơn, rẻ hơn” đến một spec có số

Nếu chỉ đọc kỹ một dòng trong tin tuyển, hãy đọc dòng này: FDE làm việc trực tiếp với khách, biến những mục tiêu kinh doanh mơ hồ thành dịch vụ đáng tin cậy, quan sát được, với kết quả rõ ràng về chất lượng, độ trễ và chi phí.

Mục trách nhiệm kể lại cả quá trình đó: từ mục tiêu mơ hồ ra spec rõ ràng và PoC có phạm vi cụ thể, rồi đi đến deployment. FDE lại được đưa vào từ giai đoạn sớm nhất của hành trình khách hàng, tức là bạn thường nhận yêu cầu khi nó còn mù mờ nhất.

Thử hình dung một tình huống giả định. Một công ty hỗ trợ khách hàng đang dùng LLM để tóm tắt ticket và nói với bạn: “Hệ thống chậm quá, mà hóa đơn cũng cao.” Câu này chưa phải yêu cầu kỹ thuật. Việc đầu tiên của bạn là tách nó thành ba trục mà tin tuyển đã nêu.

Trục	Câu hỏi discovery	Chỉ số đưa vào spec (ví dụ giả định)
Chất lượng	“Bản tóm tắt tốt trông thế nào? Ai đang chấm?”	Bộ 200 ticket có tóm tắt mẫu; điểm không thấp hơn hệ thống hiện tại
Độ trễ	“Người dùng chờ ở màn hình nào? Bao lâu thì họ bỏ đi?”	p95 dưới một ngưỡng thống nhất với khách, đo ở lưu lượng giờ cao điểm
Chi phí	“Ngân sách tính theo request hay theo tháng?”	Chi phí cho mỗi 1.000 request, so với mức hiện tại

Khi đã có bảng này, PoC trở nên rõ ràng: thử một model nhỏ hơn hoặc một cấu hình serving khác, chạy trên đúng bộ 200 ticket, báo cáo ba con số. Nếu chất lượng giảm, bạn có bằng chứng để quay lại thương lượng với khách thay vì tranh luận bằng cảm giác.

Đây cũng là lúc vai trò project manager và product manager xuất hiện. Bạn quyết định thứ tự thử nghiệm, chốt với khách thế nào là “xong”, và tự hỏi phần nào của công việc này nên trở thành công cụ dùng chung. Script chạy eval trên 200 ticket, nếu được tham số hóa ngay từ đầu, chính là ứng viên cho con số 70%.

Chuẩn bị thế nào trong vài tuần?

Bắt đầu từ công cụ của chính Baseten. Truss là CLI mã nguồn mở để deploy và serve model ML trên Baseten. Làm một dự án nhỏ với nó cho bạn hai thứ cùng lúc: hiểu vòng đời model theo đúng cách công ty làm, và một thứ cụ thể để nói trong phỏng vấn.

Một dự án portfolio tốt nên lặp lại đúng bài tập ở trên. Chọn một bài toán có thật, viết spec một trang với ba trục, đóng gói và deploy một model qua Truss, đo độ trễ ở nhiều mức tải, ước tính chi phí, rồi viết README giải thích bạn đã đánh đổi gì.

Phần cuối README nên có một đoạn: nếu đây là việc cho khách thật, phần nào bạn sẽ tách ra thành công cụ dùng lại.

Đừng bỏ qua các tầng bên dưới, vì blog của Baseten nhắc thẳng tới hạ tầng và networking. Thử hình dung một endpoint chậm: thủ phạm có thể là model, là cold start, là cấu hình hạ tầng hay đường mạng. Hãy luyện thói quen tự hỏi “chậm ở đâu” và đo từng chặng thay vì đoán.

Bốn dòng CV khiến hồ sơ lệch hướng

Mỗi gạch đầu dòng trong CV nên đi theo khung: yêu cầu mơ hồ ban đầu, chỉ số bạn đã chốt, kết quả đo được, và phần nào trở thành thứ dùng chung. Bốn lỗi dưới đây đều là chỗ lệch khỏi khung đó, kèm một cách viết lại (các ví dụ đều là giả định).

Lỗi phổ biến nhất là tự định vị như presales, vai trò mà Baseten đã nói rõ không phải FDE của họ. Dòng yếu: “Demo sản phẩm cho khách hàng tiềm năng, hỗ trợ đội sales chốt hợp đồng.” Viết lại: “Dựng PoC tóm tắt văn bản cho khách, viết spec có ngưỡng độ trễ và chi phí mỗi request, rồi đưa dịch vụ lên production.”

Lỗi thứ hai là chỉ biết một tầng, trong khi tiêu chí là tò mò ở mọi tầng của stack. Dòng yếu: “Fine-tune model phân loại văn bản đạt độ chính xác cao.” Viết lại: “Fine-tune model phân loại, tự đóng gói và deploy thành endpoint, đo độ trễ từng chặng và tìm ra cold start là nguyên nhân chậm.”

Lỗi thứ ba khó thấy hơn: kể PoC “thành công” mà không có con số nào. Dòng yếu: “Xây PoC chatbot thành công, khách hàng hài lòng.” Viết lại: “Xây PoC chatbot, báo cáo điểm chất lượng trên bộ ticket mẫu, độ trễ p95 và chi phí mỗi 1.000 request so với hệ thống cũ.”

Lỗi cuối là chỉ kể việc làm riêng cho một khách rồi thôi, trong khi đội đặt mục tiêu 70% những gì FDE xây được đưa vào sản phẩm.

Dòng yếu: “Viết script benchmark cho dự án của khách A.” Viết lại: “Chuyển yêu cầu ‘giảm chi phí’ của đội nội bộ thành spec có ngưỡng độ trễ và chi phí mỗi request, rồi đóng gói công cụ đo thành thư viện cho ba đội khác.”

Đặt bốn dòng viết lại cạnh tin tuyển, bạn sẽ thấy chúng trả lời đúng câu hỏi Baseten đang hỏi: kỹ sư này có biến được một mục tiêu mơ hồ thành dịch vụ có số đo, và để lại thứ gì cho sản phẩm hay không.