Hai câu mô tả dự án cho hồ sơ FDE: production, không phải demo

Form ứng tuyển có một ô nhỏ ghi “Mô tả dự án tiêu biểu”. Bạn gõ: “Built an app using Python and React”, thấy hơi mỏng, thêm vài cái tên công nghệ rồi bấm gửi. Với vị trí Forward Deployed Engineer, câu đó gần như không nói gì về những điều người tuyển đang tìm.

Dự án của bạn có thể rất tốt, nhưng câu văn thì không cho thấy điều đó. FDE Academy, trong hướng dẫn viết CV cho FDE, cho rằng người duyệt hồ sơ tìm dấu hiệu bạn từng chịu trách nhiệm triển khai và tư duy theo kết quả kinh doanh, chứ không chỉ độ rộng kỹ thuật.

Câu mẫu “mạnh” của họ bắt đầu bằng việc đưa một model phân loại vào luồng production của khách hàng.

Với FDE, cái giá của sự mơ hồ còn cao hơn. Hướng dẫn tuyển FDE đầu tiên của Paraform khuyên nhà tuyển dụng hỏi thẳng ứng viên về code từng deploy lên hạ tầng của khách. Hai câu của bạn phải trả lời trước câu hỏi đó.

Kỹ năng này dùng được ở nhiều chỗ: trong CV, trong ô mô tả ở form ứng tuyển, trong tin nhắn gửi recruiter, và ở câu đầu tiên khi người phỏng vấn bảo “kể cho tôi về một dự án”.

Một dự án, ba cách viết

Thử hình dung một dự án giả định, kể cả các con số. Bạn làm ở một công ty logistics, đội kho đang dùng một hệ thống ERP cũ do vendor khác viết, không có tài liệu API.

Bạn viết một service đọc dữ liệu tồn kho từ bản replica của database, thêm API và dashboard, rồi deploy lên server on-prem của công ty sau khi đội IT duyệt bảo mật.

Phiên bản 0, kiểu nhiều người vẫn viết: “Built an inventory app using Python and React.” Câu này có công cụ, nhưng không có người dùng, không có ràng buộc, không có kết quả.

Phiên bản 1 áp công thức mà Careerflow đề xuất: Hành động + Nhiệm vụ + Công cụ/Phương pháp + Số liệu + Kết quả/Phạm vi. Câu mới: “Xây dashboard tồn kho bằng Python và React, rút thời gian lập báo cáo từ 2 ngày xuống 15 phút.”

Câu đó đã đủ tốt cho một vị trí SWE. Với FDE, nó vẫn thiếu đúng thứ người đọc cần biết: hệ thống của ai, khó ở chỗ nào, ai đang dùng.

Phiên bản 2, viết cho FDE:

“Xây service và dashboard tồn kho đọc thẳng từ ERP cũ của vendor (không có tài liệu API, chỉ có replica database), rồi deploy lên server on-prem sau khi qua review bảo mật của đội IT. 40 quản lý ở 6 kho dùng hằng ngày; thời gian lập báo cáo tồn kho giảm từ 2 ngày xuống 15 phút.”

Bản tiếng Anh cho CV: “Built an inventory service and dashboard on top of a vendor’s undocumented legacy ERP via a read replica; deployed on-prem after passing IT security review. Used daily by 40 managers across 6 warehouses; cut reporting time from 2 days to 15 minutes.”

Mỗi cụm trong phiên bản 2 trả lời một dòng trong JD

“ERP cũ của vendor, không có tài liệu” khớp với yêu cầu mà mẫu JD FDE của Valletta Software nêu: ứng viên từng làm ra thứ hữu ích bên trong một hệ thống mình không thiết kế và không thể nhìn thấy hết.

“Deploy on-prem, qua review bảo mật” khớp với cách JD đó mô tả công việc: triển khai vào hạ tầng của khách và vượt qua các yêu cầu bảo mật của họ, chứ không phải chạy trong một sandbox do mình kiểm soát.

“Service, API, dashboard, deploy” cho thấy bạn đã đi qua nhiều tầng. Hướng dẫn phỏng vấn Palantir FDE của Aced mô tả vai trò này là đảm nhận trọn vẹn sản phẩm từ đầu đến cuối, từ đặt bài toán, làm dữ liệu cho tới front-end.

“40 quản lý ở 6 kho dùng hằng ngày” làm hai việc. Nó lấp ô Phạm vi trong công thức của Careerflow. Nó cũng chứng minh dự án đang chạy production, đúng điều mẫu JD của Valletta nói thẳng: bạn chịu trách nhiệm production, không phải bản demo.

“2 ngày xuống 15 phút” giữ nguyên từ phiên bản 1. Đây là dạng tác động dễ đọc nhất: Career Services của UT Austin lấy ví dụ một câu kể việc rút thời gian xây pipeline từ hàng tuần xuống vài ngày cho hơn 10 nhóm, vừa có thời gian tiết kiệm, vừa có quy mô.

Năm bước để tự viết lại dự án của bạn

Bước một: viết ra người dùng thật. Không phải “người dùng” chung chung, mà là một vai trò cụ thể như quản lý kho, đội vận hành, nhân viên chăm sóc khách hàng. Nếu dự án không có ai dùng ngoài bạn, hãy ghi rõ là dự án cá nhân và chọn dự án khác làm câu chuyện chính.

Bước hai: gọi tên phần hệ thống không phải của bạn. Đó có thể là API của bên thứ ba, database kế thừa, quy trình duyệt của đội khác. Nhiều kỹ sư giấu chi tiết này vì sợ dự án trông “bẩn”, trong khi với FDE đây lại là phần đáng giá nhất.

Bước ba: nêu một ràng buộc triển khai có thật. Môi trường on-prem, cloud của khách, review bảo mật, quyền truy cập dữ liệu bị giới hạn: chỉ cần một chi tiết như vậy là đủ thay cho cả dòng liệt kê công nghệ.

Bước bốn: chọn hai con số, một về phạm vi và một về tác động. FDE Academy cho rằng ngay cả một ước lượng trung thực về hướng thay đổi vẫn tốt hơn không có số.

Nếu không có số đo chính xác, hãy ước lượng thận trọng hoặc viết điều kiểm chứng được, như “thay thế quy trình nhập tay hằng tuần”, thay vì bịa ra một tỉ lệ phần trăm.

Bước năm: cắt còn hai câu, rồi đọc lại bằng con mắt của người phỏng vấn. Với từng cụm, tự hỏi: nếu bị hỏi tiếp, bạn có kể được trong năm phút không? Cụm nào không kể tiếp được thì bỏ.

Phép thử này bám sát cách vòng phỏng vấn diễn ra. Theo hướng dẫn của Aced, Palantir tìm người biến nhu cầu mơ hồ của khách thành phần mềm có phạm vi rõ và triển khai được, và chấm cả cách bạn mở rộng hay sửa code khi đặc tả chưa đầy đủ.

Paraform nói thẳng hơn: ứng viên cần bản đặc tả chi tiết rồi mới bắt tay sẽ chật vật ở vai trò này.

Vì thế, cụm “ERP không có tài liệu” phải dẫn được đến câu chuyện bạn đã dò cấu trúc database thế nào và xin quyền truy cập từ ai.

Những lỗi khiến hai câu không nói được gì

Lỗi phổ biến nhất là viết danh sách công nghệ thay cho câu chuyện. “Python, React, Docker, Kubernetes” ai cũng ghi được. Người tuyển FDE cần biết bạn dùng chúng để giải quyết chuyện gì, cho ai.

Lỗi thứ hai là đem demo hoặc dự án hackathon ra kể như sản phẩm production. Chỉ một câu hỏi “ai đang dùng nó bây giờ?” là sự thật lộ ra. Demo cứ ghi là demo, còn câu chuyện chính nên là dự án đã lên production.

Lỗi thứ ba là động từ mơ hồ như “tham gia”, “hỗ trợ”, “cải thiện hiệu năng”. Nếu bạn làm một phần của dự án lớn, hãy gọi đúng tên phần đó: “tự viết lớp ingestion” rõ hơn nhiều so với “tham gia xây pipeline”.

Lỗi thứ tư là chỉ kể phần backend. Nếu bạn đã chạm vào cả data, giao diện hay deployment, hãy để câu văn cho thấy điều đó, dù chỉ bằng một cụm từ.

Lỗi cuối cùng là viết dài. Hai câu nghĩa là hai câu. Muốn nhồi thêm chi tiết thường là dấu hiệu bạn chưa chọn ra được ràng buộc quan trọng nhất.

Cùng một dự án, mở đầu theo từng JD

JD nhấn mạnh việc deploy vào môi trường của khách thì đưa on-prem và review bảo mật lên trước; JD nói nhiều về data thì mở bằng chi tiết replica database. Đó không phải tô vẽ, mà chính là việc FDE làm hằng ngày: nghe kỹ người trước mặt cần gì, rồi kể đúng phần việc thật của mình bằng ngôn ngữ của họ.

Sau mọi tín hiệu, người đọc CV vẫn đang hỏi một câu: đưa người này vào hệ thống của khách, họ có làm ra thứ chạy được hay không. Hai câu của bạn là lần đầu tiên bạn được trả lời câu hỏi ấy.