Resume Do's, Don'ts, and Deal Breakers for Software Engineers

Most resume advice imagines one careful reader studying the page. In my experience the document actually gets two fast reads, by two different people, with two different goals, and a resume tuned only for the first read leaves the second one entirely to chance.

The first read happens at screening time, when a recruiter or hiring manager decides whether you get an interview loop at all. Honest disclosure before I go further: I've spent a lot of time on the interviewing side of loops and essentially none on the sourcing and screening side, so my picture of this read comes from recruiter writeups and candidate reports rather than firsthand experience (the screening world deserves its own piece, on how applications actually get seen in the first place, and I'd take corrections from working recruiters gladly). The claims that show up consistently: this read is quick, often cited at somewhere between 30 seconds and a couple of minutes, it scans for evidence you fit the role family, and formatting problems can end things before the content is ever weighed.

The second read is the one I can speak to directly, because I've done it many times. Roughly 5-15 minutes before your round, your interviewer (often assigned to your loop that same morning) opens your resume for the first time and skims it with a single purpose: choosing the 2-3 things they'll dig into during the interview.

What the pre-round skim actually looks like

From the interviewer's chair, those few minutes usually break down into three moves:

• Choosing the 2-3 most interesting or most senior-sounding claims to probe ("led the migration," "cut infra costs 40%," "owned the billing service"). The follow-up questions write themselves, and the answers are informative fast.
• Mapping lines to the round about to happen. If your resume mentions "designed event-driven architecture" and I'm running your system design round, that phrase just became part of the agenda.
• Noting anything confusing, like overlapping dates, an unexplained multi-year gap, or titles that go senior then junior, so it can be asked about neutrally rather than guessed at.

The consequence is that every line on the page is an invitation for a question, whether you intended it that way or not. A bullet you can expand on comfortably for two minutes is working for you before the round even begins, while a padded bullet is a landmine you set for yourself, since the interviewer has no way to tell which kind they're pointing at until they ask.

I do a fair bit of woodworking, and resume polish maps pretty well onto sanding. It's tedious, nobody compliments it directly, and it contributes nothing structural, but the surface is what everyone touches first, so it earns attention far out of proportion to how interesting the work is. Skipping it leaves the joinery just as strong underneath, it only guarantees nobody gets close enough to appreciate the joinery.

The do's that both reads reward

• Quantified impact with honest numbers. "Reduced p95 latency from 800ms to 300ms on a service handling 2M requests/day" holds up under questioning in a way "improved performance" never will. Honest matters more than impressive, because the follow-up is coming ("how did you measure that, and what did you try first?"), and a modest real number you can walk through beats an inflated one you can't. More on that in the deal breakers below.
• A single scannable page, two at most for senior candidates with long histories. The recruiter writeups agree on this for the first read, and it matches the pre-round skim too: an interviewer can't probe what they never saw, and page three is where bullets go to be unread.
• A top third tailored to the role family. A full rewrite per application usually isn't realistic, and in my view it isn't necessary; the top third (your summary line if you use one, how your most recent role is framed, which skills you choose to surface) is the part that should clearly match the job family you're targeting, whether that's backend, frontend, ML, or infra.
• Plain language instead of buzzword soup. "Built the service that processes refunds for 40 countries" lands on both passes. "Leveraged best-in-class microservice paradigms to drive scalable outcomes" gets skimmed past, and a skipped bullet contributed nothing.

The don'ts

• Skill-soup lists. Thirty technologies in a block signals almost nothing, because nobody is fluent in thirty things and every reader knows it. In a pre-round skim, the giant skills section is the first thing that gets skipped. A list of 8-12 things you would happily be grilled on reads far stronger.
• Three pages covering everything. The cutting is the real work of resume writing. The internship from 2014 can go.
• Mystery gaps and overlaps. In the debriefs I've sat in, a gap with a one-line explanation ("2023: career break, family caregiving") is a total non-event. An unexplained gap hands the reader a blank to fill in, and their version will usually be worse than yours. Overlapping dates work the same way; if you consulted while employed, a single line saying so beats leaving it a puzzle.
• Tiny fonts. Squeezing onto one page with an 8-point font defeats the point of one page, which is scannability. If the reader has to zoom in, some of those bullets effectively don't exist.

If your current resume just failed several of those checks, don't be too hard on yourself. Most resumes look like this, partly because a lot of standard advice pushes people toward stuffing, and stuffing feels safer than cutting right up until somebody actually reads the result.

The deal breakers

These are patterns I have personally seen flagged in debriefs, which is a higher bar than "things interviewers find annoying."

1. Claims that collapse under one follow-up question. By far the most damaging. The resume writes checks the interview has to cash, and I've watched "led the Kubernetes migration" become "I attended the migration meetings" after one "what was the hardest part?" The cost goes well past that single bullet, because every other line on the page becomes suspect in the same moment. The weaker-but-true version ("worked on the team that migrated us to Kubernetes, owned the CI pipeline cutover") would have been probed, passed, and frankly landed better.
2. Obvious template or AI sameness. I'll hedge this one properly, since a reader can rarely prove any specific resume was generated. But when several resumes in one week share the identical "spearheaded cross-functional initiatives driving scalable impact" cadence, they blur together, and blurring together is exactly the failure on a fast read. Using AI to tighten your own writing seems fine to me; letting it manufacture claims in language you would never say out loud goes wrong in the room, because the seam between how the resume talks and how you talk is audible.
3. Seniority claims your stories can't back. Interviewers calibrate follow-ups to the level the resume claims (loops really do differ by level, which I've written about in new grad vs. senior loops). A resume where every line says "led," "owned," and "drove," followed by purely individual-contributor stories, downlevels the candidate in real time. Claiming the level your stories genuinely support produces the better outcome, and if you're unsure which claims your stories can carry, building a STAR story bank is the systematic way to find out.

Read your own resume like your interviewer will

The prep exercise almost nobody runs: sit down with your own resume for 5 minutes and pick the 2-3 bullets you would probe if it belonged to a stranger. Then check, out loud, whether each one survives two follow-up questions. The free version is a friend reading it cold and asking "tell me more about this one" and "what was the hard part?" about whatever catches their eye. When a bullet dies in that exercise, fix the bullet or build the story behind it before someone with a hiring decision runs the same experiment for real.

A resume's job doesn't end when it gets you the interview; it sets the agenda for the interview itself, so the hours you spend cutting, quantifying, and pressure-testing bullets pay off twice. If you want that pressure-testing to come from something that asks real follow-up questions, running a behavioral mock off your actual resume claims is one of the things we built Preppable for, and a patient friend with your resume in hand covers a lot of the same ground for free. Either way, make sure somebody asks you the second question before it counts.