Summary: A resume is not a self-narration; it is a document scanned by three gates with different standards. Strong technical skills but no interview calls? The problem is often not ability, but that you spent your effort on the wrong gates. At the end of this article, there are three sets of "before / after" comparisons you can follow directly.

Preface

"Put everything I've done on it" is the most common way to start writing a resume, and also the easiest way to waste effort.

A resume is not a self-narration; it is a document that gets scanned by three gates: HR initial screening, technical interviewer re-screening, and formal interview follow-ups. The standards differ for each gate, and some are even opposite. If you have strong technical skills but can't get interviews, the problem is likely not your ability, but that you put your effort into the second and third gates, and no one caught you at the first gate.

The following breaks it down by these three gates, and finally lands on specific sentences. The examples use AI agent projects, which have typical pitfalls.

First Gate: Initial Screening, Essentially Keyword Matching

Initial screening takes seconds, not minutes. The reviewer might be an HR person, or a department head who's scrolling through resumes while in a meeting. He won't read how cleverly you designed your fallback solution; he does one thing: takes the keywords from the job description and finds matches in your resume.

If no match, next.

So the elimination reasons at this gate are usually plain: job keywords, project direction, and tech stack don't align. Note it's about "relevance," not "presence." You wrote LangChain, you wrote RAG, but the job wants "agent orchestration" and "multi-turn dialogue." If there's no bridge, you're out.

How to write:

• Put the job title at the top; don't make people guess what position you're applying for.
• Put the tech stack on its own line, and use the exact words from the JD as much as possible. He writes "large model application development," so you shouldn't just write "AI development."
• Put direction words in the project title. "Enterprise knowledge base Q&A (RAG + multi-turn dialogue)" is far more useful than "XX intelligent system."
• Remove fluff. Words like "deeply involved," "fully responsible," and "effectively improved" are pure noise at the initial screening stage; they take up space and block keywords.

Summary: The first gate does not reward writing style, only hits.

Second Gate: Technical Re-screening, Looking at "Did You Actually Do This Work"

After passing initial screening, the resume lands in the hands of a technical interviewer. He scans quickly and simultaneously asks three questions.

1. Was this project actually done? The basis is engineering traces: fallback, rate limiting, timeout retry, context isolation, exception handling, canary release. Having these words shows you faced real traffic and real failures; if it's all "implemented," "integrated," "completed," it reads like a course assignment written after running a demo.
2. Is it worth an hour's interview? Interviews cost time, and the interviewer's time is tighter than yours. He quickly judges whether this is a chat wrapper that calls APIs, or something people actually use and can be backed up when problems occur. If he can't judge, he won't schedule — not because you're unqualified, but because he can't spare that hour.
3. Is there a point that can be talked about for half an hour? For example, routing or scheduling logic you designed yourself, how memory is stored and trimmed, what to do when the model times out or returns empty, how costs were reduced. One is enough; if there's none, the interview becomes awkward trivia.

Summary: This gate doesn't look at how hard you worked, only at whether the project has traces of "actually being used in production."

Third Gate: Interview Follow-ups, Every Sentence on the Resume Is an Invitation to Question

When you reach the interview, the resume's role changes: from "introduction" to "question paper."

The interviewer won't spread effort evenly; he'll pick the brightest two or three lines and drill down. You write "familiar with RAG retrieval," and he'll likely ask: How do you split documents? After splitting, how do you ensure semantic boundaries aren't cut? Why this chunk size? When recall is poor, which layer do you tune first? Should you add rerank, and how much latency does it add? What metrics do you use to monitor online recall?

Notice none of these questions are "What is RAG?" They are all "How did you decide at that time?" This is also why people who memorize interview questions slip at this stage: they can answer concept questions, but not decision questions.

So the habit you should cultivate when writing a resume is to ask yourself for every line: If this sentence gets questioned three levels deep, can I answer it?

If you can't, there are two options.

1. Option 1: Downgrade your wording. Replace "master" with "participate," "led the design" with "used," "independently implemented" with "modified based on XX solution." Lower the wording, and the depth of follow-ups also drops.
2. Option 2: Fill in the knowledge gap. First thoroughly understand this content, and only write it back when you can truly answer.

Pitfall reminder: What you should never do is write it anyway — the interviewer is usually more familiar with this direction than you, and one follow-up question will expose you.

Down to Sentences: Three Comparisons

The principles are done. Let's look at sentences. All are taken from agent-type projects; the numbers are illustrative, replace them with your own real values — fabricated numbers will be exposed in follow-ups within seconds.

Case 1

Before: Responsible for backend development of the agent project, used large model API to implement multi-turn dialogue, improved user experience.

After: I was responsible for the session layer of the agent dialogue service. The original approach was to stuff the entire history into the prompt every turn; on long sessions, token cost rose linearly with turns, and after exceeding 8k, the model started losing earlier context. I changed it to a two-tier context: per-topic segmented summaries + the most recent N turns of raw text. The average token per session dropped about 40%, and the problem of irrelevant answers in long sessions was notably reduced.

Case 2

Before: Used RAG technology to build a knowledge base Q&A, improved answer accuracy.

After: The retrieval side of the knowledge base Q&A. The first version used pure vector recall. In practice, I found that table-type and number-type questions often failed recall. I added BM25 for hybrid recall, then unified reranking. Manual spot-check badcases dropped from about 9 out of 100 to about 4. The cost was that P95 latency increased by about 200ms, partially offset by a high-frequency question cache.

Case 3

Before: Familiar with large model calls, rich experience in prompt engineering.

After: The model call layer has two-tier fallback: if the primary model doesn't return within 8 seconds or returns structurally invalid output, switch to a backup model; if the backup also fails, return a rule-based fallback phrase and log an alert. After launch, such failures account for about 3% of total requests, and users barely notice.

Core rule: The revised sentences all contain three things: a specific scenario, a trade-off made at the time, and a verifiable result. When these three are present, the interviewer's questions will naturally go deeper, and you can answer — because that's what you actually did.

Negative pitfall: Writing "independently designed and implemented a high-concurrency agent scheduling system supporting millions of calls" when it's actually an internal tool for a few dozen users — that line is digging a trap for yourself: follow-ups about QPS, deployment form, and bottlenecks will expose you within three rounds. The most expensive thing on a resume is not the highlight, it's the hole.

Self-check After Writing

The three gates together are one thing: resume writing is reverse-calculated from the end.

• To get scanned by initial screening: put keywords up front, use the JD's original words;
• To get the technical interviewer willing to schedule: write out engineering traces and real usage results;
• To withstand follow-ups: run every sentence through "can I answer three levels deep?"

Self-check method:

After writing, do a self-check: send the resume to someone who doesn't know your project, ask them to come up with ten questions based only on the resume. Keep the ones you can answer, change wording or delete the ones you can't. After this round, the resume is no longer a stream of experiences, but something you can actually back up.