Content mistakes: responsibility lists, buzzwords and overclaiming

This section is the failure catalogue. Its six mistakes fall into two groups: mistakes in what the lines say, and mistakes in what the page shows — its dates, its layout, and the personal details it gives away.

This lesson covers the first group. All three mistakes here come from the same place: writing something that feels safe or impressive instead of something a reader can check. A responsibility cannot be challenged, an adjective cannot be disproved, and an overstated skill looks good until someone asks about it.

Responsibility lists instead of outcomes

The single most common defect in engineering resumes, and the one with the largest cost.

What it looks like

Software Engineer, Northwind Retail — Jan 2022 – Present

• Responsible for developing and maintaining backend microservices.

• Worked closely with product managers to gather requirements.

• Participated in code reviews and contributed to technical documentation.

• Ensured high code quality through unit and integration testing.

Every line is true. Every line is also true of every other engineer who has held that job.

This is a job description written in the past tense. It describes the role, not the person in it. A reader finishes it knowing what the position involved and nothing about whether you were good at it.

Why it happens

Usually not laziness. Three real causes:

1. It is what a job description looks like, and that is the nearest model most people have for "professional writing about work".
2. Outcomes take work to recover. You have to remember what changed and find the number.
3. It feels safer. A responsibility cannot be challenged; an outcome invites "how did you measure that?"

That third one is worth confronting: the challenge is the point. A claim that can be probed is a claim that carries weight.

The fix

Apply the impact-first structure to each line. Here is the same role rewritten:

Software Engineer, Northwind Retail — Jan 2022 – Present

Own the order and inventory services: 800k orders/month, team of 5.

• Cut order-confirmation latency from 4.2 s to 600 ms by moving fulfilment notification off the request path onto a queue.

• Removed a double-reservation bug that had been silently over-selling ~200 items a month, by making inventory holds idempotent.

• Reduced on-call pages for the inventory service from ~12 to 2 per month by adding retry-with-backoff and fixing three sources of unbounded queue growth.

Same job. Same person. The reader now has an opinion.

Buzzwords and rating bars

The next mistake is decoration: two additions that feel like they strengthen a resume and consistently weaken it.

Self-describing adjectives

Passionate, results-driven software engineer with excellent communication skills and a proven track record of delivering innovative solutions in fast-paced environments.

Problems with this sentence:

• Unverifiable. There is no evidence you could offer for "passionate".
• Universal. No candidate describes themselves as unmotivated with poor communication.
• Space-consuming. That is three lines of prime real estate saying nothing.
• Actively negative to engineers, who read it as padding.

The list to delete: passionate, results-driven, self-motivated, detail-oriented, team player, hard-working, dynamic, synergistic, thought leader, rockstar, ninja, guru.

Skill rating bars

Templates love these: a technology name beside four filled dots out of five, or a progress bar.

They fail in three separate ways.

They are meaningless. Your 4/5 in Python and mine are not comparable. There is no scale. Nobody knows what the fifth dot would represent.

They invite the wrong question. A reader looking at "Python ●●●●○" wonders what is missing. You have introduced a doubt that a plain list would not have.

They are invisible to parsers. A bar is a graphic. An applicant tracking system extracts nothing from it — so a bar-based skills section can leave you unfindable in exactly the searches you wanted to match. That is the most expensive failure of the three.

Replace them with a plain grouped list (see A skills section that survives scrutiny).

Other decorations worth removing

The underlying principle: a resume is a document to be read fast and parsed reliably, not a design portfolio. Visual design should serve hierarchy, and stop there.

Overclaiming, and what it costs

Buzzwords say too little. The opposite mistake says too much. Everything on your resume is a question you have agreed to answer. Writing something you cannot defend is not a small exaggeration; it is a trap you set for yourself.

How it plays out

You list Kubernetes because you once deployed to a cluster someone else set up.

An interviewer sees it, assumes it is a strength, and opens with: "I see you've worked with Kubernetes — walk me through how you'd debug a pod stuck in CrashLoopBackOff."

Three things now go wrong at once:

1. You cannot answer well. That is a bad ten minutes.
2. A question you might have shone on was displaced. The interviewer chose this because your resume said it was safe ground.
3. Everything else on the resume is now suspect. If Kubernetes was overstated, what about Kafka? This is the expensive part.

That third cost is the one people underestimate. A single unsupportable claim converts your resume from evidence into a set of claims requiring verification.

The calibration test

For every technology, project, and number on your resume:

Could I talk about this for ten minutes, including something that went wrong?

The "something that went wrong" clause is the useful half. Anyone can recite what a tool does. Only someone who has genuinely used it can describe how it failed on them.

If you cannot do that, you have three honest options:

1. Remove it.
2. Downgrade it. Move it from a bullet into a plainer mention, or from "built" to "worked with".
3. Learn it properly, if it matters for the roles you want.

Honest ways to represent partial experience

You do not have to pretend inexperience does not exist. There is accurate language for every level:

An engineer who accurately writes integrated with Kafka; did not operate the cluster is more credible than one who writes Kafka expert and falls over on the first question.