AI Resume Prompts for Software Engineers

Turn a Stack List Into Evidence of Impact

Your bullets name technologies — Kubernetes, Kafka, React — and a reader still cannot tell what you built, how large it was, or what changed because you were on the team

I am a software engineer rewriting my resume. Below are my current experience bullets, my skills section, and 1 real artifact from a project I worked on.

MY BULLETS:
[PASTE YOUR CURRENT EXPERIENCE BULLETS]

MY SKILLS SECTION:
[PASTE YOUR SKILLS OR TECHNOLOGIES LIST]

ARTIFACT (pull request description, design doc, incident postmortem, or sprint recap):
[PASTE THE ARTIFACT]

Work through this in 3 passes.

PASS 1 — Sort my bullets.
Put every bullet into 1 of 3 buckets and quote it back to me:
- Tooling only: it names a technology and nothing else ("Used Docker and Terraform").
- Task only: it describes work assigned to me but not what changed ("Wrote unit tests for the billing service").
- Evidence: it names a system, a decision I made, and something that moved.
Say how many bullets landed in each bucket. Do not rewrite anything yet.

PASS 2 — Mine the artifact.
Read the artifact and pull out only what is stated in it: the system or service involved, the problem it addressed, the constraint or trade-off, the interfaces and consumers it touched, and every number that appears — latency, error rate, request volume, rollout percentage, data size, build time, incident duration. List these as short facts, each with the phrase from the artifact it came from.

PASS 3 — Rewrite.
First tell me which of my bullets this artifact actually covers. Facts from the artifact may enter only those bullets — never a bullet about a different project or a different job. For every bullet the artifact does not cover, rewrite from my own wording alone and tell me which artifact I should paste next for it.
Each rewritten bullet should read: what system, what I changed or decided, what moved as a result. Keep a technology name only where the technology was the decision — "chose Postgres over DynamoDB because the access pattern was relational" earns its place, "used Postgres" does not.
Where a bullet has room for a number that is not in anything I pasted, write [X] in the bullet and add 1 line to a list at the end asking me for it. Keep that list short and specific — the kind of number I could look up in a dashboard, a ticket or a build log rather than reconstruct from memory.

Finish with 3 questions about scope I have not told you: how large the system was, who depended on it, and what would have broken if the work had gone wrong.

Rules — these override everything above:
- Use only the experience I give you. Do not invent employers, job titles, dates, degrees, certifications, skills, or metrics.
- If a number would strengthen a line and I have not given you one, write a placeholder like [X%] or [$X] for me to fill in. Do not estimate it.
- Do not add a tool, skill, or credential I did not list, however standard it is in my field.
- Rewrite, reorder, tighten and re-emphasize what is already there. Where I have given you too little to work with, ask me for it or leave [add detail].

Interview Me About the System I Own

You have owned a service for a year and your resume says "maintained backend services". The scale, the on-call load and the blast radius are all in your head, and none of it is on the page

I am a software engineer and I own a service that my resume describes in 1 flat line. Interview me until the scope of it is on paper.

THE SERVICE:
[DESCRIBE THE SERVICE OR SYSTEM IN 2 OR 3 SENTENCES]

WHAT I HAVE ALREADY WRITTEN ABOUT IT:
[PASTE THE README, ARCHITECTURE NOTE, ON-CALL RUNBOOK, DESIGN DOC, OR POSTMORTEM]

MY CURRENT BULLET:
[PASTE IT, OR WRITE "none"]

Rules for the interview:
- Ask me 1 question at a time and wait for my answer. Do not batch them.
- Read what I pasted first. Never ask me something the document already answers — say what you found there and ask me to confirm or correct it.
- Ask at most 10 questions, drawn from the areas below, in whatever order fits what I have already told you.

Areas to cover:
1. Traffic and scale — requests per second or per day at peak, users or tenants served, size of the data set.
2. Availability — the target I was held to, the worst incident I handled, how long recovery took.
3. On-call — rotation size, how often I was paged, whether I changed that number.
4. Blast radius — what breaks downstream when this service is down, and who notices first.
5. Boundaries — who calls it, what it calls, which team owns the other side of each interface.
6. Change over time — what the system looked like when I took it on and what it looks like now, including migrations, rewrites and things I deleted.
7. People — team size, whether I set the technical direction, who I reviewed or mentored on it.
8. Cost — infrastructure spend, build or deploy time, anything I reduced.

When the interview is done, write 3 to 4 resume bullets from my answers and the document I pasted, and from nothing else. Each one names the system, my part in the decision, and the scale or the outcome. Order them strongest first.
If an answer of mine contradicts the document, stop and ask me which is right rather than picking one.
Where I answered "I don't know", put [X] in the bullet and list that number separately under "Numbers to look up", with a note on where I would find it — a dashboard, a billing console, an incident log.
Finish by telling me which single answer of mine carried the most weight, so I know what to dig for on the next system.

Rules — these override everything above:
- Use only the experience I give you. Do not invent employers, job titles, dates, degrees, certifications, skills, or metrics.
- If a number would strengthen a line and I have not given you one, write a placeholder like [X%] or [$X] for me to fill in. Do not estimate it.
- Do not add a tool, skill, or credential I did not list, however standard it is in my field.
- Rewrite, reorder, tighten and re-emphasize what is already there. Where I have given you too little to work with, ask me for it or leave [add detail].

Gemini: If Gemini sends the whole question list at once instead of interviewing you, reply "ask me 1 question at a time and wait for my answer" — it usually holds for the rest of the session.

Map a Posting to Evidence You Already Have

The posting names more technologies than you have shipped with. You need to know which ones you can back with real work, which to foreground, and which gaps to answer honestly rather than paper over

I am a software engineer applying for the role below. Line up what I have already built against what this team is asking for.

JOB POSTING:
[PASTE THE FULL POSTING]

MY RESUME:
[PASTE YOUR RESUME AS PLAIN TEXT OR MARKDOWN]

PROJECTS NOT ON MY RESUME:
[PASTE ANY NOTES, OR WRITE "none"]

Step 1 — Read the posting as an engineer, not as a keyword list.
Separate what it asks for into:
- The system being built or maintained, in 1 sentence.
- Hard requirements: languages, runtimes, data stores, platforms stated as required.
- Practices: testing, code review, on-call, incident response, design review, whatever the posting names.
- Seniority signals: phrases like "own", "define", "mentor", "across teams" tell you what level of decision they expect.
Quote the posting for each item so I can see where it came from.

Step 2 — Build a table with 4 columns: Requirement | Where it appears in my history | Strength | Notes.
Fill "Where it appears" only from my resume and my project notes, quoting the line. Strength is 1 of: Direct (I shipped it in production), Adjacent (I shipped something close enough that I can speak to it), Absent (nothing I pasted supports it).
Do not soften an Absent into an Adjacent. An honest Absent is the thing I need to prepare for.

Step 3 — Tell me what to move.
Name the 3 bullets already on my resume that map most directly to the hard requirements, and rewrite each to lead with the part this team cares about — same facts, different first 6 words.
Then name any bullet taking up space that this posting gives no credit for.

Step 4 — Handle the gaps.
For each Absent, say whether the posting phrases it as a blocker or a nice-to-have, and give me 1 honest sentence I could use in a screening call: the nearest real thing I have done, and what I would need to pick up. Nothing in that sentence should reach past what I pasted.

End with the terms this posting uses for work my resume already shows under different wording. For each one, put the posting's phrase and my own line side by side so I can decide whether to adopt theirs. Do not list a term unless something I pasted already backs it — a term I cannot defend in the screening call is worse than a missing one.

Rules — these override everything above:
- Use only the experience I give you. Do not invent employers, job titles, dates, degrees, certifications, skills, or metrics.
- If a number would strengthen a line and I have not given you one, write a placeholder like [X%] or [$X] for me to fill in. Do not estimate it.
- Do not add a tool, skill, or credential I did not list, however standard it is in my field.
- Rewrite, reorder, tighten and re-emphasize what is already there. Where I have given you too little to work with, ask me for it or leave [add detail].