# CV FDE: bỏ danh sách framework, kể kết quả triển khai bằng con số có mốc so sánh

> Người tuyển FDE đọc CV để tìm một kết quả họ có thể kiểm tra lại, nên một dòng “LangChain, Kafka, Kubernetes” gần như không cho họ thông tin gì.

Bản gốc: https://fdetimes.net/vi/phan-tich/cv-fde-ke-ket-qua-trien-khai-thay-vi-liet-ke-framework/

“Giảm thời gian deployment từ 6 tuần xuống 9 ngày.” Hướng dẫn viết CV FDE của Aced (trước đây là Exponent) đưa câu này ra làm ví dụ mẫu, đặt cạnh một câu chung chung kiểu “cải thiện hiệu quả”. Lời khuyên của họ rất thẳng: mỗi bullet phải kết thúc bằng một con số.

Lời khuyên nghe giống mẹo viết CV quen thuộc. Thực ra nó nói lên cách bên tuyển FDE đọc hồ sơ. Họ không tìm người đã chạm vào nhiều công cụ nhất. Họ tìm người từng đưa một hệ thống vào vận hành ở chỗ khách hàng và chứng minh được nó tạo ra thay đổi.

Với nhiều developer Việt Nam, CV vẫn xếp theo stack: dự án nào, dùng Spring hay FastAPI, Kafka hay RabbitMQ. Cách viết đó hợp với vòng lọc từ khóa của một vị trí backend. Khi nộp vào vị trí FDE, nó lại giấu mất thứ người tuyển cần thấy nhất.

## Framework chỉ là điều kiện tối thiểu

Tin tuyển Forward Deployed Software Engineer của Palantir cho thấy rõ thứ tự ưu tiên. Ngôn ngữ lập trình xuất hiện như một yêu cầu nền: phải code tốt và thành thạo những ngôn ngữ như Python, Java, C++.

Phần mô tả công việc thì nói về chuyện khác: làm việc trực tiếp với khách hàng và tự làm chủ việc thực thi các dự án quan trọng từ đầu đến cuối.

Palantir còn ghi Ownership thành một giá trị riêng. Họ định nghĩa đó là theo dự án từ lúc bắt đầu đến khi xong, vượt qua mọi trở ngại gặp phải. Một danh sách framework không chứng minh được điều này. Nó chỉ cho thấy bạn đã đi qua những công cụ đó, không cho thấy bạn đã đưa việc gì đến đích.

Aced cũng nói đúng ý ấy: người tuyển FDE đặt quyền làm chủ và tác động lên khách hàng lên trên độ phức tạp kỹ thuật thuần túy.

Vì vậy mục Skills nên chỉ gồm những kỹ năng liên quan đến vị trí mà bạn nói chuyện được một cách đáng tin, không phải mọi thứ bạn từng dùng.

Liệt kê quá tay sẽ quay lại hại bạn trong phòng phỏng vấn, khi người hỏi chọn đúng cái tên bạn hiểu ít nhất.

**Điểm mấu chốt:** Framework cho thấy bạn biết dùng gì, con số cho thấy khách hàng nhận được gì.

## Công thức của Google vẫn dùng được

Cách viết này không do giới FDE nghĩ ra. Năm 2015, Laszlo Bock, khi đó là người đứng đầu bộ phận nhân sự của Google, trả lời trong một buổi AMA trên Reddit rằng mọi thành tích nên viết theo dạng “đạt được X bằng cách làm Y, đo bằng Z”. Lời khuyên chung của ông là phải làm rõ tác động của công việc mình làm.

Áp vào FDE, ba thành phần đó có nghĩa cụ thể hơn. X là thay đổi ở phía khách hàng, chẳng hạn một quy trình nhanh hơn, ít lỗi hơn hoặc một quyết định được đưa ra sớm hơn. Y là việc bạn tự tay xây hoặc tự dẫn dắt. Z là con số, và trong FDE nó gần như luôn có mốc trước và mốc sau.

Các bullet mẫu của Aced đi đúng khuôn này. Một dòng về data pipeline nói rằng thời gian đến insight đầu tiên giảm từ 3 tháng xuống 3 tuần. Những dòng khác đo độ trễ của hệ thống RAG hoặc số giờ tiết kiệm được nhờ một bộ công cụ dùng lại nhiều lần. Không dòng nào mở đầu bằng tên thư viện.

## Viết lại một bullet, từng bước

Thử hình dung một developer ở công ty outsource tại Hà Nội vừa làm xong dự án cho một khách hàng logistics. Bullet hiện tại của anh ấy:

“Phát triển hệ thống RAG với LangChain, Pinecone, FastAPI.”

Ba tên công cụ, không có khách hàng, không có kết quả. Giờ đi qua công thức của Bock. X: đội chăm sóc khách hàng tra cứu chính sách vận chuyển nhanh hơn. Y: anh ấy ngồi với đội đó để lấy câu hỏi thật, dựng pipeline truy xuất rồi đưa vào công cụ họ đang dùng hằng ngày.

Z: giả sử trước đây mỗi lượt tra cứu mất 4 phút, sau khi triển khai còn 40 giây, đo trong 30 ngày đầu chạy production. Ghép ba phần lại, bullet mới đọc như sau:

“Giảm thời gian tra cứu chính sách vận chuyển của đội chăm sóc khách hàng từ 4 phút xuống 40 giây mỗi lượt (đo trong 30 ngày đầu chạy production), bằng cách thu thập câu hỏi thật từ đội này, xây pipeline truy xuất và tích hợp vào công cụ họ dùng hằng ngày.”

Đặt hai dòng cạnh nhau, khác biệt nằm ở chủ ngữ. Dòng cũ nói về công cụ, dòng mới nói về đội vận hành của khách hàng. Các con số 4 phút, 40 giây, 30 ngày ở đây chỉ để minh họa; con số thật phải đến từ log, ticket hoặc báo cáo của chính dự án bạn làm.

Tên LangChain hay Pinecone vẫn có thể giữ trong mục Skills, nếu bạn giải thích được vì sao chọn chúng. Chúng chỉ không còn là phần chính của dòng nữa.

## Con số sẽ bị hỏi lại

Đến đây nhiều người dễ hiểu sai: cứ thêm con số là CV mạnh hơn. Con số giúp bạn được mời phỏng vấn, nhưng trong phòng phỏng vấn nó trở thành một tuyên bố phải bảo vệ. Paraform, nền tảng tuyển dụng, viết thẳng rằng CV không nói thật về mức độ sẵn sàng làm FDE, nên người phỏng vấn sẽ đào vào từng con số.

Thử hình dung người phỏng vấn đọc bullet logistics ở trên và dừng ở “4 phút”. Câu hỏi đầu tiên gần như chắc chắn là: baseline đo ở đâu? Tiếp theo: ai xác nhận con số sau triển khai? Và cuối cùng: trong toàn bộ việc này, phần nào do chính bạn làm?

Một câu trả lời mẫu có thể như sau: “Baseline lấy từ log công cụ ticket của đội chăm sóc khách hàng trong hai tuần trước khi triển khai.

Số sau triển khai lấy từ cùng nguồn log đó, trong 30 ngày đầu chạy production, và trưởng nhóm bên khách đã duyệt báo cáo. Phần tự làm là pipeline truy xuất và phần tích hợp; giao diện do một đồng nghiệp phụ trách.”

Câu trả lời đó qua được vì nó có đúng ba thứ: nguồn đo, khoảng thời gian, người xác nhận, cộng với ranh giới rõ ràng về phần việc của mình. Christian & Timbers, công ty tuyển dụng nhân sự cấp cao, yêu cầu đúng điều này: tuyên bố càng lớn thì càng phải kèm mốc ban đầu và khoảng thời gian đo.

Họ còn đặt chuẩn cao hơn một bước: phần việc kỹ thuật của FDE phải dẫn đến một workflow chạy production với kết quả đo được, và doanh nghiệp nên tìm người đã triển khai agentic AI nhiều lần, gắn với kết quả tài chính có ghi nhận. Vì thế câu hỏi tiếp theo rất có thể là: bạn đã làm lại việc này ở khách hàng thứ hai chưa?

Xếp các tiêu chí tuyển dụng vào một bảng sẽ thấy mỗi bullet phải trả lời những gì, cả trên giấy lẫn trong phòng phỏng vấn:

| Bên tuyển | Họ kiểm tra điều gì | Bullet cần có | Phải sẵn sàng trả lời trong phỏng vấn |
|---|---|---|---|
| Palantir | Làm chủ dự án từ đầu đến cuối | Bạn sở hữu phần nào, đưa đến đâu | Trở ngại nào bạn tự vượt qua |
| Aced | Tác động lên khách hàng hơn độ phức tạp | Một con số cho mỗi dòng | Mọi kỹ năng ghi trong mục Skills |
| Christian & Timbers | Workflow production, kết quả lặp lại | Hệ thống đã vào vận hành, không dừng ở demo | Mốc ban đầu và khoảng thời gian đo |
| Paraform | CV là tín hiệu yếu | Câu chuyện có thể kể lại chi tiết | Bạn đã làm gì, theo thứ tự nào |

Từ những câu hỏi đó, có ba lỗi hay khiến một bullet đẹp sụp đổ ngay trong buổi phỏng vấn.

**Phần trăm thổi phồng.** Một dòng “tăng hiệu suất 300%” nghe ấn tượng, nhưng chỉ cần một câu “300% của cái gì?” là lộ. Một con số nhỏ mà trung thực an toàn hơn nhiều.

**Nhận kết quả của cả đội là của mình.** Nếu bạn lúng túng khi được hỏi phần nào mình tự làm, giá trị của con số mất luôn. Ownership mà Palantir tìm là theo việc của mình đến cùng, không phải đứng tên thành tích chung.

**Con số không có mốc.** “Giảm 70% thời gian xử lý” mà không nói từ bao nhiêu, đo trong bao lâu thì không ai kiểm chứng được, và người phỏng vấn sẽ coi như dòng đó không tồn tại.

## Dev Việt nên bắt đầu từ đâu

Khó khăn thường gặp với người làm outsource là không có số liệu vì khách hàng giữ hết. Cách khắc phục nằm trong chính công việc: từ dự án tới, ngay tuần đầu hãy ghi lại mốc ban đầu, như quy trình hiện tại mất bao lâu, lỗi bao nhiêu lần, cần bao nhiêu bước thủ công. Không có mốc trước thì sau này không có Z.

Khi đọc JD FDE, hãy chú ý những cụm như “end-to-end”, “làm việc trực tiếp với khách hàng”, “production”. Gặp những cụm này, hãy xếp bullet theo kết quả cho khách hàng, đừng xếp theo stack. Nếu JD chỉ toàn tên framework, có thể đó là một vị trí backend được đặt tên khác.

Trước khi gửi CV, đọc lại từng con số và tự hỏi ba câu ở trên: đo ở đâu, ai xác nhận, phần nào của mình. Con số nào không trả lời được cả ba thì bỏ, vì người tuyển FDE sẽ hỏi cho đến khi có câu trả lời.

CV FDE tốt nhất đọc lên giống một loạt biên bản bàn giao: khách hàng nào, thay đổi gì, đo bằng cách nào. Phần stack, người phỏng vấn sẽ tự hỏi khi họ đã muốn nghe tiếp.

**Thử ngay tuần này:**

- Chọn ba bullet trong CV hiện tại và viết lại từng dòng theo dạng “đạt X cho khách hàng bằng cách làm Y, đo bằng Z”, có ghi mốc trước và sau.
- Với mỗi con số, ghi riêng một dòng nháp: đo từ đâu, trong bao lâu, ai xác nhận, phần nào do bạn tự làm. Nếu không trả lời được thì bỏ con số đó.
- Cắt mục Skills chỉ còn những công cụ bạn nói chuyện được 10 phút mà không cần tra cứu.

## Nguồn

- [Forward Deployed Engineer Resume: Examples & Skills (2026) - Aced (formerly Exponent)](https://www.aced.io/blog/forward-deployed-engineer-resume-examples-skills-2026)

- [Forward Deployed Engineer Resume: Examples & Skills (2026) - Aced (formerly Exponent)](https://www.aced.io/blog/forward-deployed-engineer-resume)

- [Palantir Technologies - Forward Deployed Software Engineer](https://jobs.lever.co/palantir/bf718bd3-b2ef-451e-8033-cb4d2d9c094b)

- [How to Hire Elite Forward Deployed Engineers](https://www.christianandtimbers.com/insights/how-to-hire-elite-forward-deployed-engineers)

- [How To Hire Your First Forward Deployed Engineer 2026 | Paraform](https://www.paraform.com/blog/how-to-hire-forward-deployed-engineer)

- [Advice for Job-switchers and Newbies from Google's Hiring Chief](https://www.govexec.com/management/2015/04/advice-job-switchers-and-newbies-googles-hiring-chief/111508/)