Why people exaggerate on resumes, and the case for verifiable work
Why resume exaggeration happens, why it usually gets caught, and why evidence a reviewer can check directly is a stronger position than any claim, true or not.
À propos de cette page
L’interface du site s’affiche dans votre langue. Le texte long de cette page a été rédigé en anglais et n’a pas encore été traduit.
Resume exaggeration is common enough that hiring processes are largely built around the assumption that some claims will not hold up: reference checks, technical interviews, take-home assignments, and background checks all exist partly because a resume, on its own, is an unverified document. Someone wrote it about themselves, with an obvious incentive to present the best possible version of events.
Most of it is not outright fabrication. It is closer to rounding up: a “contributed to” becomes a “led,” a project with three people becomes one where your specific role gets left ambiguous, a skill you used once on a tutorial becomes a bullet point that implies fluency. The pressure is understandable. A resume is a competition for attention, and vague, undersold claims lose to confident, specific ones, even when the confident version is stretched further than it should be.
Why it tends to get caught
A resume claim about a skill or a project is easy to write and easy to test. A technical interview can ask a follow-up question that a genuinely hands-on contributor answers fluently and a rounded-up one struggles with. A reference call can clarify what someone’s actual role was on a team project. The gap between the claim and the reality tends to surface exactly when it matters most, in the room, in front of the person deciding whether to hire you.
This is also why exaggeration is a bad trade even when it works in the short term. Getting an interview on a claim you cannot fully back up mostly wastes everyone’s time, including yours, once the gap becomes visible.
The alternative: evidence that does not need to be taken on trust
For developers specifically, there is a category of resume content that sidesteps the trust problem entirely, because it is not a claim at all: a public GitHub profile. A repository either exists or it does not. Commit history either shows a language and a level of activity, or it does not. A reviewer does not have to trust your description of a project; they can open it and read the code directly.
This does not mean every GitHub profile is automatically convincing, activity is not the same as ability, and a lot of real work happens in private repositories that never show up publicly. But for the parts of your history that are public, the credibility comes from the fact that they are checkable at all, not from how confidently they are worded.
Building a resume from what can actually be checked
The practical version of this idea is straightforward: where you have real, public, verifiable work, lead with it, and let a reviewer confirm it themselves rather than asking them to take your word for it. resumefromgit.com builds exactly that kind of resume, reading a public GitHub username and generating a visual CV and an ATS-safe PDF resume directly from the repositories, languages, and contribution history already on the account, so the Projects section is not a set of claims but a set of links a reviewer can actually open.