Tuyển FDE đầu tiên: bắt đầu với hai người và một ranh giới code rõ ràng

Thử hình dung bạn là kỹ sư thứ năm của một startup AI. Bản demo chạy tốt, một khách hàng doanh nghiệp đồng ý chạy thử, rồi proof-of-concept nằm im sáu tuần vì dữ liệu của họ không giống bất kỳ thứ gì đội bạn từng test. Sales gọi điện hằng tuần, đội product bận roadmap, còn bạn thì sửa vội vào buổi tối.

Đó gần như đúng khoảnh khắc mà Paraform, một marketplace tuyển dụng, gọi là tín hiệu rõ nhất để tuyển FDE đầu tiên: một thương vụ proof-of-concept bị đứng. Nó không phải chuyện bán hàng. Đó là phần việc engineering nằm giữa sản phẩm và thực tế của khách, và chưa ai được giao làm.

Bài này dành cho hai kiểu người đọc. Nếu bạn là engineering lead được giao dựng đội, đây là trình tự để làm. Nếu bạn đang muốn trở thành FDE, đây là cách công ty sẽ đánh giá bạn, và là những câu hỏi bạn nên hỏi ngược lại họ.

Bạn đang tuyển kiểu FDE nào?

Paraform cho rằng nguyên nhân phổ biến nhất khiến một cuộc tuyển FDE kéo dài là các bên không thống nhất được mình đang tuyển kiểu FDE nào. Rocketlane còn nói thẳng hơn: FDE có năm dạng khác nhau, và chọn sai dạng so với quy mô thương vụ và cách định giá thì con số không còn hợp lý.

Phạm vi công việc thực tế cho thấy vì sao. Ở Cursor, một engagement có thể chỉ là gap analysis trong vài tuần, cũng có thể là dựng cả một SDK trong vài tháng. Hai việc đó cần hai kiểu người khác nhau.

Cách định giá cũng kéo vai trò đi theo. Rocketlane lập luận rằng nếu bạn bán theo kết quả, FDE sẽ là đội trực tiếp mang kết quả đó đến cho khách, trong một gói bán hàng ở phân khúc cao.

Vì thế, trước khi đăng tin, hãy viết một trang trả lời năm câu hỏi dưới đây. Cho sales, product và engineering cùng đọc. Nếu ba bên trả lời khác nhau, bạn vừa tìm ra lý do cuộc tuyển sẽ kéo dài.

Câu hỏi	Ví dụ câu trả lời cho startup ở trên
Tín hiệu nào khiến ta tuyển?	PoC với khách logistics đứng vì tích hợp dữ liệu
Engagement điển hình dài bao lâu?	Vài tuần tích hợp, chưa phải build nhiều tháng
Ta bán theo cách nào?	Thử nghiệm có tiêu chí thành công, sau đó tính theo kết quả
Code của FDE nằm ở đâu?	Repo riêng cho từng khách, không sửa thẳng core
FDE báo cáo cho ai?	Engineering lead, không phải trưởng sales

Người đầu tiên viết playbook, người thứ hai vận hành nó

Hướng dẫn của Recruiting from Scratch khuyên bắt đầu với hai FDE. Người đầu tiên phải đủ senior để định nghĩa playbook deployment, người thứ hai đưa playbook đó vào công việc thường ngày. Cùng hướng dẫn đó cảnh báo: tuyển quá khoảng ba FDE khi chưa có một playbook lặp lại được sẽ gây hỗn loạn.

“Senior” ở đây cụ thể là gì? Hồ sơ Cursor tìm kiếm là hơn 5 năm làm software engineering, có trực giác tốt về system design và có kinh nghiệm làm việc trực tiếp với khách hàng.

Tin tuyển của Palantir mô tả công việc là làm trong nhóm nhỏ, gần như không có người giám sát, và tự chịu trách nhiệm từ đầu đến cuối những dự án quan trọng.

Paraform cũng cảnh báo rằng ứng viên cần một bản đặc tả chi tiết trước khi bắt tay vào việc sẽ gặp khó trong vai trò này. Đó là lý do người đầu tiên không thể là một kỹ sư giỏi chỉ đang chờ ticket. Ở giai đoạn này chưa có ticket nào cả.

Khi đội đã lớn hơn, Recruiting from Scratch đặt mục tiêu một FDE cho mỗi tài khoản doanh nghiệp chiến lược. Hãy coi đó là đích đến về sau, không phải điểm xuất phát.

Phỏng vấn bằng một buổi làm thật

Bài kiểm tra mà Recruiting from Scratch đề xuất rất đơn giản: cho ứng viên build một thứ nhỏ, rồi trình bày nó cho một stakeholder không làm kỹ thuật ngồi ngay trong phòng, thay cho các vòng LeetCode hay system design thông thường. Nó kiểm tra đúng hai việc mà FDE phải làm mỗi tuần.

Với startup ở trên, một buổi 90 phút có thể chia như sau. Mười lăm phút đầu, người phỏng vấn đóng vai trưởng vận hành của khách hàng và mô tả vấn đề bằng ngôn ngữ của người dùng, ví dụ “đơn hàng bị trùng mỗi khi tài xế mất sóng”.

Ứng viên được hỏi bao nhiêu tùy thích. Một giờ tiếp theo dành để dựng một bản chạy được trên một file CSV mẫu có lỗi cố ý cài sẵn.

Mười lăm phút cuối, một người bên sales hoặc vận hành vào phòng và nghe ứng viên trình bày. Hãy chấm ba điểm: ứng viên có hỏi lại để làm rõ trước khi viết code không, có tự phát hiện dòng dữ liệu bẩn không, và có giải thích được giới hạn của bản dựng mà không cần thuật ngữ chuyên môn hay không.

Một ứng viên dừng lại để hỏi “định nghĩa đơn trùng của anh là gì?” thường đáng giá hơn một ứng viên viết xong nhanh nhất.

Ranh giới phải vạch trước ngày đầu tiên

Rocketlane khuyên vạch ranh giới kiến trúc giữa phần build riêng cho khách và core product trước engagement đầu tiên. Nếu không làm, FDE đầu tiên sẽ vá thẳng vào core để kịp hạn chót, và sau ba khách hàng bạn có ba nhánh sản phẩm khác nhau.

Trong ví dụ trên, quy tắc có thể là: connector và script làm sạch dữ liệu nằm trong repo của từng khách, còn mọi thay đổi vào core phải qua review của đội product.

Tuyến báo cáo cũng quan trọng không kém. Recruiting from Scratch cho rằng FDE nên nằm trong engineering, vì báo cáo cho sales sẽ kéo họ sang làm việc pre-sales.

Cursor chọn một vị trí ở giữa: VP phụ trách FDE ở đó đặt đội của mình giữa khối engineering và product với đội go-to-market. Cả hai cách đều có chung một ý: FDE phải được giữ gần code.

Những lỗi khiến đội FDE đầu tiên thất bại

Lỗi đầu tiên là kỳ vọng tuyển nhanh. Paraform khuyên dành 8 đến 12 tuần cho một cuộc tuyển FDE đầy đủ, và phần lớn phải chủ động tìm đến ứng viên thay vì chờ đơn gửi về. Nếu bạn cần người cho PoC đang đứng tuần sau, hãy giao tạm cho một kỹ sư trong đội trong lúc vẫn tuyển.

Những lời khuyên như thời gian tuyển hay bắt đầu với hai người nên được đọc như kinh nghiệm của người làm nghề tuyển, không phải chuẩn chung.

Lỗi thứ hai là tuyển người thứ ba, thứ tư khi người đầu tiên chưa viết xong playbook. Lỗi thứ ba là để FDE báo cáo cho sales rồi ngạc nhiên khi họ dành cả tuần làm demo. Lỗi thứ tư khó thấy hơn: tuyển một kỹ sư xuất sắc nhưng cần spec rõ ràng, rồi đặt họ vào chỗ không có spec.

Nếu bạn là người được tuyển

Đọc kỹ tin tuyển. Nếu tin ghi rõ engagement dài bao lâu, ai là người báo cáo trực tiếp và code của bạn sẽ nằm ở đâu, công ty đó đã làm phần việc của mình. Nếu không, hãy hỏi đúng ba câu đó trong buổi phỏng vấn đầu.

Trong CV, đừng chỉ ghi “làm việc với khách hàng”. Hãy viết về một lần bạn nhận một vấn đề chưa có spec, tự dựng giải pháp, rồi giải thích nó cho người không làm kỹ thuật và được họ đồng ý dùng. Đó chính là bài kiểm tra mà công ty sẽ cho bạn làm, nên hãy chứng minh bạn đã làm nó ngoài đời thật.

Một đội FDE tốt không bắt đầu từ số người trong đội. Nó bắt đầu từ một PoC đang đứng, một trang viết rõ vai trò, và một người đủ vững để biến lần triển khai đầu tiên thành cách làm cho mọi lần sau.