Viết công khai về dự án có giúp bạn được tuyển làm FDE? Có, nhưng không theo cách nhiều người nghĩ

Tháng 3/2026, hãng tuyển dụng Robert Half công bố một con số đáng để người đi xin việc suy nghĩ: 67% lãnh đạo nhân sự ở Mỹ nói việc đọc những hồ sơ do AI tạo ra đã làm chậm cả quy trình tuyển dụng. Hồ sơ nhiều hơn, nhưng chọn được người lại lâu hơn.

Trên Hacker News, trong một chủ đề hỏi về tín hiệu tuyển dụng mới khi CV đã do AI viết, có người nói nửa đùa nửa thật rằng hồ sơ nào quá bóng bẩy thì nhiều khả năng là của AI. Theo logic ấy, một lỗi nhỏ lại thành dấu hiệu của người thật.

Khi viết một hồ sơ đẹp gần như không tốn công, hồ sơ đẹp cũng mất giá. Robert Half rút ra hệ quả: nhà tuyển dụng ngày càng cần những người đáng tin, đủ khả năng kiểm chứng kỹ năng của ứng viên.

Nếu bạn đang nhắm tới vai trò FDE, đây là bài toán của chính bạn. The Pragmatic Engineer ghi nhận làn sóng tuyển FDE từ khoảng đầu năm 2025, và đến tháng 5/2026 vẫn nhận định nhu cầu cao và đang tăng, với Google, OpenAI và Anthropic cùng tuyển mạnh.

Vậy viết công khai về dự án của mình có giúp bạn nổi lên giữa đám đông hồ sơ đó không? Có, nhưng hiếm khi bằng cách khiến người tuyển tự tìm tới bạn. Một bài viết kể lại quá trình đưa dự án vào chạy thật có giá trị nhất ở hai thời điểm: khi bạn còn đang học, và khi đã có người muốn kiểm chứng bạn.

Người tuyển FDE muốn kiểm chứng điều gì?

Gergely Orosz, tác giả The Pragmatic Engineer, ghi nhận hầu như nhà tuyển dụng FDE nào cũng tìm người có nền tảng kỹ sư phần mềm vững. Đó là điều kiện cần, và một repo GitHub sạch sẽ có thể chứng minh phần này.

Nhưng một số công ty đòi hơn thế. Commure và Matta, hai cái tên Orosz nhắc tới, coi trọng kinh nghiệm thực tế xây và giao một dự án từ đầu đến cuối. Phần “giao” chính là chỗ code một mình không kể hết được.

FDE Academy, một trang hướng dẫn về nghề FDE, khuyên ứng viên mô tả một dự án đã được phát triển và đã triển khai, chứ không chỉ đưa ra code. Blockchain Council còn đi xa hơn: thay vì nhiều bản demo nhỏ, hãy làm một sản phẩm công khai duy nhất, đầy đủ, xây với tinh thần production.

Theo nguồn này, dự án như vậy nên có bản deploy thật trên cloud, với các API endpoint, xác thực cơ bản và log vận hành. README đi kèm cần có user story, sơ đồ kiến trúc, hướng dẫn chạy và các giới hạn đã biết.

Chi tiết đáng chú ý là mục cuối cùng: giới hạn đã biết. Bản demo không bao giờ khoe điều đó, nhưng chính nó cho người đọc thấy bạn hiểu hệ thống của mình có thể hỏng ở đâu.

Hai ứng viên, cùng một dự án

Thử hình dung hai ứng viên cùng xây một agent đọc ticket hỗ trợ khách hàng rồi ghi kết quả vào CRM. Ứng viên A có repo sạch sẽ, README hướng dẫn cài đặt và một bản demo. Ứng viên B có đúng repo ấy, cộng thêm một bài viết dài.

Bài của B kể lý do phải dựng hàng đợi khi API của CRM giới hạn số request, cách B ánh xạ các trường dữ liệu bẩn do người dùng nhập tay suốt nhiều năm, và cách B giải thích cho nhân viên hỗ trợ mỗi khi agent ghi sai.

A chứng minh được nền tảng kỹ sư phần mềm. B chứng minh thêm rằng mình đã đưa một dự án đi trọn từ lúc xây tới lúc giao, đúng thứ mà những công ty như Commure hay Matta tìm kiếm.

Khác biệt lộ rõ nhất trong phòng phỏng vấn. Người phỏng vấn B có sẵn chất liệu để đào: “Nếu khách hàng không cho dựng hàng đợi thì bạn làm gì?”. Mỗi câu trả lời vững là một bằng chứng mà AI khó viết hộ.

Người phỏng vấn A phải bắt đầu từ con số không, đúng vào lúc họ đã có đủ lý do để nghi ngờ một hồ sơ quá trơn tru.

Không ai đọc blog của bạn, trừ đúng lúc quan trọng

Đừng kỳ vọng quá nhiều vào đường link trong CV. Cũng trong chủ đề Hacker News kia, có người nói giới tuyển dụng ít khi đọc CV, có người tin referral mới là thứ quyết định, và lập tức bị phản bác rằng ở công ty người đó, ngay cả referral cũng không còn được ưu tiên.

Đó là lời kể cá nhân, không phải số liệu, nhưng đủ để thấy không có đường tắt. Vì thế đừng coi bài viết là công cụ để người tuyển tự tìm ra bạn.

Shawn Wang (swyx) cho thấy mặt còn lại. Anh kể rằng toàn bộ bài viết công khai của mình đã hiện ra, và theo lời anh, gần như chính chúng mang về cho anh công việc ở AWS. Động từ đáng để ý: bài viết “hiện ra”, tức được tìm thấy khi đã có người tìm, chứ không tự đi gõ cửa.

Swyx còn chỉ ra một lợi ích đến trước cả khi có ai tuyển bạn. Với anh, viết công khai là một cách học có tổ chức, và người đọc sẽ chỉ ra chỗ bạn sai. Bị một người lạ bắt lỗi thiết kế hàng đợi trên blog dễ chịu hơn nhiều so với bị bắt lỗi trong phòng phỏng vấn.

Mỗi tín hiệu chứng minh được điều gì?

Bảng dưới đây so sánh bốn loại tín hiệu mà ứng viên FDE thường có. Các cột là đánh giá biên tập rút ra từ những lời khuyên và lời kể ở trên, không phải số liệu đo được.

Tín hiệu	Khó làm giả bằng AI? (đánh giá)	Chứng minh được gì	Khi nào được đọc
Gạch đầu dòng trong CV	Rất dễ làm giả	Gần như không gì nếu thiếu kiểm chứng; quá bóng bẩy còn bị nghi	Lúc sàng lọc, nếu được đọc
Repo GitHub chỉ có code	Trung bình	Nền tảng kỹ sư phần mềm	Khi người tuyển chịu bấm vào
Bài viết về triển khai, kèm bản deploy thật	Khó, vì phải chịu được câu hỏi đào sâu	Dự án từ đầu đến cuối: user story, kiến trúc, giới hạn, vận hành	Khi người phỏng vấn tìm hiểu hoặc người giới thiệu chuyển tiếp
Lời giới thiệu (referral)	Khó	Không trực tiếp, chỉ là sự bảo chứng của người khác	Trước cả vòng sàng lọc, nếu còn được ưu tiên

Không tín hiệu nào đủ một mình. Referral đến sớm nhất nhưng không chứng minh năng lực, và theo vài lời kể thì cũng không còn chắc ăn.

Bài viết về triển khai chứng minh nhiều nhất nhưng thường được đọc muộn nhất. Người giới thiệu mở cửa, bài viết cho người phỏng vấn thứ để kiểm chứng. Ghép hai thứ lại là chiến lược hợp lý nhất.

Viết thế nào để bài chịu được câu hỏi “rồi sao nữa?”

Đừng ôm năm dự án; hãy chọn một. Lời khuyên của Blockchain Council về một sản phẩm duy nhất, đầy đủ, có lý do: một bài viết sâu về một hệ thống thật cho người phỏng vấn nhiều chỗ để đào hơn năm bản demo.

Hãy dựng bài theo đúng các mục mà nguồn này liệt kê cho README. Phần mở đầu là user story. Với agent xử lý ticket ở trên, đó có thể là: nhân viên hỗ trợ mất thời gian chép tay kết quả vào CRM, và dữ liệu cũ thì lộn xộn.

Phần giữa, dài nhất, dành cho kiến trúc và các quyết định tích hợp. Vẽ một sơ đồ đơn giản: ticket đi vào, qua agent, vào hàng đợi, rồi tới CRM. Sau đó kể thật một chỗ bạn từng làm sai, chẳng hạn lần đầu gọi thẳng API và bị giới hạn request chặn lại.

Phần cuối nói về các giới hạn đã biết: agent sẽ ghi sai ở loại ticket nào, và bạn báo cho nhân viên hỗ trợ ra sao khi chuyện đó xảy ra. Kèm link tới bản deploy thật có API, xác thực và log, để người đọc tự kiểm chứng thay vì phải tin lời bạn.

Một mẹo kiểm tra trước khi đăng: đọc lại từng đoạn và tự hỏi “rồi sao nữa?”. Đoạn nào không trả lời được câu đó, hoặc chỉ liệt kê công nghệ đã dùng, thì nên viết lại bằng một quyết định cụ thể và lý do đằng sau nó.

Nếu CV chưa có dòng nào về triển khai cho khách hàng thật, bài viết là nơi bạn chứng minh mình từng tự đưa một hệ thống từ ý tưởng tới lúc chạy ổn định.

Mỗi dự án trong CV nên có một dòng mô tả bằng ngôn ngữ triển khai, kiểu “đưa agent vào chạy với CRM có giới hạn request, xử lý dữ liệu nhập tay”, kèm link tới bài.

Khi đọc mô tả công việc, hãy để ý những cụm như “end-to-end”, “customer-facing” hay “integration”. Đó là những chỗ bài viết của bạn có thể làm bằng chứng. Rồi đưa bài cho một người quen trong ngành đọc và góp ý trước khi nhờ họ giới thiệu.

Khi ai cũng có thể có một bộ hồ sơ trơn tru, thứ khó làm giả nhất là dấu vết của một hệ thống đã thật sự chạy, cùng một câu chuyện đứng vững trước câu hỏi “rồi sao nữa?”.