Công ty AI y tế tuyển FDE nhưng kinh nghiệm y tế chỉ là điểm cộng

Hippocratic AI làm AI cho y tế. Tin tuyển Forward Deployment Engineer tại York, Pennsylvania của họ xếp kinh nghiệm tích hợp y tế (HL7/FHIR, Epic/Cerner) vào mục điểm cộng. Thứ bắt buộc lại là sẵn sàng được triển khai onsite tại khách hàng trong thời gian dài.

Chi tiết này đi ngược trực giác của hầu hết lập trình viên đang cân nhắc chuyển sang FDE. Câu hỏi quen thuộc là: nên chọn một ngành (ngân hàng, logistics, y tế) để đào sâu, hay giữ mình là generalist để đi đâu cũng được? Tin tuyển của một công ty vertical rõ ràng như Hippocratic AI gợi ý rằng câu hỏi đó đặt sai chỗ.

Nếu bạn có 2–8 năm kinh nghiệm và đang nhắm vai FDE, cách bạn trả lời câu này quyết định bạn học gì năm tới, viết CV thế nào và lọc JD ra sao. Vì thế đáng bỏ công nhìn kỹ hai phe đang tranh cãi, rồi chỉ ra họ thật ra nói về hai thứ khác nhau.

Hai phe nghe như mâu thuẫn

Phe generalist có nhiều tiếng nói hơn. Paraform viết thẳng rằng hầu hết vị trí kỹ sư cho phép bạn chuyên sâu, còn FDE thì không có được sự xa xỉ ấy. Aced (trước là Exponent) đi xa hơn: với FDE, bề rộng thắng bề sâu, ngược hẳn với SWE.

Andrew Stroup, một practitioner, bổ sung lý do vì sao. Kỹ năng embed, theo ông, dùng được ở nhiều ngành vì mẫu hình gốc không thuộc riêng ngành nào: đi vào thực tế vận hành của khách rồi xây giải pháp khớp với thực tế ấy.

Phe ngược lại ít tiếng nói hơn nhưng lập luận cũng chắc. Valletta Software cho rằng giá trị của FDE nằm ở domain knowledge, và loại kiến thức đó chỉ tích lũy được qua thời gian trong một bối cảnh. Forward deployment, theo họ, là đi sâu vào một đến ba khách hàng.

Đọc nhanh, hai phe cãi nhau. Đọc kỹ, chữ “sâu” của Valletta không phải chữ “sâu” mà Paraform và Aced bác bỏ.

Có hai kiểu “sâu”, và cả hai đều không mang theo trọn vẹn

Kiểu thứ nhất là sâu theo ngành, chọn từ trước: bạn quyết định năm nay mình là “dân y tế”, học HL7, học quy trình bệnh viện, rồi mới đi tìm việc. Lời cảnh báo của Paraform nói về vai FDE nói chung, nhưng đọc theo cách này thì nó áp vào kiểu chuyên sâu ấy rõ nhất.

Đây cũng là loại kiến thức mà tin tuyển của Hippocratic AI xếp vào điểm cộng.

Kiểu thứ hai là sâu theo account, tích lũy: bạn ngồi trong vận hành của một khách hàng đủ lâu để biết exception nào quan trọng, hệ thống nào thật ra đang chạy, ai quyết định cái gì. Đây là kiểu Valletta nói đến, và nó đến từ việc có mặt chứ không từ việc chọn ngành trước.

Có thể đọc yêu cầu onsite dài hạn của Hippocratic AI theo hướng đó: thứ công ty này cần trước hết là người chịu ngồi đủ lâu bên khách.

Aced mô tả FDE là T-shaped: sâu một mảng, rộng nhiều mảng, cộng kỹ năng làm việc với khách hàng. Nhưng thanh dọc của chữ T không nhất thiết là một ngành.

Thanh dọc là năng lực bước vào một bối cảnh lạ và xây đúng thứ bối cảnh đó cần, cái Stroup gọi là mẫu hình không thuộc riêng ngành nào. Thanh ngang là những ngành bạn đã đi qua; chi tiết của từng account ở lại với khách đó.

Đua về domain, kỹ sư đang chạy trên sân người khác

Có một lý do thực dụng hơn để không đặt cược vào sâu theo ngành. MindStudio chỉ ra rằng người đến từ operations, product hay consulting mang sẵn phán đoán về domain của khách: họ đã biết exception nào quan trọng và vì sao một sơ đồ quy trình gọn gàng lại vỡ ngoài đời thực. Khoảng trống của họ là độ sâu kỹ thuật.

Hệ quả có thể suy ra: ở mảng hiểu ngành, kỹ sư phải cạnh tranh với những người đã có sẵn phán đoán đó, còn lợi thế của bạn nằm đúng ở chỗ họ thiếu. Nếu bạn, một lập trình viên, dành hai năm để cạnh tranh về kiến thức ngành, bạn đang chạy đua trên sân nhà của họ.

Palantir đã thể chế hóa một sự phân công tương tự. Theo Paraform, deployment strategist ở đó sở hữu toàn bộ phần upstream, từ requirements đến stakeholders, trong khi kỹ sư build. Framing vấn đề và engineering tách thành hai vai.

Đó là lý do câu hỏi đúng cho kỹ sư không phải “ngành nào” mà là “sâu kỹ thuật ở đâu”. Ở đây bản phân tích tháng 5/2026 của The Pragmatic Engineer đưa ra một gợi ý khó chịu: vai FDE hiện đại về bản chất là consultant hoặc solutions architect, nghiêng về tư vấn và tích hợp hơn là build phần mềm mới.

Nếu đúng vậy, thanh dọc kỹ thuật của FDE nhiều khả năng là tích hợp: nối hệ thống cũ, dữ liệu bẩn, quyền truy cập, API nửa chừng, không phải thuật toán đẹp.

Giai đoạn công ty quyết định bạn phải rộng đến đâu

Còn một biến nữa mà cả hai phe ít nói: bạn vào công ty ở giai đoạn nào. Valletta mô tả một startup năm mươi người, nơi một người vừa là sales engineer, vừa là solutions architect, vừa là FDE. Ở đó bề rộng không phải lựa chọn, nó là mô tả công việc.

Paraform khuyên đúng theo hướng này: bắt đầu với FDE gánh cả hai chức năng, rồi tách khi độ phức tạp triển khai vượt quá sức một người. Nên cùng chữ “FDE”, nội dung công việc dịch chuyển theo tuổi của tổ chức.

Bối cảnh	Ai gánh phần “hiểu ngành”	Kỹ sư cần rộng hay sâu
Startup khoảng 50 người (Valletta)	Chính bạn, kiêm sales engineer và solutions architect	Rộng gần như toàn bộ; sâu theo account tích lũy dần
Tổ chức đã tách vai kiểu Palantir (Paraform)	Deployment strategist sở hữu upstream	Kỹ sư tập trung build; framing vấn đề nằm ở strategist
Công ty vertical AI (Hippocratic AI)	Công ty đã chọn ngành thay bạn	Kiến thức ngành là điểm cộng; onsite dài hạn là bắt buộc

Bảng cho thấy không có câu trả lời chung cho “chuyên sâu hay generalist”. Thứ thay đổi theo giai đoạn là bao nhiêu phần framing ngành rơi lên vai bạn.

Lập trình viên Việt Nam nên đặt cược vào đâu

Với một kỹ sư 2–8 năm ở Việt Nam, lời khuyên thực dụng là: đừng vội chọn ngành lúc này. Hãy chọn thanh dọc.

Luyện những kỹ năng tích hợp ít hào nhoáng: đọc một hệ thống legacy không có tài liệu, map dữ liệu từ schema lạ, dựng pipeline chạy được trong môi trường của khách chứ không phải laptop của bạn, và nói chuyện với người vận hành đủ lâu để biết exception nào họ sợ.

Nếu bạn từng làm outsourcing qua vài ngành khác nhau, đó không phải điểm yếu “không chuyên” như nhiều người tự ti. Nó chỉ có giá trị khi bạn kể lại được ở mỗi dự án mình đã học ngành đó nhanh thế nào và điều gì trong vận hành thực tế khác với spec ban đầu.

Trên CV, thay dòng “kinh nghiệm ngành X” bằng những câu có cấu trúc “vào bối cảnh Y, phát hiện Z khác với giả định, điều chỉnh những gì đang build”.

Khi đọc JD, hãy tách hai cột như Hippocratic AI đã vô tình làm giúp bạn: cột must-have cho biết công việc thật, cột nice-to-have cho biết công ty hy vọng gì. Nếu kiến thức ngành nằm ở cột hai, đừng để nó cản bạn nộp.

Kiến thức ngành, như Valletta nhận xét, sẽ tích lũy dần khi bạn ở đủ lâu trong một bối cảnh. Việc của bạn là trở thành người được cử đến bối cảnh đó: đủ vững về tích hợp và sẵn sàng onsite, thứ mà ngay cả một công ty AI y tế cũng đặt lên trên kinh nghiệm y tế.