A mid-level backend engineer at a growth-stage company typically starts the day triaging alerts that fired overnight — scanning Datadog traces or a Grafana SLO dashboard for the service they own. Standup covers incidents, in-flight work, and capacity planning for the next peak. Mornings are the deepest block: writing or reviewing Go/Python/Java service code, designing a new API contract, or debugging a slow PostgreSQL query via EXPLAIN ANALYZE. Code review is continuous — backend PRs routinely touch database migrations, which demand extra care for online-safe rollouts. Afternoons mix design reviews (a new event schema proposed by another team, a migration plan from RabbitMQ to Kafka), a pairing session with a junior on idempotency for a payment endpoint, and a capacity-planning conversation with SRE about CPU headroom before launch. Senior backend engineers spend more time in contract review and SLO ownership across services they don't write code for. Staff+ backend engineers operate on quarters and years — migrations, data-platform direction, reliability strategy — not per-PR feedback.

No observability story on the resume

Backend engineers who ship code but can't debug production are a liability. If your resume says nothing about SLIs/SLOs, on-call, distributed tracing, or post-mortems, hiring managers assume you've never owned a running service. The Google SRE book's principle that 'hope is not a strategy' is now canonical vocabulary in senior interviews. Resume signal: at least one bullet referencing observability, incident response, or a concrete reliability metric (uptime, MTTD, MTTR, error-rate delta).

Missing idempotency and retry semantics

Writing 'built APIs' without any mention of idempotency keys, exactly-once semantics, or retry behavior is a red flag at mid-level and above. A widely-documented production failure mode is the 'phantom write' — a retry after a timeout double-charges a user because the server has no memory of the original request. Resume signal: at least one bullet that acknowledges retry safety, duplicate detection, exactly-once processing, or at-least-once delivery handling — especially for anything touching payments, inventory, or messaging.

Chatty or wrongly-drawn service boundaries

The single most expensive microservices mistake is getting the boundary wrong. Sam Newman's canonical warning: 'Getting service boundaries wrong can result in having to make lots of changes in service-to-service collaboration — an expensive operation.' Resumes that say 'split monolith into 15 microservices' without mentioning bounded contexts, data ownership, or the problem the split actually solved read as cargo-cult decomposition. Frame the decomposition around the business problem it solved (team autonomy, deploy independence, scaling an isolated hot path), not the service count.

Optimizing P50, ignoring P99

Senior backend readers specifically scan for tail-latency awareness. 'Reduced average latency by 40%' reads as junior work; 'Cut p99 from 1.8s to 320ms' reads as senior. Averages hide the worst user experiences, and SLOs live at the percentile, not the mean. Wherever you quote a latency number, quote it at p95 or p99 — and if you improved a system, be explicit about which percentile moved. This is one of the fastest signals hiring managers use to separate backend engineers who've run production from those who've only built features.

Shallow distributed-systems vocabulary

Bullets about microservices or cross-service work that never mention sagas, outbox pattern, eventual consistency, transaction isolation levels, or consensus read as buzzword-first and mechanism-second. Kleppmann's Designing Data-Intensive Applications is the canonical reference — at senior level, hiring managers expect you to articulate why you chose at-least-once over exactly-once, or read-committed over serializable, in at least one bullet. Resume signal: at least one concrete mechanism (not just a product name) in your top two backend roles.

1Framework dump without fundamentals

Listing 'Django, Flask, FastAPI, Express, Spring Boot, Gin, Fiber' tells a senior reader you haven't decided what to be deep on. Hiring managers care more about your grasp of transaction isolation, indexing, and consensus than which HTTP framework you reach for. Pick one primary language + framework at real depth and show the depth in your bullets.

2No reliability or uptime metrics

Backend systems are judged by their reliability. A resume with zero mention of SLOs, uptime, error rates, MTTD, MTTR, or on-call signals that you've built features but never operated them. Even directionally honest numbers ('99.9% uptime', 'two sev-2s in 12 months') land better than silence.

3Averages instead of percentiles

Writing 'reduced average latency by 40%' is a tell: it's the number that averages hide. Senior backend readers want p95 or p99 — percentiles are where SLOs live, and they're where users feel the pain. If you improved a system, know which percentile moved and name it explicitly.

4Omitting data modeling decisions

Schema design is core backend work that resumes routinely skip. Name concrete decisions — normalization vs denormalization trade-offs, partition keys, online-migration approach, isolation level chosen — to show you think beyond query-writing to the shape of the data layer itself.

5Microservices without a reason

'Split monolith into 15 microservices' reads as cargo culting unless you name the problem it solved (team autonomy, deploy independence, isolating a scaling hot path) and how you drew boundaries (bounded contexts, data ownership). Service count alone isn't an achievement — the decomposition reasoning is.

6Ignoring idempotency and retry safety

Any mention of payments, messaging, inventory, or webhooks with no mention of idempotency keys, exactly-once semantics, or retry handling is a red flag. The 'phantom write' class of production bugs — double-charging on retry after a timeout — is one of the most cited backend failure modes. Show you've thought about it.

7ATS-hostile formatting

Two-column layouts, tables, icons, embedded images, and header/footer-only contact info break ATS parsers. Stick to a single-column, standard-section-heading resume (Experience, Education, Skills, Projects) exported from a word processor. Keep creativity for your portfolio site — the resume is a parser artifact first and a design artifact second.