Resume for a Software Engineer

What employers look for

The first screen is almost mechanical. A recruiter checks whether the resume names the primary language, the main framework, the database and the cloud or infrastructure tools listed under requirements. Write them the way the posting does: TypeScript rather than JS/TS, PostgreSQL rather than 'SQL databases' if PostgreSQL is what they asked for. The second screen belongs to the hiring manager, who reads for scope. Did you own a service or fix tickets inside one? How many requests, records or users did the system handle? Was there an on-call rotation, and were you in it?

Interviews then check what the resume claimed. Expect questions on a design decision you made and the trade-off behind it, on how you test (unit, integration, contract, load), on what you look for when reviewing a pull request, and on a production incident you handled. Bullets that already describe those situations make the interview a confirmation rather than a cross-examination. The soft skills that get probed are written communication in design docs, working with product and design partners, and how you estimate.

Languages and frameworks (as named in the posting)

Put the exact names from the posting in a skills line near the top, then prove depth by using each one inside a bullet. A language that appears only in the skills list reads as exposure, not competence.

System design

Describe one system you designed or redesigned: the components, the data store, why you chose them, and what changed in throughput or cost. One concrete design beats a list of architecture terms.

Scalability and performance

Give the before and after: requests per second, p95 latency, batch runtime. State the scale the system actually ran at so the reader can judge whether it resembles theirs.

Code review

Mention review responsibility directly: reviewed pull requests for a team of six, wrote the team's review checklist, or added a lint rule that removed a class of bugs. Managers want to see that you read other people's code carefully.

Testing and CI/CD

Name the test layers you maintained and the pipeline you worked in. 'Raised unit coverage on the billing service from 41 to 78 percent' tells a story; 'experienced with testing' does not.

Cloud and infrastructure

Name the services and tools the posting names (containers, Kubernetes, infrastructure as code, a managed queue) and attach each to a bullet where you deployed, migrated or operated something with it.

Reliability and on-call

Availability, incident count, time to recovery and a short line on on-call participation show that you have owned software after it shipped, which is most of a working engineer's week.

Cross-functional collaboration

Reference design docs you wrote, product partners you scoped work with, or a migration you coordinated across teams. Interviewers ask about this, and a bullet gives you a prepared example.

Sample summary and bullets

Projects, open source and side work

Projects matter most when you have under three years of experience or when you are changing stacks. Put them in a short Projects section after Experience, two or three entries, each with a one-line description, the stack, and a link to the repository. Write the entry like a job bullet: what it does, what you built, and any measurable use (installs, stars, users or requests). A repository with a clear README and a real commit history does more than any adjective.

Open source contributions go in the same section. Name the project, the kind of contribution (bug fix, feature, documentation, maintainer) and whether it was merged. Do not inflate a typo fix into 'core contributor'. For employer code you cannot share, describe the problem and the design and say the code is proprietary; hiring managers understand that.

• Lead with the project that matches the posting's stack, even if it is the smaller one.
• State what you personally wrote when the project had collaborators.
• Remove tutorial clones and course assignments once you have anything original.
• Keep links short and working; a dead link is noticed.

Numbers that belong on an engineering resume

Engineering impact is measurable, which is why vague bullets stand out. The four categories worth tracking are latency and throughput, cost, reliability, and users or volume. For each system you touched, write down a before, an after and the time window. If you never measured, give the scale instead: records processed, services maintained, size of the team whose code you reviewed.

Sample figures that read as credible for a mid-level engineer: p99 latency from 1.2 seconds to 400 ms; monthly infrastructure cost down $4,000; incidents per quarter from nine to two; a feature used by 300,000 monthly active users. Rounded numbers are fine. Numbers you cannot explain in an interview are not; every figure on the page should come with a two-minute story behind it.

Tailor it to the posting

Every engineering posting is a slightly different stack at a slightly different level, and the resume should move with it. Start from the Requirements section, not the company blurb. Pull every technology, practice and scale word out of it (the language, the framework, the datastore, the cloud, 'microservices', 'high availability', 'mentoring') and check whether each one appears on your page one in the same spelling. The ones that do not, and that you can honestly claim, need a bullet. The ones you cannot claim, leave out; an interview will find the gap.

ClearHire drafts against the posting you have selected, using only what is in your own documents, and you edit the result before using it. Treat its draft as a first pass against the posting's wording and check every number yourself.

1. Copy the posting's required technologies into a skills line at the top, spelled exactly as the posting spells them, and drop tools it does not mention.
2. Rewrite the summary for the role's level: a senior posting wants ownership and design decisions, a mid-level posting wants shipped features and reliability.
3. Move the two or three bullets that match the posting's core responsibility into the first job entry, above everything else.
4. Compress work in unrelated stacks to one line each so the page stays focused and fits on two pages at most.
5. Add a projects entry if the posting's stack is one you have used only outside work, and link the repository.
6. Read the finished page against the posting once more and remove any claim you could not defend in a system design or code review conversation.