Skip to content
The Forge Log

Issue 006

How to write a junior developer CV that names a shipped project.

What to put above the fold when you finally have something real to put there.

3 min read

A printed CV on a wooden desk with a fountain pen resting across it.

Most junior CVs are written to hide the absence of experience. Long skills lists, every framework touched once, three personal projects with screenshots. The moment you have shipped a real project for a real company, that CV is working against you, because it buries the one line an interviewer wants to read.

The line that matters

An interviewer reading a junior CV is scanning for one thing: evidence that you have worked under real conditions. A client name, a role on a team, software that is running somewhere. If that line exists, it goes at the top, under your name, before education, before skills, before anything.

How to write the project entry

Treat it like a job, because it was one. A heading with the company’s name (with their permission, which on a Blacksmith.Works project you earn when your part ships), the project name, and the dates. Then three to five lines, each starting with a verb and ending with a fact.

  • What the system does.“Built the booking module of an internal scheduling tool used by the company’s service team.” Not the framework list; the outcome.
  • What was yours. Name the module, the tickets, the sprint count. On a team project, precision about your slice is more credible than vagueness about the whole.
  • How it was reviewed.“Every pull request reviewed by a senior engineer; changes requested and resolved across N reviews.” Interviewers rarely see this line on a junior CV, which is exactly why it works.
  • How it was run. Jira board, sprints, weekly check-ins with a mentor, an agreed weekly schedule. This says you can work inside a process without being told twice.
  • Where the proof is. A link to your public Anvil Stamp page, which lists the project, your role and the date it completed, and which returns a 404 for anyone who did not ship.

What to cut

The skills cloud. Replace the forty-item list with the stack you actually shipped in, and say “used in production on the project above”. Two personal projects at most, and only if they show something the client project did not. The objective statement. Anything that says “passionate”.

What to keep honest

Do not inflate the slice. If you built one module of a five-module system, say one module; the mentor who reviewed you may be the reference the interviewer calls, and they will describe the same module. Do not name a client you were not cleared to name. On our projects the brand-reference right is earned by shipping your part; until then the entry says “a logistics company in North Macedonia” and that is fine.

Do not list a certificate that does not exist. There is no Blacksmith.Works certificate; there is a public record of what you shipped, and a URL. The URL is worth more.

The reference line

“References available on request” is a wasted line for most juniors, because the references are lecturers. Yours is different: a senior engineer with five or more years of production work who reviewed your code for weeks and can speak to how you handled a real deadline and real feedback. Say so, in one sentence, with the mentor’s permission: “Reference: my project mentor, a senior engineer, available on request.”

Before you have the project

If you are reading this without a shipped project yet, the CV advice is simple: get the project. It is the difference between a document that argues and a document that shows. The apprentice page explains how a Blacksmith.Works project works and what it costs; the Anvil Stamp post explains what you walk away with.