How to Write a Technical Résumé Bullet That Actually Proves a Skill
Technical resume bullet points for software engineers work when they claim a skill, name the method, and anchor proof a screener can verify.
Skill Graph Team••7 min read
Most engineering résumé bullets are either chores ("worked on the payments service") or advertisements ("spearheaded a transformative microservices initiative"). Neither proves a skill. One is a job description. The other is a press release.
A technical résumé bullet has a narrower job. In one line, it should make a skill claim, name the method, and leave an evidence anchor a screener can pull on. If a hiring manager cannot ask a precise follow-up from the bullet, the bullet is decoration.
This is not the generic XYZ formula recycled by every university career site. Those formulas were written for campus recruiting in consulting. Engineering hiring is trying to find out whether you have done a real technical thing, under constraints, with artifacts that still exist.
Why technical resume bullet points fail
Three failure modes cover almost every weak file.
Tool soup. "Developed APIs using Python, FastAPI, Docker, AWS, Terraform, and Kubernetes." That is a skills list wearing a verb. It does not say what was hard, what you chose, or what would exist if you had been wrong.
Unanchored metrics. "Improved performance by 40%." Forty percent of what, measured where, by changing what. Generated résumés love this shape because it looks quantitative. Interviewers treat it as a bluff until proven otherwise.
Responsibility without authorship. "Collaborated on migrating the monolith." Collaborated is how you hide whether you wrote the design, moved one endpoint, or merged other people's PRs. Teamwork can be real. The bullet still needs your slice.
Career-centre advice tells you to start with strong verbs. Fine. Verbs are not the scarce resource. Proof is. McKinsey's skills-based hiring research treats demonstrated skills as about five times more predictive of performance than education. They will still read bullets. Then they will test whether the bullets were cosplay. Write as if the take-home already exists.
Ready to map your competitive advantage?
Stop guessing your next move. Visualize your skills, identify gaps, and grow with AI-powered guidance.
The three-layer formula
Use this fill-in, then cut words until it fits one or two lines:
[Skill claim] by [technical method], [constraint or scale if it changes the meaning], [evidence anchor].
Layer
Question it answers
Good
Bad
Skill claim
What capability are you asserting?
"Sharded the events table"
"Worked on backend"
Method
How, technically?
"hash on org_id, dual-write for a week"
"using best practices"
Evidence anchor
How can someone check?
"P95 writes 1.2s → 180ms; migration note + PR"
"significantly improved scalability"
The skill claim should be a capability, not a brand. "Designed a pagination scheme" is a claim. "Used Postgres" is a tool. Tools can appear inside the method layer.
The method should be specific enough that two engineers would not describe it the same way by accident. "Built a REST API" is accidental. "Idempotent POST with an Idempotency-Key stored in Redis for 24h" is not.
The evidence anchor can be public or internal:
PR number or merge request title
Dashboard name plus the metric
Design doc title
Incident or ticket id
Deployed URL or package name
Dataset / eval table in a repo
You do not need a hyperlink in the PDF. You need a retrieval key you can open in a screen share. If you cannot name one, the bullet is not ready. Either find the artifact or downgrade the claim.
Depth belongs in the claim, not as an adjective. "Expert in Kubernetes" is not a bullet. "Wrote the rolling-update runbook after a botched rollout that dropped 12% of traffic" is a depth signal.
Before and after across four role types
Same formula, different domains. Steal the structure, not the facts.
Role
Before
After
SWE
"Developed scalable APIs in Python to enhance user experience."
"Designed keyset pagination for /orders (Postgres (shop_id, id)). P95 1.1s → 160ms on 3M rows (PR #884)."
SWE
"Led migration to microservices on Kubernetes."
"Split billing from the monolith into one ECS service. Dual-wrote invoices for 10 days; zero mismatch vs the old table (cutover doc)."
ML
"Built machine learning models to predict customer churn with 92% accuracy."
"Churn model, walk-forward by cohort week. PR-AUC 0.41 vs 0.28 last-contract baseline; 92% accuracy discarded as majority-class (eval notebook)."
ML
"Implemented MLOps pipelines on AWS."
"Scheduled a weekly SageMaker job from a locked training image. Wrote the data-hash check that blocked a silent schema drift (Airflow DAG + failed run)."
Data
"Created dashboards and insights for leadership."
"Rebuilt revenue in dbt from Stripe events. Late events via 14-day watermark. Finance retired the CSV export (dbt model fct_revenue)."
Data
"Used Python and SQL for data cleaning."
"Deduped 12M event rows with a window on (user_id, event_id); dropped 8% duplicates that had double-counted signups (query in analytics/qa)."
Robotics
"Worked on ROS2 navigation for autonomous robots."
"Wrote a ROS2 lifecycle node that gated Nav2 until IMU covariance dropped below threshold. Cut false starts in the lab from frequent to rare (bag + node)."
Robotics
"Used C++ and Python for robot software."
"Ported the joint interpolation loop from Python to C++. Cycle time 12ms → 1.4ms on the real controller (bench log)."
A few more rewrites in prose, because tables hide the cuts.
Product engineering. Before: "Collaborated cross-functionally to ship a notifications platform." After: "Shipped notifications via an outbox table and a worker. Idempotent on (user_id, template, ref). QA: killed the worker mid-send; no double email (flag notif_v2)."
Platform. Before: "Improved CI/CD and developer productivity." After: "Moved image builds to a remote cache. p50 CI 14m → 6m on the API repo. Breakages now fail on hadolint instead of on deploy (pipeline file)."
ML eval. Before: "Fine-tuned an LLM to improve customer support." After: "LoRA on 3k labelled tickets. Offline: +11 recall@3 vs keyword search on a frozen 400-ticket set. Did not ship; latency 2.1s on CPU (eval sheet)."
That last one is a successful bullet about a project that did not ship. Evidence includes the decision to stop. Hiring teams trust restraint more than fake production claims.
If you want the longer extraction process behind these lines, use the project-to-skill-claim framework. The bullet is the compression. Do not invent the metric in the compression step.
Evidence anchors that survive a screen
Anchors fail when they are theatrical. "Available upon request" is not an anchor. A GitHub org the interviewer cannot see, with no named PR, is only slightly better.
Use the smallest unique name:
PR #884 in shop-api
fct_revenue in the dbt project
Nav2 gate node imu_ready
On-call doc "checkout-sqs-2025-11"
Then keep a local index that maps those names to URLs. In the interview, you open the artifact. You do not recite the bullet.
Two rules keep you out of trouble:
If the work is private, describe the artifact type, not the secret. "Migration note in the billing repo" is enough. Do not paste customer data. Do not invent a public mirror that does not exist.
If several bullets share one repo, vary the skill, not the URL. Three lines that all say "see my GitHub" prove one skill: you have a GitHub.
Generated bullets fail these rules because the model has no index. It will happily cite "PR #123" that does not exist. Only write anchors you can open in thirty seconds.
A template you can fill in tonight
Copy this block for each role on the résumé. Fill four rows, then keep the best three.
Role: _______________
Skill you can defend: _______________
Method (specific): _______________
Constraint (size, SLOs, hardware, team): _______________
Evidence name: _______________
One-line bullet:
[claim] by [method] under [constraint], [evidence].
Edit passes, in order:
Delete every tool that is not required to understand the method.
Replace "improved," "leveraged," and "utilized."
Confirm the metric has a before and after, or delete the metric.
Confirm you can open the evidence in a screen share.
Read it aloud. If you need a second sentence to explain the first, the claim is too big. Split or narrow.
Do not chase twenty-five decorative variants. Eight honest bullets beat a page of clones. A personal skill graph helps because each node already stores the method and the artifact. The résumé becomes a query over that graph for one job, not a fresh writing project every time a posting appears. See also what a skill graph is if the data model is still fuzzy.
Write the next bullet from a real PR, not from a prompt. Open the diff. Name the skill. Name the method. Name the file. If those three are true, the line will sound like an engineer wrote it, because one did. If the artifacts already live as nodes, export the bullets from that inventory instead of drafting them from a blank page.
