# CV Forward Deployed Engineer một trang: cấu trúc, cách viết kết quả triển khai và mẫu từng mục

> Người tuyển FDE không hỏi trước tiên bạn dùng framework nào; họ muốn biết khách hàng nào đã làm việc khác đi nhờ bạn, và nhanh hơn bao nhiêu.

Bản gốc: https://fdetimes.net/vi/bach-khoa/cv-forward-deployed-engineer-mau/

Hãy so hai dòng. Dòng đầu viết "cải thiện hiệu quả triển khai". Dòng sau viết "rút thời gian triển khai từ 6 tuần xuống 9 ngày". Hướng dẫn viết CV FDE của Aced dùng đúng cặp này để chỉ ra một bên là câu mô tả chung chung, bên kia là câu cho thấy bạn đã làm được gì.

Với vị trí Forward Deployed Engineer, khoảng cách giữa hai dòng đó đáng để bạn sửa từng chữ. FDE là người đưa phần mềm vào chạy ở chỗ khách hàng, nên CV của bạn cũng cần chứng minh điều đó ngay từ những dòng đầu.

Bài này hướng dẫn từng bước để dựng một CV FDE một trang. Bạn sẽ có một file văn bản có khung sẵn, ba đến năm bullet viết lại theo công thức kết quả trước, và một danh sách tự kiểm tra tính trung thực trước khi gửi.

## Cần chuẩn bị gì trước khi mở trình soạn thảo?

Bạn chưa cần đến mẫu thiết kế đẹp. Thứ cần có là nguyên liệu: danh sách các dự án đã làm, ai dùng chúng, và con số trước/sau mà bạn thật sự đo được hoặc có thể kiểm chứng. Không có con số thì ghi rõ là chưa có, đừng ước lượng cho đẹp.

Một mẹo thực tế là viết CV ở dạng văn bản thuần trước, như Markdown hay file text, rồi mới chuyển sang định dạng cuối. Làm vậy bạn sẽ tập trung vào nội dung, không mất buổi tối chỉnh lề.

## Bước 1: Chọn độ dài, và nó gần như luôn là một trang

Aced khuyên giữ CV FDE trong một trang, chỉ dùng hai trang khi bạn có từ 8 năm kinh nghiệm trở lên. Với người có 2 đến 8 năm, quy tắc này buộc bạn chọn lọc. Đó cũng chính là kỹ năng một FDE cần khi trình bày cho khách hàng.

Kiểm tra sau bước này: in thử hoặc xuất PDF. Nếu sang trang hai mà bạn chưa có 8 năm, hãy cắt bớt trước khi viết thêm.

## Bước 2: Dựng khung ba phần mà người tuyển quét được

Final Round AI mô tả cấu trúc một trang gồm phần tóm tắt hoặc mục tiêu, phần kỹ năng và phần kinh nghiệm làm việc dạng bullet. Họ khuyên nhóm kỹ năng theo từng nhóm để dễ quét. Khung tối thiểu trông như sau:

```text
HỌ TÊN — email — link GitHub/portfolio

TÓM TẮT
[1-2 câu: bạn đã đưa loại hệ thống nào vào chạy cho loại người dùng nào]

KỸ NĂNG
Lập trình:      [ngôn ngữ bạn viết production được]
Dữ liệu/hạ tầng: [công cụ đã dùng thật]
Làm việc với KH: [discovery, demo, đào tạo người dùng...]

KINH NGHIỆM
Công ty — Vai trò — Thời gian
- [bullet kết quả]
- [bullet kết quả]
```

Phần kỹ năng chia nhóm vì một lý do cụ thể. Tin tuyển FDSE của Palantir yêu cầu một người lập trình vững, có năng lực đã được chứng minh với các ngôn ngữ như Python, Java, C++. Người đọc cần thấy ngay dòng "Lập trình", không phải tìm nó giữa hai mươi tên công cụ xếp lộn xộn.

Kiểm tra: che toàn bộ CV, chỉ để lộ phần tóm tắt và nhóm kỹ năng. Nếu một người lạ đọc xong vẫn không đoán được bạn từng làm với khách hàng, phần tóm tắt cần sửa lại.

## Bước 3: Viết bullet theo thứ tự kết quả trước, công nghệ sau

fde.academy liệt kê một lỗi thường gặp là mở đầu bullet bằng công nghệ thay vì kết quả. Bản nháp viết từ góc nhìn người dựng hệ thống, thay vì người dùng nó, rất dễ rơi vào lỗi này.

**Điểm mấu chốt:** Mở đầu bằng kết quả cho khách hàng, để công nghệ xuống cuối câu.

Thử làm một ví dụ. Giả sử bản nháp của bạn là:

```text
- Xây pipeline Python đồng bộ dữ liệu giữa CRM và hệ thống kế toán của khách hàng.
```

Câu này đúng nhưng không nói gì về giá trị. Bullet mẫu mà fde.academy đưa ra kết thúc bằng kết quả đo được gắn với quy mô: giảm 80% thời gian đồng bộ dữ liệu thủ công trên 20 tài khoản khách hàng. Đảo thứ tự lại, bản nháp trên thành:

```text
- Giảm 80% thời gian đồng bộ dữ liệu thủ công cho 20 tài khoản khách hàng
  bằng một pipeline Python nối CRM với hệ thống kế toán.
```

Công thức ở đây gồm bốn phần theo thứ tự: kết quả nghiệp vụ, con số, quy mô, rồi mới đến cách làm. Hai mẫu của Final Round AI theo đúng logic này. Một mẫu rút thời gian tạo báo cáo tuân thủ hằng tuần từ ba ngày xuống dưới hai giờ. Mẫu kia cắt 35% lỗi xử lý hồ sơ bồi thường.

Hai mẫu đó đáng học ở chỗ con số được gắn vào nghiệp vụ của khách hàng, tức báo cáo tuân thủ và hồ sơ bồi thường, chứ không gắn vào hệ thống của bạn. Chỉ số kiểu "latency giảm 40ms" chỉ nên dùng khi bạn nói được nó đã giúp ai làm việc gì.

Kiểm tra: đọc ba từ đầu tiên của mỗi bullet. Nếu đó là tên ngôn ngữ, framework hay cloud, hãy viết lại.

## Bước 4: Viết rõ ra rằng bạn đã ngồi với người dùng

Aced nói thẳng: nếu bạn đã nói chuyện với người dùng hoặc các bên liên quan, hãy viết điều đó ra. Lý do là làm việc trực tiếp với khách hàng là phần cốt lõi của vai trò FDE. Người đọc sẽ không tự suy ra điều này từ một bullet thuần kỹ thuật.

Tin tuyển của Palantir cho biết thêm thứ cần chứng minh: làm việc trong nhóm nhỏ và sở hữu toàn bộ quá trình thực thi lẫn triển khai của những dự án quan trọng. Một bullet tốt nối được cả hai ý:

```text
- Phỏng vấn [nhóm người dùng] tại [loại khách hàng] để xác định [vấn đề];
  tự dẫn dắt từ thiết kế đến go-live, kết quả: [con số trước → sau].
```

Kiểm tra: mỗi vị trí trong phần kinh nghiệm nên có ít nhất một bullet nhắc đến người dùng hoặc stakeholder cụ thể và một bullet cho thấy bạn sở hữu việc từ đầu đến cuối.

## Bước 5: Rà tính trung thực trước khi người phỏng vấn làm việc đó

Bước này nhiều người bỏ qua, và cũng là chỗ CV hỏng nhanh nhất. Aced cảnh báo về việc trình bày prototype như hệ thống production, vì người phỏng vấn sẽ hỏi sâu và chuyện đó lộ ra ngay. fde.academy cảnh báo một lỗi tương tự: mô tả việc nội bộ như thể đó là triển khai cho khách hàng.

Cũng theo fde.academy, dự án cá nhân chỉ có giá trị khi đã chạy với người dùng thật. Với side project, điều đó có nghĩa là hoặc đưa cho người thật dùng trước, hoặc để nó ra khỏi phần kinh nghiệm.

Nếu bạn đang làm kỹ sư sản phẩm và muốn chuyển sang FDE, đừng cố đổi tên việc nội bộ thành "triển khai cho khách hàng".

Hãy gọi đúng tên, kiểu "công cụ nội bộ cho [số] nhóm vận hành", rồi nói rõ người dùng là ai, bạn đã ngồi với họ thế nào và con số nào thay đổi.

Đó vẫn là bằng chứng về làm việc với người dùng, và nó đứng vững khi bị hỏi tiếp.

| Nếu thực tế là | Đừng viết | Hãy viết |
|---|---|---|
| Demo chạy trên dữ liệu mẫu | "Triển khai hệ thống" | "Xây prototype, kiểm chứng với [ai]" |
| Công cụ cho đồng nghiệp | "Triển khai cho khách hàng" | "Công cụ nội bộ cho [nhóm], [kết quả]" |
| Side project chưa ai dùng | Đặt ngang kinh nghiệm làm việc | Bỏ đi, hoặc đưa cho người thật dùng trước |

Kiểm tra: với mỗi bullet, tự hỏi "nếu bị hỏi tiếp ba câu, có trả lời được bằng chi tiết thật không?". Bullet nào không qua được thì sửa lại.

## Những lỗi nào vẫn hay lọt qua?

Lỗi đầu tiên là con số không có mốc so sánh. "Giảm 80%" chỉ có nghĩa khi người đọc biết 80% của cái gì và trên quy mô nào, đó là lý do mẫu của fde.academy kèm theo "20 tài khoản khách hàng".

Lỗi thứ hai là phần tóm tắt viết như lời tuyên bố mục tiêu, kiểu "mong muốn phát triển trong môi trường năng động". Phần tóm tắt nên dành để nêu một kết quả triển khai. Thử hình dung một bản trước và sau, mượn lại bullet mẫu ở Bước 3:

```text
TRƯỚC:
Kỹ sư phần mềm [số] năm kinh nghiệm, mong muốn phát triển
trong môi trường năng động.

SAU:
Kỹ sư phần mềm làm việc trực tiếp với đội vận hành của khách hàng;
gần nhất giảm 80% thời gian đồng bộ dữ liệu thủ công cho
20 tài khoản khách hàng, tự dẫn dắt từ discovery đến go-live.
```

Bản sau trả lời được đúng câu hỏi ở Bước 2: bạn đưa loại hệ thống nào vào chạy, cho ai, và kết quả ra sao. Dĩ nhiên con số phải là của chính bạn, không phải của mẫu.

Lỗi thứ ba khó thấy hơn: liệt kê mọi công cụ từng chạm vào. Dòng kỹ năng dài làm loãng đúng thứ Palantir muốn thấy là năng lực lập trình đã được chứng minh. Chỉ giữ những gì bạn sẵn sàng code trực tiếp trong buổi phỏng vấn.

## Kỹ năng này dùng lại ở chỗ khách hàng ra sao?

Viết một bullet theo thứ tự kết quả, con số, quy mô, cách làm cũng chính là cách một FDE viết email cập nhật cho khách hàng sau mỗi đợt triển khai. Khách hàng không quan tâm bạn đổi thư viện nào. Họ muốn biết báo cáo tuân thủ giờ mất bao lâu và lỗi hồ sơ giảm bao nhiêu.

Vì thế, khi đi làm, hãy tập ghi lại con số trước/sau ngay từ ngày đầu của mỗi dự án. Thời gian đồng bộ thủ công, số lỗi mỗi tuần, số người dùng thật đều là những con số nên ghi. Đến lần viết CV tiếp theo, bạn sẽ không phải đoán, và khách hàng hiện tại cũng có sẵn một bản tổng kết đáng tin.

Một CV FDE tốt không phải là văn bản bạn viết riêng cho việc đi xin việc. Nó là bản ghi trung thực những gì đã thay đổi ở chỗ người dùng nhờ bạn có mặt.

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

- Chọn ba bullet trong CV hiện tại đang mở đầu bằng tên công nghệ và viết lại theo thứ tự: kết quả, con số trước/sau, quy mô, công nghệ.
- Với mỗi dự án, ghi một dòng: ai là người dùng, bạn đã nói chuyện với họ chưa, hệ thống đang ở mức prototype hay production. Sửa CV cho khớp.
- Mở một tin tuyển FDE, đánh dấu cụm từ về sở hữu end-to-end và làm việc với khách hàng, rồi kiểm tra CV có bullet nào chứng minh từng cụm đó không.

## Nguồn

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

- [Forward Deployed Engineer Resume: How to Write One That Gets Interviews](https://fde.academy/blog/forward-deployed-engineer-resume-how-to-write-one-that-gets-interviews)

- [Forward Deployed Engineer Resume Tips (with Template)](https://www.finalroundai.com/blog/forward-deployed-engineer-resume-tips-template)

- [Palantir Technologies - Forward Deployed Software Engineer](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0)