Does writing publicly about your projects help you get hired as an FDE? Yes, but not the way most people think

In March 2026 the recruitment firm Robert Half published a figure job seekers should think about: 67% of HR leaders in the US say reviewing AI-generated CVs has slowed down hiring. Employers get more applications, but choosing someone takes longer.

In a Hacker News thread asking what new hiring signals matter now that AI writes CVs, one commenter suggested, half in jest, that an overly polished CV is probably AI’s work. By that logic, a small mistake becomes a sign of a real person.

When a polished CV costs almost no effort, polish loses its value. Robert Half draws the conclusion: employers increasingly need trusted people who can verify a candidate’s skills.

If you are aiming for an FDE role, this is your problem. The Pragmatic Engineer noted a wave of FDE hiring from around early 2025, and as of May 2026 still described demand as high and growing, with Google, OpenAI and Anthropic all hiring heavily.

So does writing publicly about your projects help you stand out from that crowd of applications? Yes, but rarely by getting recruiters to find you. A write-up about taking a project into production is most valuable at two moments: while you are still learning, and once someone already wants to check your work.

What do FDE recruiters want to verify?

Gergely Orosz, author of The Pragmatic Engineer, notes that almost every FDE employer looks for people with solid software engineering foundations. That is the baseline, and a clean GitHub repo can prove it.

Some companies ask for more. Commure and Matta, two names Orosz mentions, value hands-on experience building and shipping a project end to end. The “shipping” part is where code alone cannot tell the whole story.

FDE Academy, a guide to the FDE profession, advises candidates to describe a project that has been developed and deployed, rather than just showing code. Blockchain Council goes further: instead of many small demos, build a single, complete public product with a production mindset.

According to that source, such a project should have a real cloud deployment with API endpoints, basic authentication and operational logs. The accompanying README should include a user story, an architecture diagram, instructions for running it and known limitations.

The last item deserves attention. A demo never shows its known limitations, but listing them tells readers you understand where your system can break.

Two candidates, one project

Picture two candidates who have each built an agent that reads customer support tickets and writes the results into a CRM. Candidate A has a clean repo, a README with setup instructions and a demo. Candidate B has the same repo, plus a long write-up.

B’s write-up explains why a queue was needed when the CRM’s API rate-limited requests, how B mapped messy fields that users had typed in by hand for years, and how B explained things to support staff whenever the agent wrote something wrong.

A proves solid software engineering foundations. B also proves they have taken a project all the way from building to shipping, which is exactly what companies like Commure and Matta look for.

The difference is clearest in the interview room. B’s interviewer has material ready to dig into: “What would you do if the customer wouldn’t let you set up a queue?” Every solid answer is evidence that AI would struggle to write for you.

A’s interviewer has to start from scratch, at precisely the moment they have every reason to be suspicious of a CV that looks too polished.

Nobody reads your blog, except when it matters

Don’t expect much from the link on your CV. In the same Hacker News thread, one person said recruiters rarely read CVs, another believed referrals were what really counted, and was promptly told that at the replier’s company even referrals no longer got priority.

These are personal accounts, not data, but they are enough to show there is no shortcut. So don’t treat a write-up as a way to get recruiters to find you.

Shawn Wang (swyx) shows the other side. He says his entire body of public writing came up and, in his words, more or less got him his job at AWS. Note the verb: the writing “came up”, meaning it was found once someone was looking, not that it went out knocking on doors.

Swyx also points to a benefit that arrives before anyone hires you. For him, writing in public is a structured way to learn, and readers will point out where you are wrong. Having a stranger catch a flaw in your queue design on a blog is far more comfortable than having it caught in an interview.

What does each signal prove?

The table below compares four kinds of signal FDE candidates typically have. The columns are an editorial assessment drawn from the advice and accounts above, not measured data.

Signal	Hard to fake with AI? (assessment)	What it proves	When it gets read
CV bullet points	Very easy to fake	Almost nothing without verification; too much polish even invites suspicion	At screening, if it is read
GitHub repo with code only	Moderate	Software engineering foundations	When the recruiter bothers to click
Deployment write-up with a real deployment	Hard, because it must survive probing questions	An end-to-end project: user story, architecture, limitations, operations	When the interviewer looks into you or a referrer passes it on
Referral	Hard	Nothing directly, only someone else’s endorsement	Before screening, if referrals still get priority

No signal is enough on its own. A referral arrives earliest but proves no competence, and according to some accounts it is no longer a sure thing.

A deployment write-up proves the most but is usually read last. The referrer opens the door; the write-up gives the interviewer something to verify. Combining the two is the most sensible strategy.

How to write a piece that survives “so what?”

Don’t juggle five projects; pick one. Blockchain Council’s advice to build a single, complete product has a reason: a deep write-up about one real system gives an interviewer more to dig into than five demos.

Structure the piece around the same sections that source lists for a README. Open with the user story. For the ticket agent above, that might be: support staff waste time copying results into the CRM by hand, and the legacy data is a mess.

The middle, and longest, part covers the architecture and the integration decisions. Draw a simple diagram: tickets come in, pass through the agent, enter a queue, then reach the CRM. Then honestly describe one thing you got wrong, such as calling the API directly the first time and getting blocked by the rate limit.

The final part covers known limitations: which kinds of ticket the agent will get wrong, and how you tell support staff when that happens. Link to the real deployment with its API, authentication and logs, so readers can check for themselves instead of taking your word for it.

A test before publishing: reread each paragraph and ask “so what?”. Any paragraph that cannot answer, or that just lists the technologies used, should be rewritten around a specific decision and the reason behind it.

If your CV has no line yet about deploying for real customers, the write-up is where you prove you have taken a system from idea to stable operation on your own.

Each project on your CV should have a one-line description in deployment language, such as “shipped an agent against a rate-limited CRM, handling hand-entered data”, with a link to the write-up.

When reading job descriptions, watch for phrases like “end-to-end”, “customer-facing” or “integration”. Those are the places where your write-up can serve as evidence. Then ask someone you know in the industry to read it and give feedback before you ask them for a referral.

When anyone can have a polished CV, the hardest thing to fake is the trace of a system that actually ran, and a story that stands up to the question “so what?”.