Founding FDE ở Glean: vì sao tin tuyển dụng đòi kinh nghiệm 0-to-1 chứ không chỉ triển khai
Ở vị trí này, thứ bạn làm cho khách hàng sẽ được Glean đưa vào sản phẩm, nên ai chỉ quen cài sản phẩm có sẵn sẽ khó đi qua vòng lọc.
Tóm tắt nhanh
- Tin tuyển dụng của Glean nói thẳng rằng việc chính của Founding FDE là tạo sản phẩm từ 0 đến 1, và thứ kỹ sư xây sẽ được Glean đưa vào sản phẩm.
- Thomas Otter chỉ ra rằng FDE tính phí cho khách hàng thì phục vụ dự án chứ không phục vụ sản phẩm. Glean chọn chiều ngược lại.
- Muốn ứng tuyển, bạn cần bằng chứng mình từng tự xây phần mềm production khi yêu cầu còn mơ hồ, chứ triển khai giỏi thôi thì chưa đủ.
“Việc chính của bạn là tạo ra sản phẩm từ 0 đến 1.” Câu này nằm trong tin tuyển Founding Forward Deployed Engineer của Glean, và nó đặt trọng tâm vào việc tạo sản phẩm chứ không chỉ triển khai thứ đã có.
Một câu tiếp theo trong tin còn rõ hơn: thứ bạn xây sẽ được Glean đưa vào sản phẩm. Vì thế, người làm vị trí này không chỉ là cánh tay nối dài của đội sản phẩm. Họ đứng ở đầu nguồn của roadmap.
Bạn nên để ý điều này vì chức danh FDE đang bị dùng rất lỏng. Thomas Otter cảnh báo trong bài viết về nghề này rằng nhiều vị trí FDE thực chất chỉ là triển khai hoặc pre-sales được dán nhãn mới.
Tin của Glean cho thấy một vị trí FDE “thật” kiểm tra những gì, và tại sao kinh nghiệm cài đặt sản phẩm có sẵn, dù làm giỏi, vẫn chưa đủ để qua vòng lọc.
Triển khai giỏi vẫn chưa đủ, vì sao?
Ở một vị trí triển khai, sản phẩm đã có sẵn. Câu hỏi là làm sao cho nó chạy được trong môi trường của khách hàng. Còn tin của Glean giao một việc khác: tìm ra những bài toán kinh doanh lớn nhất chưa được giải tại các khách hàng chiến lược nhất. Khi đó chưa có sản phẩm nào để cài.
Đó là lý do tin đặt một yêu cầu cốt lõi: bạn đã từng xây phần mềm production từ đầu trong môi trường mơ hồ. Chữ quan trọng là “mơ hồ”.
Người triển khai làm việc với một bản đặc tả có sẵn. Người làm 0-to-1 phải tự viết bản đặc tả đó, thường sau vài cuộc nói chuyện mà khách hàng cũng chưa diễn đạt rõ mình cần gì.
Otter mô tả đúng loại việc này. Theo ông, FDE hợp với những công việc mà phạm vi chưa chắc chắn, khi bạn đang làm một thứ chưa ai làm trước đó.
Phép thử của Otter: dự án hay sản phẩm?
Otter còn đưa ra một phép thử ngắn: nếu FDE được tính phí cho khách hàng, họ làm việc cho dự án chứ không cho sản phẩm. Lý do dễ hình dung: khi khách trả tiền cho thời gian của kỹ sư, động lực của cả hai bên là hoàn thành đúng hợp đồng, và chẳng ai có lý do để biến lời giải đó thành thứ dùng lại được.
Glean chọn chiều ngược lại. Câu “thứ bạn xây sẽ được Glean đưa vào sản phẩm” là một cam kết về mô hình vận hành, không chỉ là lời quảng cáo. Underdog, trong hướng dẫn nghề nghiệp năm 2026, mô tả cùng ý: FDE biến sự hỗn loạn ở phía khách hàng thành hiểu biết về sản phẩm mà công ty có thể dùng lại.
Đặt tin tuyển của Glean cạnh cảnh báo của Otter, bạn có một bảng để soi bất kỳ tin FDE nào:
| Khía cạnh | Vị trí triển khai mang nhãn FDE | Founding FDE kiểu Glean |
|---|---|---|
| Điểm bắt đầu | Sản phẩm có sẵn, cần cài cho chạy | Bài toán kinh doanh chưa ai giải |
| Đầu ra | Một dự án hoàn thành cho một khách | Phần mềm sau đó vào sản phẩm chung |
| Ai trả công cho thời gian | Thường là khách, theo dự án | Công ty, vì kết quả nuôi roadmap |
| Kinh nghiệm cần chứng minh | Cấu hình, tích hợp, hỗ trợ | Tự xây production từ đầu khi yêu cầu mơ hồ |
| Người làm việc cùng | Đội hỗ trợ, đội bán hàng | Forward Deployed PM, lãnh đạo cấp C |
Cột bên trái không phải là việc kém giá trị. Nó chỉ là một nghề khác, cần một CV khác và mở ra một con đường sự nghiệp khác.
Thử hình dung một tuần ở khách hàng
Giả sử khách hàng chiến lược là một công ty bảo hiểm, đội pháp chế mất nhiều giờ mỗi tuần để dò điều khoản trong hợp đồng. Một kỹ sư triển khai sẽ hỏi: nên kết nối với hệ thống lưu trữ nào, phân quyền ra sao? Đó là những câu hỏi đúng, nhưng chúng bắt đầu từ sản phẩm.
Một Founding FDE sẽ hỏi trước về kinh doanh: quyết định nào đang bị chậm, chậm thì công ty mất gì, ai ký duyệt. Có thể bài toán thật không nằm ở tìm kiếm mà ở việc so sánh hợp đồng mới với mẫu chuẩn.
Khi đó kỹ sư dựng một agent nhỏ, viết bộ eval từ các ca thật của đội pháp chế, và chỉ đưa lên production khi điểm eval đủ tin cậy.
Bước cuối mới phân biệt hai vai trò: viết lại lời giải để khách hàng thứ hai, thứ ba cũng dùng được. Theo mô hình của Glean, đó là lúc thứ được xây cho một khách trở thành tính năng của cả sản phẩm.
Một pod, một ghế cạnh lãnh đạo, và rất nhiều chuyến bay
Tin tuyển của Glean, đăng trên trang việc làm của General Catalyst, cho biết vị trí này làm trong một pod cùng Forward Deployed PM và là đối tác kỹ thuật của lãnh đạo cấp C phía khách hàng.
Cấu trúc này nói lên nhiều điều. Có một PM đi cùng nghĩa là kỹ sư không phải tự gánh hết phần định hình sản phẩm, nhưng họ vẫn phải tranh luận ngang hàng về việc nên xây gì.
Tin còn yêu cầu bạn làm việc với sự tự chủ và trách nhiệm của một founder. Thực tế, điều đó có nghĩa là không ai đưa ticket cho bạn. Bạn tự chọn bài toán, tự chịu trách nhiệm nếu chọn sai.
Đi kèm là một chi phí cá nhân cụ thể: vị trí đòi hỏi đi công tác 25–50% thời gian. Nếu hoàn cảnh gia đình không cho phép, hãy biết điều đó trước khi bước vào vòng phỏng vấn. Đừng để đến lúc nhận offer mới cân nhắc.
Phần AI không phải để trang trí
Mức sàn của tin là hơn 4 năm làm vai trò kỹ thuật, có thành tích đưa phần mềm lên production. Nhưng tin nêu rõ một vùng kinh nghiệm nữa: phát triển agent, khung đánh giá (evaluation framework) và triển khai ở quy mô lớn.
Ba thứ này đi với nhau có lý do. Một agent dựng trong một tuần ở khách hàng thì ai cũng làm được bản demo. Thứ tách người làm 0-to-1 thật ra khỏi người làm demo là eval: bạn có biết khi nào agent đủ tốt để lên production không, và chứng minh được điều đó với lãnh đạo khách hàng không.
Vì thế, nếu bạn đang chuyển từ backend hay data engineering sang, đừng chỉ học cách gọi API của mô hình. Hãy học cách viết bộ eval từ dữ liệu thật và cách theo dõi agent khi lưu lượng tăng. Đó là phần mà các tin tuyển dụng kiểu này đang kiểm tra.
Chứng minh 0-to-1 trên giấy thế nào?
Phần lớn CV kỹ sư được viết như một danh sách công nghệ và hệ thống từng làm. Với vị trí như Founding FDE ở Glean, cách viết đó giấu đi đúng thứ người tuyển cần thấy.
Họ không hỏi bạn biết Kubernetes hay không. Họ hỏi bạn đã bao giờ bắt đầu từ một vấn đề chưa có lời giải và kết thúc bằng phần mềm có người dùng thật chưa.
Hãy viết mỗi dự án quan trọng theo bốn nhịp: vấn đề kinh doanh, chỗ mơ hồ ban đầu, thứ bạn tự xây, và nơi nó được dùng lại sau đó. Nhịp cuối là nhịp mà hầu hết mọi người bỏ qua, nhưng chính nó trả lời câu hỏi của Otter: bạn làm cho dự án hay cho sản phẩm.
Khi đọc tin tuyển, hãy làm phép thử ngược lại. Nếu tin chỉ nói về cấu hình, onboarding và hỗ trợ demo, đó là vị trí triển khai, dù chức danh có ghi FDE.
Nếu tin nói về xây từ đầu, về roadmap, về làm việc với lãnh đạo khách hàng, bạn đang nhìn vào một vị trí sản phẩm, và cần chuẩn bị câu chuyện 0-to-1 của mình.
Chữ “Founding” trong chức danh nghe như một danh hiệu. Đọc kỹ tin của Glean thì thấy nó là một câu hỏi phỏng vấn: bạn đã từng tự tạo ra thứ gì chưa từng tồn tại, khi không ai nói cho bạn biết nó phải trông như thế nào?
Bài này có hữu ích không?
Cảm ơn bạn đã góp ý!