Stop bolding the tech stack. What to actually highlight on your CV

There is a debate that keeps resurfacing in job search threads. Someone asks what they should bold on their CV, and the answers split straight down the middle. Half say bold every technology so the recruiter can find their stack. The other half say bold nothing because it looks desperate.

Both camps are answering the wrong question. The real question is not whether to bold. It is what the first skim of your CV should land on, because on the first pass a recruiter gives you seconds, not minutes, and their eyes go to whatever you made heavier than the rest of the page.

Bolding is not decoration. It is you choosing, in advance, what a tired reader sees in those few seconds. Which makes it strange that most people spend that budget on the names of tools.

Why bolding the tech stack fails

I understand the instinct. The job asks for Python and Kubernetes, you have Python and Kubernetes, so you bold Python and Kubernetes and hope the match jumps out.

The problem is that the bolded tool name carries no new information. Your stack is already sitting in the skills section, and if an ATS or a recruiter is keyword matching, it gets found there whether you bold it or not. What the bold version adds is a claim of emphasis with nothing behind it. A bolded Kafka does not say senior. It says this person wants me to notice a word, and the word alone tells me nothing about whether they used the thing for a weekend tutorial or ran it in production for four years.

There is a second failure mode that is easier to see from the reading side. Bold ten tool names per role and the page turns into a ransom note. When everything is highlighted, the highlighting stops working, and the reader’s eye stops trusting your emphasis entirely. You spent your one skim-control mechanism and got nothing for it.

The number is the argument

Here is the reframe. A technology name proves contact. A metric proves depth. The gap between those two is exactly what a hiring manager is trying to establish in the first read, and it is the one thing the skim cannot infer on its own.

Compare the same experience written twice.

Weak emphasis: “Built streaming data pipelines using Kafka, Flink and Python.”

Better emphasis: “Built streaming pipelines in Kafka and Flink processing around 2 billion events a day, cutting reporting lag from hours to minutes.”

The second version still contains the stack, unbolded, in plain sight for anyone matching keywords. But the emphasis now lands on the part only you can claim. Thousands of applicants can write the word Kafka. Very few can write two billion events a day, and the reader knows it. Scale, money, time, and percentages are hard currency precisely because they are falsifiable. You would not dare bold a number you cannot defend in an interview, and hiring managers read bolded numbers with exactly that assumption.

This is the same logic as making bullet points specific rather than polished. Specificity is the quality a reader cannot fake-detect. Bolding is just the delivery mechanism that makes sure the specific part is what they hit first.

Rules that keep bolding honest

• Bold at most one phrase per bullet. The number, the outcome, or the scale. If a bullet has two things worth bolding, it is probably two bullets.
• Keep it scarce across the page. A handful of bolded fragments per page is emphasis. Twenty is wallpaper.
• Never bold verbs or soft skills. A bolded “led” or “cross-functional” is emphasis spent on the least verifiable words on the page.
• Do not bold job titles or company names. The document structure already makes those findable. Spend the bold on what structure cannot show.
• If a bullet contains nothing worth bolding, the bullet is the problem. No outcome, no scale, no change worth highlighting usually means the bullet is a duties list. Fix the evidence, not the formatting.

No exact numbers? Scope is a metric

The most common objection is real. Plenty of solid work never came with a dashboard. You inherited the system, nobody measured the before state, or the impact was spread across a team.

Scope still counts. The number of services you owned, the size of the user base, how often the process ran, how many engineers were on the team you led, how long the incident took to resolve before and after your change. “Maintained internal tooling” has nothing to bold. “Owned the build tooling used by roughly 80 engineers daily” does, and it is just as honest. Defensible estimates are fine. Invented precision is not, so “around 40 percent” you can explain beats “43.7 percent” you cannot.

Where the tech stack actually goes

None of this means hiding your stack. It means putting it where it works. Keep a clean skills section for the keyword pass, and let tool names appear unbolded inside bullets where the context shows real usage. A stack mentioned inside a story about scale is worth more than the same stack bolded in isolation, because now the reader has evidence of how much, not just whether.

And which metrics deserve the bold changes per application? A platform role cares about scale and reliability numbers. A product-facing role cares about user and revenue numbers. This is ordinary CV tailoring, just applied to emphasis rather than content, and it is one more reason one CV sprayed at every job keeps losing to a tailored one.

The tedious part is remembering your own numbers six months later, which is exactly why I keep them in a master profile in OutRung while they are fresh. When the metrics are recorded once with the achievement, choosing what to bold for a specific role becomes selection, not archaeology.

The skim test

Before you send anything, read your CV the way a recruiter will. Only the bolded fragments, top to bottom, nothing else.

If what you hear is a list of technologies, you have written a keyword index. If what you hear is scale, outcomes, and change, you have written an argument. Six seconds is enough time to make one point. Make sure it is the point only you can make.