In this guide
Role-specific resume and interview guides
Software engineer resume: describing projects and technical impact
How engineers can describe systems, their own contribution, technical decisions and results on a resume, with rewritten bullets and a project pattern.
What engineering reviewers read for
Technical reviewers skim a resume for signals they can probe in interview: the size and nature of the systems you worked on, whether you designed things or only implemented tickets, how you dealt with failure, and whether your claims about a stack hold up. A bullet that names a framework but not a problem tells them very little.
| Element | Question it answers | Example wording |
|---|---|---|
| Context | What system, for whom, at what scale? | Payments API handling card checkouts for a subscription product |
| Your part | What did you personally own? | Designed and implemented the retry and idempotency layer |
| Decision | What trade-off did you make? | Chose idempotency keys over distributed locks to keep latency low |
| Result | What changed? | Duplicate charges stopped; on-call pages for the service fell sharply |
| Proof | Where can someone check? | Design doc summary, public repository or talk, where allowed |
Rewritten engineering bullets
Illustrative example
Backend engineer
Before
Worked on the payments service using Node.js.
After
Designed the retry and idempotency layer for the payments API in Node.js and PostgreSQL, ending duplicate charges after network timeouts and removing the most frequent on-call alert.
Illustrative example
Frontend engineer
Before
Built React components.
After
Rebuilt the checkout form in React with keyboard and screen-reader support, added component tests, and cut form-related support tickets after release.
Illustrative example
Career changer with a personal project
Before
Made a budgeting app.
After
Built a budgeting web app (TypeScript, Next.js, SQLite) with authenticated accounts, CSV import and 85 unit tests; deployed it publicly and documented the data model in the repository readme.
A personal project is real evidence when it shows decisions, tests and deployment rather than a tutorial copied line by line.
Team work without overclaiming
Most production software is built by teams, and reviewers know it. Avoid 'built the platform' when you built one part of it. Name your slice precisely: the migration you led, the service you owned, the incident you investigated, the reviews you gave. Interviewers frequently ask 'what exactly did you do?', and a precise bullet makes that question easy.
Listing languages and tools honestly
Group skills by how well you know them, or show them in context only. A common, honest pattern is a short line of production experience followed by a line of familiarity. Ten languages listed with equal weight reads as padding and invites questions you cannot answer.
Illustrative example
A skills line that separates depth from familiarity
- Production: TypeScript, Node.js, PostgreSQL, AWS (Lambda, SQS), Terraform
- Familiar: Go, Python, Kubernetes
Links that help rather than hurt
Check every link before you send
- The repository has a readme explaining what it does and how to run it.
- Tests exist and pass, or the readme says why they do not.
- There is no secret, key or employer code in the history.
- Pinned projects are the ones that support this application.
- Contributions to other projects link to merged pull requests, not just a profile.
Common questions
Do I need a GitHub profile to get a software engineering job?
No. Many engineers' best work is private. Describe it well, and use a small public project or write-up only when it strengthens your application.
Should I include bootcamp or tutorial projects?
Include them if you extended them with your own decisions, tests or deployment, and say what you added. Unchanged tutorial code is weak evidence.
Put it into practice
See how Luceria helps with thisDrafted with AI assistance and checked against Luceria’s editorial standards. Examples are illustrative, not real people’s results. Spotted something out of date? Tell us.