Column tuyển FDE: ngân hàng bán API cũng cần người ngồi cạnh khách

Một tin tuyển đăng ngày 6/10/2026 cho thấy Column, ngân hàng bán dịch vụ dưới dạng API, đang tìm một Forward Deployed Engineer ở San Francisco. Người này sẽ là người chịu trách nhiệm kỹ thuật cho các khách hàng chiến lược, từ lúc onboarding đến ngày launch.

Nhìn qua thì nghe như nghịch lý. API của Column được mô tả bằng một OpenAPI spec và có sandbox, đúng kiểu sản phẩm mà khách lẽ ra tự đọc docs, tự gọi endpoint, tự xong việc. Vậy cần một kỹ sư ngồi cạnh khách để làm gì?

Câu trả lời đáng để bạn nghĩ kỹ nếu đang làm hoặc nhắm tới FDE. Khi sản phẩm là API, chỗ khách tích hợp chính là sản phẩm.

Người đứng ở chỗ đó, nếu được giao quyền, không chỉ giúp khách chạy được mà còn mang những chỗ khách vấp về để sửa chính sản phẩm, và đó là ranh giới giữa một FDE thật với một vai trò hỗ trợ khách mang tên mới.

Ngân hàng của kỹ sư, nhưng không xây từ số không

Column tự giới thiệu là ngân hàng duy nhất có giấy phép cấp quốc gia được thiết kế để giúp khách xây và cấp vốn cho sản phẩm tài chính mới. Công ty nói mình do kỹ sư lập ra, để giải quyết chính những bực bội khi làm việc với các ngân hàng hiện có.

Có điều, “ngân hàng của kỹ sư” không có nghĩa là dựng từ đầu. Theo một wiki của một hãng luật, nhà sáng lập đã mua lại một ngân hàng chỉ có một chi nhánh ở Chico, California, thay vì lập thêm một startup.

Chi tiết đó quan trọng với FDE hơn vẻ ngoài. Bên dưới lớp API là một ngân hàng thật: tin tuyển Solutions Engineer của Column liệt kê cả nhiệm vụ về quy định và rủi ro. Người đứng giữa khách và API vì thế phải hiểu cả code lẫn những ràng buộc mà một spec không diễn giải hết.

Vì sao docs tốt vẫn không đủ?

Thử hình dung một startup muốn nhúng tài khoản và chuyển tiền vào ứng dụng của mình. Đội của họ đọc docs, dựng xong luồng trên sandbox khá nhanh. Rồi họ vướng ở những chỗ docs không viết: đối soát thế nào khi một khoản chuyển bị trả về, mô hình hoá tài khoản cho khách cuối ra sao, việc gì phải xong trước ngày launch.

Nếu mỗi câu hỏi đi qua một ticket, đội của khách mất nhiều ngày chờ, còn phía ngân hàng thấy mười ticket rời rạc. Nhưng nếu mười khách chiến lược cùng vấp đúng một chỗ, đó không phải mười ca hỗ trợ, mà là một lỗi của docs hoặc của thiết kế API. Chỉ người theo trọn một ca tích hợp mới nhìn ra mẫu lặp đó.

Đó là lý do tin tuyển của Column ghép hai việc vào một người. FDE làm trực tiếp với đội kỹ thuật của đối tác để thiết kế, xây và launch sản phẩm, đồng thời làm sát với đội kỹ thuật của Column để định hình API, docs và trải nghiệm lập trình viên.

FDE khác Solutions Engineer ở chỗ nào?

Column không thiếu kỹ sư hướng khách hàng. Vị trí Solutions Engineer của công ty hỗ trợ quan hệ kỹ thuật với khách qua pre-sales, triển khai, onboarding và support, và tin tuyển tự nhận vai trò này đòi hỏi kỹ thuật cao hơn mức trung bình của nghề.

Vì cả hai đều nặng kỹ thuật, khác biệt khó nằm ở trình độ. Đọc câu chữ hai tin tuyển, khác biệt nằm ở chặng: Solutions Engineer trải rộng từ trước bán hàng đến hậu mãi, còn FDE nhận trọn một đoạn hẹp hơn, từ onboarding đến launch, với tư cách người chịu trách nhiệm kỹ thuật, kèm quyền góp tay vào chính sản phẩm.

Đặt tin tuyển này cạnh các định nghĩa độc lập về FDE sẽ rõ hơn đâu là phần Column nói chắc và đâu là phần bạn phải tự hỏi. CRV, quỹ đầu tư mạo hiểm, coi đặc trưng của FDE là viết production code trong môi trường của khách, và cho rằng FDE có thể trải cả trước lẫn sau bán hàng mà vẫn code.

PostHog mô tả FDE là người nhúng vào đội của khách để lấp khoảng trống giữa sản phẩm và nhu cầu thật. Tin tuyển Forward Deployed Software Engineer của Palantir ghi rằng kỹ sư làm việc với khách, thường là tại chỗ, để hiểu và giải quyết vấn đề của họ.

Tiêu chí FDE	Nguồn	Tin tuyển FDE của Column	Câu hỏi nên đặt khi phỏng vấn
Viết production code ở môi trường khách	CRV	Cùng đội kỹ thuật của đối tác thiết kế, xây và launch	Code bạn viết nằm trong repo của khách hay của Column?
Trải cả trước và sau bán hàng	CRV	Từ onboarding đến launch; pre-sales thuộc Solutions Engineer	Bạn nhận khách từ ai, và có mặt từ thời điểm nào?
Lấp khoảng trống giữa sản phẩm và nhu cầu	PostHog	Cùng engineering định hình API, docs, trải nghiệm lập trình viên	Lần gần nhất phản hồi của khách làm đổi API là khi nào?
Thường làm tại chỗ khách	Palantir	Tin tuyển không nói	Bạn ngồi ở đâu, bao nhiêu thời gian với khách mỗi tuần?

Cột cuối là phần quan trọng nhất. Tin tuyển cho bạn lời hứa; câu trả lời ở vòng phỏng vấn cho bạn biết lời hứa đó có được thực hiện hay không.

Đọc tin tuyển FDE như một kỹ sư

PostHog lưu ý rằng có công ty dùng chức danh FDE cho công việc gần với sales engineer. Vì thế, hai tin cùng mang chữ FDE không bảo đảm cùng một công việc, ở bất kỳ nước nào.

Dấu hiệu nằm ở động từ. Khi tin tuyển nói FDE sẽ định hình API, docs hay nền tảng, như ở Column, vai trò có đường đi ngược vào sản phẩm. Khi tin chỉ nói về hỗ trợ và đồng hành, hãy hỏi thẳng ai đã đẩy thay đổi gần nhất từ khách vào sản phẩm.

Một dòng khác trong tin của Column cũng đáng để ý: ứng viên cần kỹ năng quản lý dự án mạnh, chạy được nhiều engagement cùng lúc và giữ cho từng cái tiếp tục tiến lên.

Đưa cả hai nửa của vai trò vào CV

Nếu bạn từng sửa docs sau khi thấy khách hỏi đi hỏi lại một câu, hay đề xuất đổi một endpoint vì nó khiến người tích hợp đoán sai, hãy đưa nó lên đầu CV. Với một vai trò được mô tả như tin của Column, đây là bằng chứng sát nhất rằng bạn biết biến vấn đề lộn xộn của khách thành thay đổi cụ thể trong sản phẩm.

Cách viết cũng quan trọng. Thay vì “hỗ trợ khách tích hợp API”, hãy viết theo chuỗi: khách gặp vấn đề gì, bạn chịu trách nhiệm phần nào đến tận launch, bạn song song theo bao nhiêu khách, và bạn đã đưa gì về cho đội sản phẩm.

Nếu chưa có kinh nghiệm đó, cách rẻ nhất là tự làm người tích hợp. Chọn một API có sandbox công khai, xây một luồng nhỏ, ghi lại mọi chỗ phải đoán, rồi viết danh sách ấy thành đề xuất sửa docs và API. Đó là thứ gần nhất với việc hằng ngày của một FDE ở công ty bán API.

Tin tuyển FDE cho thấy câu trả lời thứ hai: một người đứng giữa vấn đề của khách và spec đó, để spec ngày càng ít bắt khách phải đoán.