Rejectless
Software engineer resume feedback
Resume Writing12 min read

The Resume Feedback Checklist: 15 Things to Fix Before You Apply

The same 15 checks our linting tool runs on every resume, explained step by step. Run through them manually — or let the tool do it in seconds.

Rejectless

Thejus Sunny

Engineering + hiring perspective

We built a resume feedback tool that checks hundreds of patterns across thousands of software engineer resumes. After analyzing the most common issues, we distilled everything into 15 checks. These 15 catch 90% of the problems that get resumes rejected or ignored.

You can run through them manually — read each check, compare it against your resume, fix what fails. Or you can upload your resume to Rejectless and get severity-graded feedback on all 15 checks (and dozens more) in about 10 seconds. Either way, don't hit apply until your resume passes all 15.

Each check below is tagged with a severity level: Critical (this alone can get you rejected), Warning (weakens your resume noticeably), or Info (polish issue worth fixing). These match the severity levels in the Rejectless linting tool.

Content Checks

These five checks evaluate what your resume says. Content problems are the #1 reason strong engineers get ghosted — the template is fine, the formatting is fine, but the bullets don't communicate what you actually did.

Check 1: Does every bullet start with a strong action verb? [Warning]

Scan the first word of every bullet on your resume. If you see 'Responsible for,' 'Helped,' 'Worked on,' 'Assisted,' or 'Utilized,' that bullet needs a rewrite. These words describe proximity to work, not ownership of outcomes. They signal that you were present, not that you delivered.

Fail: 'Responsible for maintaining the CI/CD pipeline and handling deployments.'

Pass: 'Reduced CI build time from 24 minutes to 7 minutes by parallelizing test suites and caching Docker layers across 32 repositories.'

The fix is simple: replace the weak opener with the verb that describes what you actually did. If you can't find a strong verb, the bullet is probably describing a responsibility rather than an accomplishment — and that's the real problem to solve.

Need help picking the right verb? Our guide to 100 action verbs for software engineer resumes organizes verbs by what you actually did — building, optimizing, leading, debugging, and more.

Check 2: Does every bullet contain a specific outcome or deliverable? [Critical]

Read each bullet and ask: 'What was the result?' If the bullet describes activity without outcome, it fails this check. Recruiters don't care what you worked on — they care what happened because of your work. A bullet without an outcome is just a task description.

Fail: 'Developed microservices using Node.js and deployed them to Kubernetes.'

Pass: 'Developed 6 Node.js microservices handling the checkout pipeline, deployed on EKS with auto-scaling — reducing deployment cycle from 2 weeks to 4 hours and supporting 15K RPM at peak.'

The outcome doesn't always have to be a number. 'Adopted by 4 product teams,' 'eliminated manual reporting entirely,' or 'passed SOC 2 audit with zero critical findings' are all specific outcomes. The key is that the reader knows what changed because you did this work.

Check 3: Are metrics scoped and defensible? [Critical]

This is the most common critical issue we flag. 'Improved performance by 30%' appears on thousands of SWE resumes — and it means nothing without scope. 30% of what? Measured how? What was the baseline? An interviewer will ask, and if you stumble, the bullet becomes a liability instead of an asset.

Fail: 'Improved system performance by 30%.'

Pass: 'Reduced P95 API latency from 1.2s to 840ms (30%) on the payments endpoint by adding Redis caching for merchant lookups and batching downstream database queries.'

Every metric on your resume should pass the '30% of what?' test. Name the system, state the baseline and result, and explain the method. If you can't scope a metric, either find the right scope or remove the number — a bullet without a metric is better than a bullet with an undefensible one.

This problem is so pervasive that we wrote a dedicated guide: Why 'Improved Performance by 30%' Hurts Your SWE Resume.

Check 4: Can you explain every bullet in a 60-second interview answer? [Warning]

Read each bullet aloud and imagine an interviewer saying: 'Tell me more about that.' Can you talk for 60 seconds about the context, your specific contribution, the technical challenges, and the outcome? If a bullet makes you hesitate — if you'd have to bluff or deflect — it doesn't belong on your resume.

Fail: 'Spearheaded the company's cloud migration strategy across all services.' (Were you really the strategist, or were you one of four engineers on the migration team?)

Pass: 'Migrated 12 services from EC2 to EKS as part of a 4-person platform team, writing Helm charts and CI/CD pipelines for zero-downtime cutover.' (Honest scope, clear contribution, defensible.)

The interview-defensibility test catches two problems: overclaiming (taking credit for team work) and underclaiming (writing vague bullets because you don't think your actual work sounds impressive). Both are fixable by describing your real scope honestly and specifically.

Check 5: Have you removed all bullets that are just job descriptions? [Warning]

A job description tells you what you were supposed to do. A resume bullet tells the reader what you actually accomplished. If your bullet could appear on a job posting for the same role, it's a description, not an achievement.

Fail: 'Developed and maintained web applications using React and Python.' (This is a job requirement, not an accomplishment.)

Pass: 'Built a real-time analytics dashboard in React and D3.js displaying 12 KPI widgets with sub-second updates via WebSocket, adopted by 340 internal users within the first month.' (This is a specific thing you shipped with a measurable result.)

The test: if you replaced your name with a colleague's who had the same job title, would the bullet still be true? If yes, it's a job description. Your bullets should describe work that only you did — specific projects, specific systems, specific outcomes.

For a complete guide to writing bullets that pass all 5 content checks, read How to Write Resume Bullet Points for Software Engineers (40+ Examples).

Credibility Checks

These five checks evaluate whether your resume is believable. Content can be strong on paper but fail the credibility test — inflated claims, unclear ownership, and context-free technology lists all raise red flags for experienced hiring managers.

Check 6: Are there any unverifiable superlatives? [Warning]

Words like 'best,' 'top,' 'leading,' 'cutting-edge,' 'world-class,' and 'state-of-the-art' are red flags. They're subjective claims that can't be verified and signal that the candidate is selling rather than reporting. A strong resume states facts and lets the reader draw conclusions.

Fail: 'Built a cutting-edge, state-of-the-art machine learning pipeline for the company's leading product.'

Pass: 'Built an ML pipeline (scikit-learn + Airflow) that generates product recommendations for 2.1M users, increasing click-through rate by 18% over the previous rule-based system.'

If a claim can't be independently verified from the resume alone, remove the adjective and add a fact instead. 'Cutting-edge' tells the reader nothing. 'Processing 2.1M users' tells them everything.

Check 7: Is ownership clear? [Critical]

Every bullet should make clear whether YOU did this or your TEAM did this. Ambiguous ownership is one of the most damaging credibility issues because interviewers will probe it — and if your answer is 'well, the team did it,' you lose trust instantly.

Fail: 'Launched a new payment processing system that handles $10M in monthly transactions.'

Pass: 'Built the idempotent retry logic and webhook reconciliation layer for the payment processing system (4-person team), handling $10M in monthly transactions with 99.98% success rate.'

You don't need to claim you did everything solo. Specifying your contribution within a team context is more credible AND more impressive to experienced interviewers. 'As part of a 4-person team' followed by your specific contribution shows self-awareness and honesty.

Check 8: Are technologies mentioned in context, not just listed? [Warning]

Your Skills section lists technologies. Your bullet points should show them in action. A bullet that reads like a tech stack list ('Used React, Redux, Node.js, Express, MongoDB, and Docker') wastes space and tells the reader nothing about your proficiency.

Fail: 'Utilized React, TypeScript, GraphQL, and PostgreSQL for full-stack development.'

Pass: 'Built a multi-tenant workspace system with a React/TypeScript frontend using GraphQL subscriptions for real-time updates and PostgreSQL row-level security for data isolation — onboarding 120 enterprise teams in the first quarter.'

The rule: technologies in bullets should appear as part of how you solved a problem, not as a standalone list. If a technology name isn't attached to a specific action and outcome, move it to the Skills section.

Check 9: Do your dates and titles make sense together? [Info]

Experienced recruiters mentally validate your timeline. A 'Senior Engineer' title after 1 year of total experience raises questions. A gap between roles without explanation can trigger assumptions. A company name they can't find on LinkedIn creates doubt.

Fail: 'Senior Software Engineer, Jan 2024 – Present' (with graduation date of May 2023 — that's a senior title after 8 months of experience).

Pass: 'Software Engineer II, Jan 2024 – Present' or provide context for the rapid progression if the senior title is legitimate.

This isn't about hiding your career path. It's about making sure your timeline tells a coherent story. If something looks unusual (rapid promotion, short tenure, career change), address it proactively rather than hoping nobody notices.

Check 10: Would a skeptical interviewer believe this? [Critical]

Read every bullet as if you were a staff engineer interviewing this candidate. Does anything feel inflated? Does any claim seem too broad for the stated role level? Would you want to dig into any bullet because it seems too good to be true?

Fail: 'Single-handedly rebuilt the entire backend infrastructure, reducing costs by 80% and improving performance by 10x.' (This strains credulity for any single engineer.)

Pass: 'Led the backend cost optimization initiative — identified 4 underutilized services via AWS Cost Explorer, right-sized EC2 instances, and migrated batch jobs to Spot — reducing monthly infrastructure spend from $34K to $18K.'

If a bullet makes a skeptical reader think 'really?' — it needs to be either scoped down to your actual contribution or supported with enough detail that the claim becomes believable. Specificity is the antidote to skepticism.

Format and Structure Checks

These five checks evaluate how your resume looks and whether it will survive the technical journey from your computer to a recruiter's screen. Format issues are less damaging than content issues — but they're also the easiest to fix.

Check 11: Is the template single-column and ATS-safe? [Critical]

If your resume uses a two-column layout, sidebars, text boxes, tables for layout, or graphics embedded as images, it may fail ATS parsing. The failure is silent — you'll never know which applications were garbled. Single-column layouts with standard section headings parse correctly in every major ATS (Workday, Greenhouse, Lever, iCIMS, Taleo).

Fail: A two-column template with a sidebar for skills and contact info, or a resume with icons and graphics embedded as images.

Pass: A single-column template like Jake's Resume or Deedy's (single-column variant) with plain text, standard fonts, and no embedded graphics.

For a deep dive on why single-column wins, read Why Single-Column Resumes Outperform Two-Column for ATS. And if you need a template, Jake's Resume Builder gives you the #1 ATS-safe template with a visual editor.

Check 12: Is the section order right for your experience level? [Warning]

Section order communicates priority. Lead with your strongest section — the one that best answers 'why should we interview this person?' Getting this wrong buries your best material below the fold.

  • New grad (0-1 years): Education → Projects → Experience → Skills
  • Early career (1-3 years): Education → Experience → Projects → Skills
  • Mid-level (3-7 years): Experience → Skills → Projects → Education
  • Senior (7+ years): Experience → Skills → Education (Projects optional)

Fail: A senior engineer with 8 years of experience leading with Education and a 3.4 GPA from 2016.

Pass: The same senior engineer leading with Experience, highlighting their two most impactful roles with quantified bullets.

Check 13: Is it one page (or justified if two)? [Warning]

For software engineers with fewer than 10 years of experience, one page is the standard. Not because of an arbitrary rule — because a focused one-page resume forces you to curate your strongest material rather than including everything. Two-page resumes are acceptable for senior/staff engineers with 10+ years, but only if the second page contains material that wouldn't fit on one page without cutting strong content.

Fail: A 2-page resume from a mid-level engineer where page 2 contains a 'Certifications' section and 3 bullets from a college internship.

Pass: A 1-page resume with 3-4 strong experience entries, focused projects, and a curated skills section — everything justifies its space.

If you're struggling to fit on one page, the problem isn't space — it's curation. Cut your weakest bullets, remove older or less relevant roles, and tighten your project descriptions. Every line should earn its place.

Check 14: Are font, spacing, and date formats consistent? [Info]

Inconsistent formatting creates a subconscious impression of carelessness. It won't get you rejected on its own, but it undermines the professional image that a clean template is supposed to project.

Common inconsistencies to check:

  • Date format: 'Jan 2024 – Present' in one place, 'January 2024 - Present' in another
  • Dashes: Hyphens (-) mixed with em dashes (—) mixed with en dashes (–) in date ranges
  • Capitalization: 'Software Engineer' vs 'Software engineer' across different roles
  • Bullet punctuation: Some bullets end with periods, others don't
  • Spacing: Inconsistent gaps between sections or between role headers and bullets

Fail: A resume where the first job uses 'Jan 2024 – Present,' the second uses '2023-2024,' and the third uses 'May 2022 to August 2023.'

Pass: Every date uses the same format ('Mon YYYY – Mon YYYY'), every bullet ends consistently (periods or no periods — pick one), and spacing is uniform throughout.

The Rejectless builder handles all of this automatically — dates, dashes, spacing, and punctuation are formatted consistently by default.

Check 15: Does the PDF export correctly with real text layers? [Critical]

This is the check most people skip — and it's critical. Some resume tools export PDFs as flattened images, not selectable text. If your PDF doesn't have a real text layer, ATS systems can't parse it, recruiters can't search it, and copy-pasting your content into another format produces garbled output.

Test: Open your exported PDF and try to select and copy a paragraph. Paste it into a text editor. Does it come through as clean, readable text? Or is it garbled, out of order, or missing characters?

Fail: A PDF exported from Canva or Figma where text selection produces garbled output or no selectable text at all.

Pass: A PDF where all text is selectable, copy-paste produces clean output, and the file size is reasonable (under 500KB for a 1-page resume — image-heavy PDFs are a red flag).

Both LaTeX-generated PDFs and Rejectless builder exports produce proper text layers. If you're using a design tool, always test the PDF export before submitting.

Or Let the Tool Run All 15 Checks in 10 Seconds

You can run through this checklist manually. Read each check, compare it against your resume, fix what fails. It works — but it takes time, and your own eye is naturally forgiving of your own writing.

Rejectless runs all 15 of these checks — plus dozens of additional patterns — automatically. Upload your resume and get severity-graded, line-by-line feedback in seconds. Every issue is tagged as Critical, Warning, or Info, so you know exactly what to fix first.

The content checks (1-5) catch vague bullets, weak verbs, unscoped metrics, and job-description filler. The credibility checks (6-10) flag overclaiming, ambiguous ownership, and unverifiable superlatives. The format checks (11-15) verify ATS safety, section order, and export quality.

Frequently Asked Questions

What counts as good resume feedback?

Good resume feedback is specific, actionable, and tied to outcomes. 'Your resume looks good' is not feedback. 'Your third bullet under Company X claims a 30% improvement without specifying the baseline, metric, or system — scope it or remove the number' is feedback. Every piece of feedback should point to a specific problem and suggest a specific fix.

Should I pay for resume feedback?

That depends on the quality of the feedback. A $200 'professional resume review' that gives you vague encouragement is worthless. A free tool that gives you line-by-line, specific, actionable feedback is invaluable. The price doesn't determine the value — the specificity and accuracy of the feedback does. Rejectless provides severity-graded, bullet-by-bullet feedback for free.

How is this different from an ATS checker?

ATS checkers evaluate whether your resume can be parsed by applicant tracking systems — formatting, file type, and keyword matching. That's checks 11 and 15 on this list. The other 13 checks evaluate your content and credibility, which is what actually determines whether a human reviewer wants to interview you. ATS parsing is necessary but not sufficient. Rejectless checks both.

How often should I get feedback on my resume?

Every time you make significant changes — adding a new role, rewriting bullets for a different target, or restructuring sections. Don't submit a revised resume without running it through feedback again. Small edits can introduce new issues (inconsistent formatting, tense mismatches, orphaned bullets) that you won't catch on your own.