What I Look for in the First 30 Seconds of a Resume

I've reviewed hundreds of resumes for technical roles. Most people assume I'm scanning for specific technologies, certifications or years of experience.

I'm not.

In the first 30 seconds, I'm answering one question: can this person solve real problems, and explain them clearly?

Everything else comes later.

Where my eyes actually go

In those 30 seconds, I'm not reading. I'm scanning, roughly in this order:

1. The top third of the page. Who are you, and what are you good at? If I have to hunt for it, that's already an answer.
2. Your most recent role. What did you actually change there?
3. The first few words of each bullet. Do they start with results, or with "Responsible for"?

If those three things tell a clear story, I keep reading. If they don't, a great resume can lose to a merely good one that's easier to read.

What catches my attention

Impact, not a task list.

• Instead of: "Responsible for managing database systems"
• Try: "Cut query response times by 60%, reducing server costs by $40K a year"

A job description tells me what you were supposed to do. An impact statement tells me what you did.

Business context, not just technical skill.

• Instead of: "Implemented a microservices architecture"
• Try: "Redesigned the architecture to handle 10x user growth, allowing the company to expand into two new markets"

I can teach someone a technology. It's much harder to teach someone to care about the business outcome.

Clear writing.

If your resume is full of buzzwords and unexplained acronyms, I start to wonder how you'll explain things to a CFO, a customer or a new team member. Your resume is your first writing sample.

Problem-solving stories.

The best bullets follow a simple shape: here was the problem, here's what I did, here's what changed. Three of those are worth more than a page of responsibilities.

What makes me pause

• Every technology you've ever touched, with no context. Surface knowledge of 40 tools is worth less than deep expertise in a few - and I'll ask about any of them in the interview.
• Vague phrases like "worked on various projects." They tell me nothing.
• No measurable outcomes at all. If you've worked for years and can't point to anything that got faster, cheaper, safer or bigger because of you, that's a concern.
• A resume that doesn't match your LinkedIn. Different dates, different titles. I'll notice.

The AI-written resume problem

Here's what's changed in the last couple of years: an awful lot of resumes now read the same. Polished, confident, full of strong verbs - and almost completely generic.

AI tools are genuinely useful for tightening your wording and catching mistakes. But they can't supply the one thing that makes a resume stand out: specifics only you could know. The actual system. The actual number. The actual problem nobody else wanted to touch.

"Spearheaded cross-functional initiatives to drive operational excellence" could be anyone. "Replaced a nightly manual export with an automated feed, saving the finance team six hours a week" could only be you.

Use AI to polish. Don't let it write the substance - because the substance is the only part I'm really reading.

What I'm really evaluating

Behind the skim, I'm trying to answer four questions:

• Do you think like a business person who knows technology - or a technologist who occasionally remembers there's a business?
• Can you explain complex things simply?
• Do you take ownership of outcomes, not just tasks?
• Have you grown? Are your recent roles bigger, more complex or more strategic than your early ones?

How to fix yours: the "so what?" test

Take each bullet and ask "so what?" Then ask it again. Keep going until you reach something a business would care about.

• "Migrated servers to the cloud." So what?
• "…which removed our dependence on an aging data center." So what?
• "…which cut hosting costs by 30% and ended the monthly outages."

That last version is the bullet.

A few other habits that help:

• Use numbers. Percentages, money, time saved, users served. If you don't have exact figures, a credible estimate is better than nothing.
• Lead with the result, then explain how.
• Write for a non-technical reader. The first person to read your resume often isn't an engineer.
• Cut ruthlessly. Older roles can shrink to a line or two. Nobody needs your 2009 help-desk duties in detail.

The bottom line

Your resume isn't a complete record of everything you've done. It's a marketing document with one job: to get you a conversation.

In those first 30 seconds, I'm deciding whether you understand that.

Related reading

• CTO or CIO? How to Tell Which One Your Company Actually Needs
• Every Organization Has a Sarah (And Why That's a Problem)

If you found this useful, subscribe to the newsletter for more on technology leadership, careers and the decisions that shape both.