When Nobody Reviewed Your Code
Some engineers have spent years writing software that no other engineer ever read. The sole developer at a small company. The agency contractor whose pull requests were approved by whoever was free. The person who built the internal system nobody else understood, on a team where review was a formality.
This is a real resume problem, and it is not the one people think it is. The worry is not that you are a weak engineer — plenty of unsupervised engineers are excellent. The worry is calibration: whether your standards have ever been tested by someone who could push back.
What the reviewer is actually afraid of
Put yourself on the other side of the page. A technical reviewer looking at five years of solo work is asking three unglamorous questions:
- Will this person’s code look like ours, or like a private dialect?
- Can they take review feedback without treating it as an attack?
- Have they ever had to justify a decision to someone who disagreed and had authority?
None of these are answered by more evidence of shipping. You can ship for a decade alone and none of it addresses them. That is why the standard advice — “show your accomplishments” — does not fix this particular resume.
It also explains a common, painful experience: strong solo engineers getting rejected in favour of candidates with visibly less impressive work. The other candidate’s page answered a question yours did not.
Signal one: someone outside your company accepted your work
The cheapest fix is external review, and open source is the standard route: a merged pull request to a project you do not own, where a maintainer who owed you nothing read your code and said yes.
Size matters much less than provenance here. A small, accepted contribution to a project with a real review culture is worth more as a calibration signal than a large repository you wrote alone, because the second one proves output and the first one proves you can work inside someone else’s standards. That difference is the specific thing this resume is missing.
Illustrative, in a projects or open-source line: Contributor to the Terraform provider we depended on — three merged pull requests, including a fix to the retry behaviour on partial API failures that took two review rounds to get right.
“Took two review rounds to get right” is not an admission. It is the entire point of the sentence, and an experienced reviewer will read it as such. What a link to your code actually proves covers what a reader takes from following that link.
Other things that carry the same signal: a bug report accepted upstream with a reproduction, a documentation fix that required understanding the code, an answer you wrote that a maintainer endorsed, a library of yours that other people file issues against — issues from strangers are evidence that a stranger read it.
Signal two: a process you imposed on yourself, described concretely
If nobody made you do it, doing it anyway is the signal. But it only lands if it is specific, because “followed best practices” is exactly what someone with no process would also write.
Concrete forms, all worth a clause each:
- CI you set up when there was no requirement to, and what it gates on — tests, linting, a build of the container, a migration check.
- A written decision record for a choice you made alone, and a case where writing it changed your mind. This is the strongest version, and it is the subject of design documents, RFCs, and what they show.
- A style and structure convention you defined and then held to across a codebase, especially if you can name the rule and why.
- Test discipline you can characterise honestly: which layer you test, what you deliberately do not test, and why.
- Post-change verification: how you knew a deploy was fine, given that no colleague was watching.
Weak: Followed industry best practices and maintained high code quality as the sole engineer.
Stronger, illustrative: As the only engineer on the product, ran the codebase as if reviewed — CI gating tests, types, and migrations on every branch; a short decision record for anything structural, including the one that talked me out of splitting the service; and a staged deploy with a documented rollback because there was nobody to call at 2am.
The second version answers the calibration question without ever mentioning it.
Signal three: production reviewed your code instead
There is one reviewer that unsupervised engineers always had, and it is unforgiving. If you were on call for your own software, you got feedback that a colleague could not have given you.
Write it that way. An engineer who has been paged by their own design decision, diagnosed it, and changed the design has been through a review process — just an expensive one. Naming the specific lesson makes this credible rather than rhetorical: the retry that caused a thundering herd, the migration that locked a table under real traffic, the background job with no idempotency that ran twice.
This is also where solo experience is genuinely superior to some team experience, and it is fair to say so plainly. You cannot hide behind a process that absorbed your mistakes.
Say the circumstance, do not hide it
A one-line context statement above the bullets prevents the reader inventing a worse story than the truth: Sole engineer; product had roughly two thousand active users and no other technical staff. The mechanics of that line are in the context line above your bullets.
Two things not to do.
Do not claim a process that did not exist. “Participated in code reviews” when there were no reviews is checkable in about one question, and it converts a fixable gap into a credibility problem.
Do not present the absence as a virtue. “Moved fast without bureaucratic review overhead” tells a reviewer exactly what they were afraid of. The honest framing — broad ownership, less external calibration, and here is how I compensated — is more persuasive, and it is the same breadth-versus-depth trade-off described in moving from a big company to a startup.
The one edit worth making
If you have nothing in signal one, that is the gap worth closing before you apply anywhere, and it is closeable in a few evenings: one real merged contribution to something you already use.
If you cannot do that in time, lead with signal two and make it specific enough that a reviewer can tell your standards came from somewhere. Vague quality language is what an uncalibrated engineer sounds like, whether or not you are one — and the fix is the same either way, which is to describe the mechanism instead of the intent. That is also the argument in scope, not years: the page should show the shape of what you did, not assert a level.