I Built a Resume Reviewer Gem — Here's What It Actually Does

Keywords: resume review, AI for hiring, Gemini Gem, resume feedback, CV writing, technical hiring, action verbs, impact metrics

Reading time: ~8 minutes

I review resumes when hiring for my team, and I also occasionally help colleagues update their CVs when they're exploring new roles. Both activities produce the same categories of feedback repeatedly: weak action verbs, missing impact metrics, descriptions of job duties rather than accomplishments, walls of text where structure would help.

For the colleagues I help, the feedback usually needs to be specific and constructive. "Use stronger verbs" is not useful — anyone can say that. "Replace 'responsible for network monitoring' with 'monitored network performance across 200+ endpoints, reducing incident response time by 40%'" is useful. Getting to that level of specificity by hand, every time, across multiple resumes per week, was taking real time.

My Resume Reviewer Gem handles that first pass consistently. It gives targeted, actionable feedback calibrated to a specific role, not generic resume advice that could apply to anyone.

The Problem I Was Trying to Solve

Three specific problems kept showing up in resume review work:

First, generic feedback that didn't actually help. The standard advice ("add metrics," "use stronger verbs," "tailor to the role") is technically correct but doesn't tell someone what to write. Most people reading that advice don't know how to apply it to their specific experience. They'd come back with a slightly polished version of the same weak resume.

Second, inconsistency across resumes. When I was reviewing multiple resumes for the same role, the feedback I'd give each candidate wasn't always calibrated to the same standard. I'd give one candidate detailed structural feedback and another only surface-level comments. The candidates who got less feedback weren't necessarily weaker — they just hit me on a day I was less thorough. That's not fair and not useful.

Third, time cost. A thorough resume review with specific suggestions takes 20–30 minutes per resume. For a hiring loop with 8–10 candidates, that's three to five hours of review work that I'd rather spend elsewhere. For colleagues asking for help, the same time cost meant I either took too long to respond or gave less thorough feedback than the resume deserved.

Generic AI tools could help with some of this but gave me general-purpose resume advice. I wanted a tool that gave specific, role-targeted feedback — calibrated to whether the candidate was applying for a senior network engineer role, an entry-level sysadmin role, or something in between.

What I Tried First (and Why It Wasn't Enough)

My first approach was a checklist: "Are there metrics? Are there action verbs? Is it tailored?" The checklist helped me as the reviewer but didn't help the candidate — they got the same generic advice everyone gets.

Second was writing out detailed feedback templates for common resume patterns. This worked but the templates grew stale quickly, and I still had to manually apply them to each resume.

Third was using general-purpose AI with a long prompt explaining the role context. This worked better than the first two but the context had to be re-pasted each session, and the AI would sometimes drift into general resume advice instead of staying focused on the specific role.

What I wanted was a tool that already knew the kinds of roles I typically review for, gave specific before/after rewrites of weak lines, and didn't make me re-explain the context each time.

The Resume Reviewer Gem did exactly that.

The Gem I Use

Here's the core of the instructions I saved into the Gem:

You are my resume reviewer. You give targeted, specific feedback on resumes calibrated to a specific role.

When I share a resume (and optionally a job description):

  • Identify the three highest-impact improvements specific to this resume and role
  • For weak lines, provide a before/after rewrite with the underlying reason for the change
  • Flag missing metrics, generic descriptions, and structural issues
  • Don't give generic advice ("add metrics," "use stronger verbs") — every recommendation must be specific to a line on this resume
  • If the resume is well-suited to the role, say so — not every resume needs major revisions
  • Sort feedback by impact: what would change the hiring decision most first

My context: I hire for IT infrastructure roles (network engineers, sysadmins, SRE-adjacent). I value specificity over completeness — three high-impact improvements beat fifteen generic ones.

The "don't give generic advice — every recommendation must be specific to a line on this resume" instruction is the one that turned out to matter most. Without it, the Gem defaults to the standard resume advice everyone has heard. With it, every recommendation is grounded in the actual content.

Two Real Examples — Before and After

These are based on actual resumes I've reviewed. Names and companies are changed but the rewrites are real examples of the kind of feedback the Gem generates.

Example 1: Network Engineer Resume — Generic to Specific

Situation. A mid-level network engineer applying for a senior network engineer role at an ISP. The resume had solid experience but read like a list of duties rather than a story of impact.

What I asked the Gem:

"Review this resume for a senior network engineer role at a mid-size ISP. Give me the three highest-impact improvements with before/after rewrites."

Gem's response (excerpt):

Highest-impact improvement #1: Convert duty descriptions to impact statements

Before:

"Responsible for monitoring and maintaining enterprise network infrastructure."

After:

"Maintained network availability at 99.97% across 200+ enterprise endpoints, reducing average incident response time from 47 to 22 minutes through systematic monitoring improvements."

Why this works: The original is a duty. The rewrite quantifies scope (200+ endpoints), proves the outcome (99.97% availability), and shows the impact (47→22 minute MTTR). It also implies process improvement, which matters for senior roles.

Highest-impact improvement #2: Surface the scale of infrastructure managed

Before:

"Managed network security policy and access controls."

After:

"Authored and enforced network security policy across 12 sites and 3,000+ users, with zero security incidents during tenure."

Why this works: "12 sites and 3,000+ users" tells the ISP-scale hiring manager this person has worked at the scale they need. The "zero incidents" claim is specific and verifiable.

Highest-impact improvement #3: Add a brief leadership line if true

Before:

(no line on leadership or mentoring)

After (if applicable):

"Mentored two junior network engineers through promotion to mid-level; reviewed and approved all configuration changes from junior team members."

What the Gem got right. Each recommendation was specific to an actual line on the resume. The rewrites included both the change and the reasoning — useful for the candidate to learn from. The suggestions were sorted by impact (which would change the hiring decision most first), not by ease of fix. The third suggestion explicitly added "if applicable" rather than fabricating evidence.

What I changed before passing back. About 10% — I softened one rewrite to keep the candidate's voice, removed one suggestion that didn't apply, added a clarifying note about which rewrites they could do without my input. The structure and the core rewrites were the Gem's.

Example 2: Colleague Resume — Tailoring for a Specific Role

Situation. A colleague with a strong generalist IT background was applying for a specific SRE-adjacent role. Her existing resume emphasized helpdesk and end-user support — relevant but not the focus of the role she wanted.

What I asked the Gem:

"Here's a resume and the target job description. The candidate has more relevant experience than the resume shows. Tell me what to surface."

Gem's response (excerpt):

The resume undersells her. Three pieces of likely-hidden experience:

1. The on-call rotation she did for two years. The job description calls out "participate in on-call rotation" and "respond to production incidents" — her resume doesn't mention the 24/7 rotation she covered from 2022 to 2024. This is exactly the experience the role wants.

Add: "Participated in 24/7 on-call rotation covering 40+ production services; first responder for incidents impacting business-critical systems."

2. The monitoring tooling she built. She built a Grafana dashboard system for the IT infrastructure team — the resume doesn't mention this. The job description lists "experience with monitoring and observability tooling" as a requirement.

Add: "Built and maintained Grafana monitoring dashboards for 12 production services, reducing time-to-detection for incidents by ~30%."

3. The scripting work that's buried. Her resume mentions "various automation tasks" without specifics. The job description wants scripting experience.

Replace:

"Various automation tasks" → "Wrote Python scripts automating routine infrastructure tasks (user provisioning, log rotation, alert tuning), saving approximately 8 hours/week of manual work."

What the Gem got right. It connected specific lines in the job description to specific experience the candidate likely had. Each suggestion was something the candidate could add — not fabricated experience, just uncovered experience. The rewrites were concrete enough that the candidate could use them directly.

What I changed before passing back. About 15% — I verified the dates and details against what I knew about her actual work history (the Gem didn't have access to that), softened one rewrite, added context for why each addition matters to the specific role she was applying for. The core suggestions were the Gem's.

Where This Works and Where It Doesn't

After about two years of use across maybe 50 resumes, here's an honest assessment.

It works well for:

  • Before/after rewrites of weak lines. The specific, line-by-line feedback is what the tool does best.
  • Surfacing hidden experience. When the candidate has more relevant work than the resume shows.
  • Calibrating to a specific role. Given a job description, the feedback gets more targeted.
  • Sorting feedback by impact. The "what would change the hiring decision most" framing is more useful than a long list.

It doesn't work well for:

  • Final hiring decisions. The Gem gives feedback; the decision is the hiring manager's. Don't use AI to decide whether to interview a candidate — use it to give them better feedback if you don't interview them.
  • Roles where you don't have a clear rubric. Without a job description or clear criteria, the Gem defaults to general resume advice.
  • Resumes with structural problems beyond content. If the layout is broken or sections are missing entirely, that's not what this tool is for.
  • Candidates with truly weak experience. If the experience itself doesn't fit the role, no rewrite will fix that. The Gem can flag this but can't manufacture experience.

How to Use This

The workflow that works:

  1. Get the resume and the target job description (if there is one).
  2. Paste both into the Gem with a request for the three highest-impact improvements.
  3. Review the suggestions against what you actually know about the candidate's experience. Verify the rewrites don't add claims that aren't true.
  4. Pass back the feedback with both the rewrites and the underlying reasoning — useful for the candidate's learning.
  5. For hiring: treat the feedback as one input. Use your judgment about overall fit, not just resume polish.

The most common mistake is passing back suggestions without verifying them. The Gem is good, but it doesn't know the candidate's actual experience. A rewrite that sounds plausible but includes fabricated metrics is worse than the original weak line. Always cross-check against what the candidate actually did.

A Note on What This Replaces

The Gem doesn't replace the judgment about whether a candidate fits a role. It doesn't replace the conversation with a candidate about their experience. And it doesn't replace the work of actually doing the job.

What it replaces is the time spent writing detailed, line-by-line feedback by hand. For me, that's roughly 15–20 minutes per resume that I can now spend elsewhere. For colleagues asking for help, the feedback quality is higher and the turnaround time is faster.

The wins are mostly time savings on consistent work — the kind of feedback I was already giving but more slowly. Over a year of hiring cycles and helping colleagues, that's meaningful time back.

Related Reading

Sources

— Justin

📅 First published: 2026-05-08 | 🔄 Last updated: 2026-06-21