The specific signals an experienced software engineer hiring panel grades on during the eight-second scan.

• Summary names a system, not a personality

  'Backend engineer owning the merchant-settlement service' beats 'passionate software engineer' every time.

• Engineering numbers — p99, throughput, error rate, MTTR

  Latency in ms, requests per day, test coverage percentages. The units a hiring panel speaks.

• Stack named inline (Go, PostgreSQL, Kubernetes)

  Standalone tokens parse cleanly as ATS keywords and let the panel grade depth at a glance.

• One non-trivial OSS contribution or side project — if it exists

  Merged PR to a recognized library or a side project with real users. Don't fabricate; don't list tutorial projects.

• Education condensed to a single line (mid+ levels)

  School, degree, year. Anything more is decoration the hiring panel skips.

• No soft-skills section

  'Communication, problem solving, teamwork' is filler — the experience bullets should already demonstrate them.

1. 1

   Open with the system and the surface area

   A staff engineer summary names the system: 'Owns the inference request router on a 40M-req/day API.' A senior engineer summary names the surface: 'Backend engineer on the bank-rails team at a payments company, owns the SEPA integration.' A mid-engineer summary names the service: 'Backend engineer at a fintech company, ships through the on-call rotation on the merchant-settlement service.' An entry-level summary names a project: 'Recent CS graduate; shipped a metrics-aggregation pipeline as an intern that cut p99 query latency by 90%.'

   The pattern is consistent: the noun matters more than the adjective. A hiring panel reading the first sentence of your summary is asking 'what did this person actually work on,' not 'what kind of person are they.' Lead with what.

   Avoid the temptation to lead with traits. 'Passionate software engineer with strong analytical skills and a love of clean code' is what every other resume opens with. It's literally the LLM-default summary for the role, and hiring panels have started filtering it out as low-signal. The summary that gets read is the one that names a specific system or project a panel can ask follow-up questions about during the phone screen.

2. 2

   Quantify with engineering numbers

   Latency, throughput, error rate, test coverage, MTTR, p99, deploy frequency, lines-of-code-deleted — these are the units a hiring panel speaks. 'Reduced p99 from 1.2s to 180ms on a 40M-req/day API' is read; 'Significantly improved performance' is skipped. The denominator matters: '50% latency reduction' could mean trimming an idle process by 5ms; '50% latency reduction on a 40M-req/day API with paying customers' is meaningful engineering work.

   The specific numbers to favor: • Latency: name p50, p95, p99 explicitly (panels read p99 as the harder constraint). • Throughput: requests/sec or events/day with both before and after. • Reliability: error rate or MTTR before/after. • Test coverage: percentage or absolute counts of flaky tests fixed. • Migration: count of services migrated and the resulting latency or reliability change. • Code review or mentorship: count of engineers you mentored through a promotion cycle.

   If you don't have the exact baseline, estimate with language that signals you're estimating: 'roughly halved,' 'order of magnitude better,' 'from minutes to seconds.' Hiring panels respect honest estimation and distrust suspicious precision.

3. 3

   Name the stack inline, not in a wall of tags

   A tech-stack chip row at the end of each role description is fine — many engineer resumes use this convention and hiring managers expect it. A separate 'Skills' section listing twenty languages and forty tools is a red flag: it tells a hiring panel the candidate has touched many things and committed to none.

   The pattern that works: name the language or tool inside the bullet where you used it, then list a compact chip row of three to six items at the bottom of each role. The bullet provides context ('Built a Go service backed by PostgreSQL'), the chip row provides the parseable list. Together they give a hiring manager an immediate read on the candidate's stack across their last three roles.

   For your Skills section at the bottom of the resume, list 15-25 items weighted toward depth in your target stack. Group them lightly: 'Languages: Go, Rust, TypeScript, Python' / 'Infrastructure: PostgreSQL, Kafka, Kubernetes, AWS' / 'Practices: gRPC, OpenTelemetry, on-call leadership.' Group labels are optional but they parse well and read well.

   Do not list languages you have not shipped in for at least three months of production work. Listing a language you briefly touched in college will read as inexperience to a hiring panel at a sophisticated company — they would rather see four languages you're fluent in than ten you've sampled.

4. 4

   Include one OSS or side-project line — if it exists

   A merged PR to a well-known open-source library, a published open-source tool with real users, or a side project with non-trivial adoption is the single highest-signal item on an engineer's resume. Hiring panels disproportionately weight these items because they prove the candidate writes for an audience beyond their day job — which is the trait most engineering managers screen for at the senior and staff levels.

   The items that count: • Merged PRs to libraries with 1k+ stars (named project, named PR, brief description). • A solo open-source project with 100+ stars and at least one external contributor. • A side project with 1k+ active users or demonstrable usage data. • A meaningful conference talk at a recognized venue (PyCon, KubeCon, GopherCon, JSConf, etc.). • Publications in named venues (LWN, Increment, ACM Queue, your own widely-read engineering blog).

   What doesn't count: tutorial projects, landing-page clones, half-finished side projects, contributions to your own throwaway repos. Filler in this section weakens the rest of the page by association.

   If you don't have any of these yet, leave the section out entirely. A resume without an open-source line is normal; a resume with a thin open-source line is a red flag. The exception is for entry-level candidates — a side project with real users (your university course-planner used by 4,200 students, for example) is the highest-leverage thing you can put on the page.

5. 5

   Cut the soft-skills section

   Communication, collaboration, leadership, problem-solving, attention to detail — every candidate writes these. Hiring panels read them as filler. The bullets in your experience section should already demonstrate them; the skills section should be technical.

   What to cut from a typical engineering resume: • 'Strong communication skills' (replace with a bullet that names a specific incident retro you led or a runbook you authored). • 'Team player' (replace with a bullet naming the cross-functional partner team and what you produced together). • 'Detail-oriented' (replace with a metric — flaky tests reduced, code review comments resolved, incident MTTR improvement). • 'Self-motivated, fast learner' (replace with an open-source contribution or side project). • 'Passionate about clean code' (replace with a refactoring outcome — lines deleted, test coverage delta, latency improvement).

   The rule of thumb: if a sentence on your resume could appear unchanged on any other candidate's resume, it's filler. Cut it. Replace it with a sentence that's only true of you.

   The exception is languages spoken (not programming languages — natural languages). Naming Spanish or Mandarin proficiency at the bottom of the resume is useful for roles at multinationals and for distributed teams. List proficiency explicitly: 'Spanish (full professional)' not 'Spanish (some).'

Each follows the [verb] [object] [number] structure hiring managers grade against. Copy them as a starting point, swap in your own numbers, and read the annotation to understand why each one works.

• Performance

  Cut p99 latency on the settlement API from 480ms to 90ms by introducing a Redis-backed batched cache for the merchant-account lookup hot path.

  Why it works: Names p99 explicitly (not just 'latency'), gives the absolute before/after numbers, and explains the specific technical intervention. The 'hot path' detail signals familiarity with profiling — a senior-level read on a mid-level resume. The cache choice (Redis-backed batched) is concrete enough that an interviewer can ask three follow-up questions.

• Reliability

  Re-architected the settlement reconciliation pipeline (Go, PostgreSQL, idempotent event sourcing); reduced merchant-facing reconciliation errors by 84% across a 12M-event/day workload.

  Why it works: Pairs the stack name (Go + PostgreSQL + event sourcing) with the workload scale (12M events/day) and the outcome (84% error reduction). The 'idempotent event sourcing' detail signals understanding of distributed-systems patterns at the level expected for a senior backend role — credibly readable on a mid-level resume.

• Shipping

  Owned the SEPA Instant integration that's now used by 4,800 European merchants; processed €2.3B in volume in the first nine months post-launch.

  Why it works: Ownership signal ('owned'), real-world adoption metric (4,800 merchants), and a volume figure (€2.3B) that proves the work shipped to a meaningful scale. SEPA is a recognized ATS keyword for payments roles in Europe. The post-launch timeframe shows the candidate has longitudinal data on the system, which is a senior trait.

• Platform

  Designed and shipped the company's first gRPC service-to-service contract layer (protobuf + buf); migrated 6 internal services off REST, shaving 35% off inter-service latency.

  Why it works: Two distinct contributions stacked: building the contract layer (platform work) and the migration of six services (rollout work). The latency outcome ties platform work to a business-facing metric. Naming buf specifically signals current-vintage tooling — a candidate familiar with modern protobuf ergonomics, not just the language.

• Testing

  Reduced flaky integration tests on the bank-rails service from 12% to under 1.5% by introducing deterministic time and a contract-test framework.

  Why it works: Testing improvements are hard to quantify; this bullet does it cleanly with a before/after on flakiness rate. The 'deterministic time' detail is a tell — engineers familiar with that pattern recognize it as the right fix, and engineers unfamiliar with it Google the term and treat it as a credibility signal. This is the kind of bullet that gets a hiring panel to push the resume forward.

• On-call

  Authored the on-call runbook adopted as the template for three sister services; new on-call hires now ramp to primary in two weeks instead of six.

  Why it works: Documentation work is undervalued on most engineer resumes; this bullet shows why it's load-bearing. The runbook generalized (three sister services adopted it), and the impact is measurable (ramp time cut by 67%). The on-call topic also signals production-engineering responsibility — a senior-leaning trait.

• On-call

  Closed 14 incident retros as the IC lead over six on-call rotations; mean-time-to-mitigation on bank-rails incidents fell from 47 to 14 minutes.

  Why it works: Counts of retros (14) and rotations (6) prove the on-call work was sustained. The MTTM metric is the production-engineering KPI hiring panels recognize. Reading this bullet, a hiring manager can ask three interview questions immediately: which incidents, what category, what was the longest-tail one.

• Mentorship

  Mentored two junior engineers through their L3-to-L4 promotion cycles; both promoted on first eligibility.

  Why it works: Mentorship is a senior-level signal — most mid-level engineer resumes can't claim it credibly. 'Both promoted on first eligibility' is the differentiator: it proves the mentorship had a measurable outcome rather than being asserted. Levels (L3, L4) are recognized across the industry; the bullet parses cleanly regardless of which company the reader works at.

• Internship

  Built a metrics-aggregation pipeline for the DNS team that cut p99 query time on weekly rollups from 4s to 380ms (intern project, shipped to prod).

  Why it works: Two parenthetical details make this internship bullet read as production work rather than coursework: the magnitude of the latency improvement (10×) and the explicit 'shipped to prod' tag. For an entry-level candidate, this is the single most important bullet on the resume — it proves they can ship in a real engineering environment.

• Open Source

  Merged two PRs into the official OpenTelemetry Go auto-instrumentation library — one closed a context-propagation bug under high concurrency.

  Why it works: Named project (OpenTelemetry), specific contribution count (two), and a description of one PR that signals depth ('context-propagation bug under high concurrency' is a technically meaty description). This is the high-signal item a hiring panel will single out when forwarding the resume. OpenTelemetry is also widely recognized across the industry.

• Side Projects

  Shipped pg-shadow, a logical-replication shadow-traffic tool for Postgres migration testing — 380 GitHub stars, used internally by two fintech companies.

  Why it works: Side projects that show production-engineering thinking (replication, migration testing) read at a much higher level than personal portfolios. The adoption metric (two fintech companies using it internally) is the differentiator — most side projects don't generate that kind of pull. Star count is a secondary signal that gives the reader a quick read on community traction.

• Architecture

  Migrated the merchant-onboarding service from synchronous REST to event-driven Kafka topics; reduced merchant-side onboarding latency p95 from 6.4s to 1.1s.

  Why it works: Architecture migration is hard work to demonstrate on a resume; this bullet does it by naming the before/after pattern (REST → event-driven Kafka), the surface area (merchant-onboarding service), and the user-facing outcome (p95 latency). The user-facing metric is what differentiates this from infrastructure work — it ties architecture to merchant experience.

Same intent, two phrasings. Read why the right column lands on the keep-pile and the wrong column doesn't.

Patterns our writers see most often when reviewing software engineer resumes — each one disqualifies candidates faster than weak experience does.

• Mistake

  Opening with adjectives instead of a system. 'Passionate software engineer with strong analytical skills and a love of clean code.'

  Fix

  Lead with the system you worked on. 'Backend engineer at a fintech company, owns the merchant-settlement service. Four years of production experience in Go and PostgreSQL.' Two sentences, twenty words, and the hiring panel knows what to ask about during the phone screen.

• Mistake

  Listing every language you've ever touched. 'Languages: Python, Java, JavaScript, TypeScript, C++, C#, Ruby, Go, Rust, Kotlin, Swift, R, MATLAB, Haskell, Elixir.'

  Fix

  Four to six languages you've shipped in for production work, in the last five years. If you used a language in one college course six years ago, leave it out. Hiring panels read long language lists as inexperience, not breadth.

• Mistake

  Bullets that describe responsibilities instead of work. 'Responsible for maintaining backend services.'

  Fix

  Replace with a specific intervention and outcome. 'Cut p99 latency on the settlement API from 480ms to 90ms by introducing a Redis-backed batched cache on the merchant-lookup hot path.' Responsibilities are claims; interventions with outcomes are evidence.

• Mistake

  A graphic-heavy designed PDF with skill bars, icons, and color-coded sections.

  Fix

  Single-column, Source Sans or Inter font, no graphics, no skill bars, no icons except company logos (and only if they parse cleanly). Engineering recruiters expect this layout; deviation reads as the candidate prioritizing design over content.

• Mistake

  A long 'Education' block listing relevant coursework, GPA, projects, and honors at a senior level.

  Fix

  For mid- and senior-level engineers, education is a single line: school, degree, year. For entry-level candidates, you can include GPA (if 3.5+) and one or two highlights, but trim aggressively past that. Hiring panels at senior levels weight education at roughly 5% of the overall read.

• Mistake

  Vague open-source claims. 'Contributed to various open-source projects.'

  Fix

  Name the project, name the contribution, link the PR or repo. 'Two merged PRs to opentelemetry-go-instrumentation (one closing a context-propagation bug under high concurrency).' Vague open-source claims read as resume padding.

• Mistake

  Two-page resume with fewer than 8 years of experience.

  Fix

  One page. Engineering hiring panels rarely open page two unless page one earned the read. Cut the internship paragraph to one line, trim education to a single row, and let your most recent two roles breathe with three to five bullets each.

• Mistake

  Hidden white-text keywords stuffed into the bottom of the page.

  Fix

  Don't. Every modern ATS flags it. Greenhouse explicitly surfaces it to recruiters as an integrity issue. Stripe, Google, Cloudflare, and the FAANG tier will disqualify you outright if caught. Honest keyword density (name what you actually shipped, where you shipped it) is the only strategy that compounds.

Strong verbs lead strong bullets. Replace generic openers (worked on, helped with, was responsible for) with the specific verb that matches what you actually did.

ATS pipelines weight your Skills section as a structured list. Include 15-25 of the items below if they match your experience — not soft skills.