How to Get a Backend Developer Job in 2026-27

What "backend developer" means on a 2026 posting, and the four jobs hiding behind the title

The title covers at least four different jobs with different interviews. Read the verbs and the nouns in the posting before you spend an evening on the application, because the loop you get depends on which one it is.

Product backend: endpoints behind a web or mobile app, a relational database, moderate traffic, a lot of business rules. The interview is API design, schema design, and SQL. Platform or infrastructure backend: internal services, libraries, deploy tooling, multi-tenant control planes. The interview leans distributed systems, failure modes and operational judgment, and these roles increasingly overlap with platform engineering. Data-intensive backend: ingestion, pipelines, large tables, analytics-adjacent serving. The interview tests query plans, partitioning and throughput rather than request/response design. Latency-sensitive backend: payments, trading, adtech, telecom, real-time. The interview tests concurrency, tail latency, and exactly what happens on a timeout.

Two useful signals in any backend posting. First, on-call: if it names a rotation, the job includes operating what you build and the behavioural round will ask for an incident story. If on-call is absent and the posting talks only about "delivering features to spec", it is often a ticket-queue or outsourced-delivery role, which is honest work but will not grow your design scope. Second, the datastore list: one relational database means a product backend; Postgres plus Kafka plus Redis plus a warehouse means real distributed work; a list of nine technologies with no verbs attached means the posting was assembled by someone who does not do the job.

Title inflation is worse than it was. "Senior backend engineer" at a 15-person startup can mean three years of experience; at a large employer it usually means five to eight plus demonstrated ownership of a system other teams depend on. Judge the level by the scope described, not the adjective, and ask in the first call what systems the role owns.

• Owns a service, on-call rotation, SLO, error budget: you will operate what you build, and the loop will test that.
• Zero-downtime migration, backfill, multi-tenant: expect a real data round, not a toy SQL question.
• p99, QPS, throughput, backpressure: a latency-sensitive team; prepare concurrency and timeout behaviour.
• Kafka, SQS, Pub/Sub, outbox, event-driven: expect at-least-once delivery and idempotency questions.
• Monolith, legacy, strangler, modernisation: honest and often good work, but ask what fraction of the year is migration.
• LLM, inference, RAG, vector, embeddings, streaming: AI-serving backend work; see the AI section below.
• SOC 2, HIPAA, PCI, tenant isolation: expect an authorisation and audit-logging line of questioning.

How you actually become a backend developer, and the honest state of entry level

Nothing credentials this role. You become a backend developer by running a service that other people hit, and then being able to explain every decision inside it. Entry level is hard in 2026 for a reason worth stating precisely: the tasks juniors used to be hired for (wiring a CRUD endpoint, writing the DTOs, translating a spec into a handler) are the exact tasks an assistant now does in a minute under a senior engineer's review. Be careful about the single-cause story, though. Hiring also slowed for ordinary financial reasons after 2022, and the two effects are tangled. What is observable is that fewer postings are aimed at people with no production experience, and that the ones that exist attract heavy competition.

That makes two routes much stronger than the open-market application. The first is an internal move. Frontend developers, QA engineers, support engineers, data analysts and sysadmins move into backend roles constantly, because the hiring manager already trusts them. If you are inside any company that has a backend team, volunteer for the unglamorous backend tickets: a flaky integration, a slow query, a missing admin endpoint, a noisy alert. Three of those and you have a case to make. The second is a referral into a team small enough to interview you as a person rather than as a pipeline stage.

If you must go in cold, what gets replies is a service with users, however few, that you operate. Not a repository: a running thing. A webhook relay, a small API with authentication and rate limiting, a Discord or Slack integration a community actually uses, a scraper plus API that someone else's app consumes. It needs a real database with more than toy data in it, migrations applied in sequence, structured logs, metrics you can show, and a README documenting the API contract and one decision you reversed and why.

Open source is the other high-leverage move, and backend is one of the places it still works, because the projects are infrastructural: database drivers, ORMs, web frameworks, queue clients, observability libraries. Fixing a real bug in a library your target employers use is a stronger signal than any certificate, and it gives you a reviewer who knows your name.

Bootcamps still place people. Judge a specific one on what it will tell you: ask for its outcomes reporting (the CIRR standard exists for exactly this), the employers it has actually placed with in the last year, and whether placement comes through partnerships or the open market. Separately, know that the generic bootcamp artefact, a REST API for a to-do app deployed to a free tier, is instantly recognisable and reads as nothing. Keep the bootcamp on the resume as education and let an operated service carry the evidence.

A computer science degree helps for a specific reason worth knowing: large employers screen for it at entry level in high-volume graduate pipelines, and some visa and graduate-programme routes require it. After roughly three years of experience it stops mattering almost everywhere.

The practical implication if you are early: optimise for getting inside any engineering organisation, including contract, internal tools, and the companies nobody writes blog posts about. Enterprise shops in insurance, healthcare claims, logistics, utilities and government contracting hire steadily, interview sanely and pay reasonably, and that is where a large share of backend work actually happens. If you are weighing backend against frontend or full stack, do not take anyone's word on which has more openings: search your own market for all three titles on two job boards and count the results, because the answer differs by city and by industry.

The loop, stage by stage, and what each round is really grading

Backend loops vary more than frontend loops because the work varies more. Ask the recruiter for the exact rounds in writing. A good recruiter will tell you the round names, the duration, whether you will use your own machine and editor, and whether an AI assistant is permitted. If they refuse to say what the technical screen is, that is itself information about the organisation.

The timed online assessment has not disappeared, especially at large employers and in high-volume pipelines, and it is still mostly data structures and algorithms with hidden test cases. Treat it as a scheduled exam: real keyboard, stable connection, read all problems first, get a brute-force solution passing before optimising, and cover empty, single and maximum inputs, because the hidden tests are mostly edge cases.

The backend-specific alternative, now common at mid-size companies, is a repository take-home: here is a service that half works, add an endpoint, fix a bug, write the tests. These are graded on things candidates do not expect: whether you handled the error paths, whether your endpoint is idempotent, whether you wrote a migration or edited the schema by hand, whether your tests would catch a regression, and whether your commits are legible. Budget the time they state and stop when it is up, then write a short NOTES.md saying what you assumed, what you deliberately left out, and what you would do with another day. That file is often read before the code.

The live coding round for backend roles is increasingly implementation with a correctness trap rather than an algorithm puzzle: build a paginated list endpoint, write a rate limiter, make a handler idempotent, parse and validate a payload, process a batch with partial failures. Narrate the invariant you are protecting. Interviewers are listening for whether you notice the concurrent case without being told.

The database round is where otherwise strong candidates fall over, because people who use an ORM every day can go years without reading a query plan. Prepare it specifically; the next section is the syllabus.

Two newer rounds are worth preparing. The code-review round hands you a pull request, often one that looks machine-written or was genuinely opened by a coding agent, and asks what you would say on it. Review out loud by category (correctness under concurrency, transaction boundaries, error paths, migration safety, N+1, missing index, missing authorisation check, secrets in logs, unbounded memory or unbounded query) rather than reading line by line from the top. The debugging or incident round gives you a symptom and a dashboard: p99 jumped from 120ms to 4s at 14:05, error rate flat, CPU flat, database connections pinned at the pool ceiling. They are grading method: form a hypothesis, say what observation would disprove it, ask for the specific metric or log line, narrow. Candidates fail this by guessing causes instead of asking for evidence.

Ask two questions at the end of every round, because they cost nothing and change your decisions later: what the on-call rotation is and whether it is compensated, and what fraction of the next year is new build versus migration.

• Recruiter screen (20 to 30 min): stack, level, on-call expectations, location requirement, comp band. Ask for the band and the round list here.
• Technical screen: timed assessment, repository take-home, or a 60-minute live implementation. Ask which, and whether an assistant is allowed.
• Coding round (45 to 60 min): implement an endpoint or small component correctly. Graded on behaviour under concurrency and failure, plus tests.
• System design round (45 to 60 min): sets your level. Graded on tradeoffs stated out loud, the data model, and failure behaviour.
• Database and SQL round (45 min; common in fintech, logistics, healthcare, adtech): queries, indexes, EXPLAIN, transactions, migration safety.
• Code-review round (30 to 45 min, increasingly common): what you catch in someone else's or an agent's pull request.
• Debugging or incident round (45 min): diagnose a latency or correctness symptom from metrics and logs.
• Hiring manager round (45 min): ownership, on-call, conflict, what you shipped, what broke, and what you changed afterwards.

The system design round: what it tests at each level, and a method that works

The old canon (design a URL shortener, design Twitter) still appears, but the better interviewers now ask about the product they sell or a problem adjacent to it. Prompts that recur in backend loops: design a webhook delivery system; design an idempotent payment endpoint; design a notification fan-out; design a job scheduler with retries; design a multi-tenant audit log; design the ingestion path for device telemetry; design the API for a feature we are about to ship. All of them reward the same discipline.

Run the round in a fixed order and say the order out loud, because a visibly structured 50 minutes beats a brilliant tangent. First, functional scope: name the two or three operations the system must support and confirm what is out of scope. Second, numbers, the step candidates skip and interviewers most notice. Ask for, or state your assumption about, request volume, read/write ratio, payload size, retention and growth, then do the arithmetic out loud. 500 writes per second at 2KB each is about 1MB per second, roughly 86GB a day and about 2.5TB a month before indexes; that is a completely different design from 5 writes per second, and saying so is the point. Third, the API contract: endpoints or message shapes, request and response bodies, error codes. Fourth, the data model: actual tables or collections, keys, and the indexes that make your access patterns fast. Fifth, scale and the asynchronous path. Sixth, failure: what happens when each dependency is slow, down, or returns twice.

What separates levels is specificity, not vocabulary. A junior answer says "we add a cache". A mid answer says "cache-aside in Redis keyed by tenant and resource id, 60-second TTL with jitter, invalidated on write, and the thundering-herd case handled with a single-flight lock". A senior answer adds what it costs, what it breaks (a stale read window a human will notice, and the support ticket that follows), what you would measure to know the cache is earning its keep, and how you would get from the current system to the proposed one without downtime.

Name consistency explicitly. Say "this read is eventually consistent and the client must tolerate a second of staleness", or "this must be in the same transaction as the balance update, so both live in Postgres". The most common senior-level failure is drawing a diagram where a critical invariant quietly spans two datastores with no mechanism to keep them agreeing, which is exactly what the transactional outbox pattern exists for: write the row and the outbox record in one transaction, publish from the outbox.

Say what you are choosing not to do, and why. "I am not sharding this. At the volume we estimated, one Postgres primary with read replicas is fine for two years, and sharding costs us cross-shard queries and a much worse migration story. If writes reach roughly ten times this, I would partition by tenant id, and here is how I would get there." Interviewers rate that far above a candidate who reaches for Kafka and Cassandra in minute three.

Finish on failure and operations even if you have to cut something else: timeouts on every network call with budgets that add up to less than the client's timeout, retries with exponential backoff and jitter and a cap, idempotency keys so retries are safe, circuit breakers or load shedding so a slow dependency does not consume your whole thread or connection pool, a dead-letter queue for poison messages, and the two or three metrics you would actually page on.

• Do the arithmetic out loud. QPS, payload size, rows per day, bytes per month, retention. A design without numbers cannot be evaluated.
• Write the API contract before the boxes: endpoints, payloads, status codes, pagination style, error semantics.
• Draw real tables with real keys and the indexes your queries need, not a box labelled "DB".
• Name the consistency model at each boundary, and never let an invariant straddle two stores without an outbox or a reconciliation job.
• Default to boring: one relational database, one cache, one queue. Justify every extra component by naming what it buys and what it costs.
• Close on failure and operations: timeouts, bounded retries with jitter, idempotency, dead-letter queue, the alerts you would page on.
• Say the tradeoff you rejected. Choosing is the skill; listing options is not.

Databases, APIs and auth: the knowledge the data round assumes, and how to drill it

Over-prepare this section, because an ORM will have shielded you from most of it in day-to-day work and interviewers know that. The questions are rarely exotic. They are about whether you have ever looked underneath.

SQL that gets asked: multi-table joins, aggregation with GROUP BY and HAVING, and at least one window function (ROW_NUMBER or a running total), because "latest row per group" is the most common real query shape and the version written with a correlated subquery is the one that falls over. Then indexing: what a composite index on (tenant_id, created_at) can and cannot serve, why column order matters, why a leading-wildcard LIKE cannot use a B-tree index, what a covering index buys, and why indexing every column makes writes slower and the planner's choices worse. Be able to read EXPLAIN output well enough to say "sequential scan on a 40-million-row table, so we are missing an index on the filter column", and to explain the difference between EXPLAIN and EXPLAIN ANALYZE.

Transactions and concurrency: know your database's default isolation level (read committed in PostgreSQL, repeatable read in MySQL InnoDB) and what anomaly it permits. Describe the lost-update problem concretely, a read-modify-write of a balance from two requests at the same instant, and the two fixes: a single atomic UPDATE with the arithmetic in SQL, or SELECT ... FOR UPDATE to take a row lock. Know what a deadlock is, that the usual cause is two transactions touching rows in different orders, and that the fix is a consistent ordering plus a retry. Know what connection pooling is for, why a pool larger than the database can serve makes latency worse rather than better, and why serverless functions in front of Postgres need a proxy such as pgbouncer or RDS Proxy.

Schema design judgment, stated as decisions: money as integer minor units or NUMERIC, never a float; timestamps as timestamptz stored in UTC; UUIDv7 or ULID rather than UUIDv4 for a primary key, because random UUIDs scatter index writes; soft deletes only where you can name who reads the deleted rows and how you will keep them out of every other query; an enum column when the set is fixed by code and a lookup table when a human will add to it. Normalise first, then denormalise deliberately and say which query forced it.

Migrations are an interview topic in their own right, because a bad one is an outage. Know the expand-and-contract pattern by name: add the new nullable column, deploy code that writes both, backfill in bounded batches, deploy code that reads the new column, then drop the old one. Never rename a column in one step while old code is running. Know which operations take a lock long enough to matter on your engine (creating an index without CONCURRENTLY in Postgres, some type changes, adding a column with a volatile default), and that a backfill must be chunked rather than one UPDATE over 50 million rows in a single transaction.

Authorisation and multi-tenancy, which is a whole line of questioning at any company handling regulated data: how a request's identity reaches the query, how you prevent one tenant reading another's rows (a tenant_id predicate enforced in one place, or row-level security), the difference between authentication and authorisation, the roles of OAuth 2.0 and OIDC in that flow, what a JWT does and does not prove, why you validate signature, issuer, audience and expiry, and why revocation is the hard part. Be ready for "where is the authorisation check" as a code-review question, because missing object-level authorisation is the most common real API vulnerability.

NoSQL and caching, where the posting calls for it: in DynamoDB you design access patterns first and the key schema follows, and you must be able to explain partition keys and the hot-partition failure. Redis questions are usually cache-aside versus write-through, TTL with jitter, stampede on a cold key, and whether you have used it as a lock (a naive SETNX lock without a fencing token is not safe under process pauses). "We used Redis only as a read cache and never as a source of truth" is a good answer.

API design, the other half of the round: REST resource modelling and when an action is honestly just a POST to a verb endpoint; the status codes that carry meaning (201 with a Location header, 400 versus 422, 409 for a conflict, 429 with Retry-After, 503 versus 500); cursor pagination, and why offset pagination both drifts under concurrent inserts and gets slower the deeper you page; idempotency keys on anything that moves money or sends a message; versioning and what counts as a backward-compatible change (adding an optional field yes, tightening validation no); contract-first with OpenAPI or protobuf so consumers can generate clients. Know where gRPC earns its place (internal, high-volume, strongly typed, streaming) and GraphQL's characteristic trap (resolver-level N+1, solved with batching or a dataloader, plus depth and cost limits on a public graph).

Asynchronous messaging, because almost every real backend has some: at-least-once delivery is the default, so consumers must be idempotent; exactly-once is effectively-once built from deduplication and idempotency, not a feature you switch on; ordering is per partition or per queue, not global, so the partition key is a design decision; visibility timeouts, dead-letter queues and poison messages; backpressure, and why unbounded retries during an outage turn a dependency's bad minute into your bad hour. The retry-storm question is asked specifically to see whether you reach for jitter.

Operations, because a backend candidate who cannot discuss production reads as junior regardless of years: structured logs with a request id propagated across services, distributed tracing, the difference between p50 and p99 and why an average hides the failure your users feel, what an SLO and an error budget are for, and one incident you can narrate from alert to root cause to the change that made it impossible to recur.

How to drill all of it in about three weeks, two hours a day. Week one, data: run Postgres locally in Docker, generate ten million rows with generate_series, then write "latest row per group" three ways (correlated subquery, window function, lateral join) and compare EXPLAIN ANALYZE timings; add and drop a composite index and watch the plan change; open two psql sessions and reproduce a lost update, then fix it both ways; run an expand-and-contract migration against the loaded table and time the lock. Week two, design and APIs: take the six prompts listed above and run each in a 50-minute timer, out loud, recorded, with a drawing tool you can share; afterwards write out the API contract and the DDL you described and see whether they actually hold together. Build one endpoint with an idempotency key backed by a unique constraint and prove it by replaying the same request. Week three, operations and review: load test your own service with k6, vegeta or wrk and record p50/p95/p99 and the point at which it falls over; instrument it with OpenTelemetry and find one real slow path; have an assistant generate a 200-line pull request against it, then review that PR by category and write the comments down, because that is the code-review round. Do at least two sessions with the assistant switched off, so an unaided round is not a shock. For reference material use primary sources: the PostgreSQL manual's chapters on indexes, concurrency control and EXPLAIN, your cloud provider's well-architected guidance, your queue vendor's delivery-semantics documentation, and Martin Kleppmann's Designing Data-Intensive Applications for the distributed-systems vocabulary.

• A window function for "latest row per group", composite index column order, and reading EXPLAIN ANALYZE: three things that come up again and again.
• Know your engine's default isolation level and the anomaly it allows, plus the two fixes for a lost update.
• Expand and contract, batched backfill, no single-step rename: the migration answer interviewers want.
• Tenant isolation and object-level authorisation: where the check lives, and why a valid JWT does not answer it.
• At-least-once is the default, so the consumer is idempotent and the retries have jitter and a cap.
• Cursor pagination over offset, idempotency keys on money and messages, 409 and 429 used correctly.
• Drill against a loaded local database, not a 100-row toy, because every interesting answer depends on scale.

The backend resume: what gets read, what gets skipped, and where the numbers come from

A backend resume is read twice by different people with different questions. A recruiter or an ATS matches the stack and the level. An engineer then scans for 20 seconds asking one thing: has this person owned a system, or a list of tickets? Everything below serves the second reader, because the first is satisfied by naming your stack accurately.

Write service-shaped bullets. A service-shaped bullet names the thing you owned, what it did, the scale in real units, and the outcome. For example: "Owned the payments reconciliation service (Go, Postgres, SQS): about 4M transactions a month; cut unmatched items from roughly 2% to under 0.1% by adding an idempotency key and a nightly repair job." Compare that with "Developed and maintained RESTful microservices using modern technologies in an Agile environment", which tells an engineer nothing and appears on an enormous number of backend resumes.

The units that make a backend resume credible are specific: requests per second or per day, p95 and p99 latency in milliseconds, row counts and table sizes, data volume per month, number of tenants or customers, queue throughput, monthly cloud cost, availability, deploy frequency, incident count. Four or five numbers across the whole resume is enough. Every one of them is an interview question, so only write numbers whose derivation you can explain.

If you do not have dashboard figures, derive honest ones before you leave the job, or reconstruct them carefully: a count on the main table, row growth per day, the cloud invoice line for your service, the retention setting, the number of customer accounts, request counts in the load balancer logs. Approximate openly with "roughly" or "about". A hiring manager will accept an approximation you can explain and will distrust a suspiciously precise percentage you cannot.

Name versions and specifics where they differentiate you: PostgreSQL 16 rather than "SQL databases"; Kafka with the partitioning scheme rather than "message brokers"; "Spring Boot with JPA, and the three places we dropped to raw SQL because the generated query was unusable". Specificity reads as experience. A 30-item skills matrix reads as padding and invites a question about the thing you touched once in 2021.

What gets skipped or actively hurts: an objective statement, "passionate about technology", soft-skill lists, proficiency bars, tutorial projects with no users, the same four bullets repeated under three employers, and any scale claim with no unit attached ("high traffic", "large scale", "big data"). Two pages at most, one if you have under five years. Put the stack line directly under each role, because that is what a scanning engineer looks for first.

A projects section earns its space only if the project is operated or consumed by someone, or it demonstrates something your jobs did not. One entry with a URL, the stack, one design decision and one number beats a list of repositories. Link the repository and make sure the README documents the API and the schema, because interviewers who click do read the README and rarely read the code.

• Lead each role with the service you owned and its stack, not with the methodology.
• Quantify in backend units: QPS, p99 ms, rows, GB per month, tenants, cost, availability, deploy frequency.
• Include one migration bullet and one incident bullet. Both are rare on resumes and both are directly interview-relevant.
• Use "owned", "designed", "migrated", "reduced", "instrumented". Avoid "assisted with", "was responsible for", "participated in".
• Mirror the posting's exact technology words where they are true, because both the ATS and the recruiter match literal strings.
• Never put a number on the page you cannot derive out loud. Every figure is a question.
• Two pages maximum, no photo, no graphics, plain headings. Design wins you nothing here and can break parsing.

Interview questions you should expect, and what each one is grading

These are the recurring questions in backend loops, grouped by what they measure. Prepare answers that are concrete about a system you really worked on, because the follow-up is always "in your case, what did you do?"

One pattern to internalise for the behavioural round: interviewers are checking whether you have operated software, not whether you are agreeable. The strongest answers contain a number, a decision made under uncertainty, and something that went wrong plus what you changed afterwards. "We had no incidents" is not a good answer; it usually means you were not close to production.

• "Walk me through a service you owned." Grading: scope and depth. Have one you can take from endpoint to table to deploy to alert, with numbers.
• "How would you make this endpoint idempotent?" Grading: whether you have handled a double-submitted payment. Idempotency key, unique constraint, stored response.
• "This query got slow. What do you do?" Grading: method. Reproduce, EXPLAIN ANALYZE, check the index and cardinality, look at row counts and plan choice, change one thing and measure.
• "Design the schema for X." Grading: keys, constraints, indexes tied to access patterns, and whether you mention the migration path.
• "Two requests update the same balance at the same instant. What happens?" Grading: concurrency literacy. Lost update, atomic UPDATE or SELECT FOR UPDATE, isolation level.
• "How do you deploy a column rename with zero downtime?" Grading: production experience. Expand and contract, dual write, batched backfill, contract.
• "How do you stop tenant A reading tenant B's rows?" Grading: authorisation design. Identity reaching the query, a predicate enforced in one place or row-level security, and how you test it.
• "The downstream service starts timing out. What does your service do?" Grading: failure design. Timeout budget, bounded retries with jitter, circuit breaker or shed load, degrade rather than cascade.
• "Your consumer gets the same message twice. Is that a bug?" Grading: whether you know at-least-once is normal. Consumer-side deduplication, idempotent handler.
• "How do you know the service is healthy?" Grading: operational maturity. SLO, p99, error rate, saturation, and the one alert you would page on at 3am.
• "REST, gRPC or GraphQL here, and why?" Grading: fit reasoning, not fashion. Audience, payload shape, typing, streaming, client count.
• "Tell me about an outage you were part of." Grading: ownership and honesty. Symptom, how you narrowed it, the fix, the durable follow-up, what you would do differently.
• "How do you use an AI assistant, and what do you not let it do?" Grading: judgment. An answer with no limits named is a weak answer.

Where the jobs are, how to reach a human, and what to say about pay

Backend demand concentrates where things move money, goods, records or messages: payments and fintech, insurance and healthcare claims, logistics and supply chain, telecom, adtech, infrastructure and developer-tools vendors, marketplaces, government contractors, and large retail. The visible consumer-tech names take a small share of the hiring and a large share of the attention. If you are optimising for interviews per application, apply where the backend is the product and the brand is unfamiliar.

Mid-size companies and startups are where application volume works in your favour, because they often skip the online assessment and run a pairing session or a take-home, and they decide in days rather than weeks. The tradeoff is a wider job (you will run the database and some infrastructure) and less structured levelling, so negotiate title and scope explicitly.

Reaching a human still beats the portal. The reliable version for backend roles: find the engineer who owns the relevant system (a conference talk, an engineering blog post, release notes, a commit in their open-source repository, a maintainer thread) and send four sentences that reference a specific technical detail of what they published, state what you have shipped that is adjacent, and attach nothing. Referrals from former colleagues outperform everything else, and that is the reason to stay reachable after you leave a job.

On remote: remote backend roles still exist in real numbers, because the work is asynchronous by nature. But many large employers now attach a location-based band and some require hybrid attendance, and a posting labelled remote may still mean remote-within-one-country or three days in an office. Confirm both the location requirement and how the band is set in the first call, not at offer.

On pay, do not negotiate against a number you read on a forum. Establish the band from sources you can cite: the BLS Occupational Employment and Wage Statistics for Software Developers (SOC 15-1252) for a geographic baseline with metro percentiles, levels.fyi for level bands at public companies, and the posting itself in pay-transparency states (California, Colorado, New York, Washington, Illinois, Minnesota, Maryland, Hawaii, Vermont, New Jersey, Massachusetts and others), where a range must be published. For federal and many contractor roles the schedule is public, so read it.

Then use a simple script in the recruiter call. "What is the band for this level?" is a question they are usually required to answer in a transparency state and often willing to answer anywhere. If pressed for your number first, answer with the band and the basis: "Based on the posted range and the scope you described, I am targeting the upper half of that band, and I am flexible on the mix of base and equity." The backend-specific leverage, when you have it, is production ownership: a candidate who has run migrations on a large table under load and carried a pager is harder to replace than one who has only written handlers. That argument moves the level, and the level is what moves the money.

• Apply where backend is the product: payments, claims, logistics, telecom, utilities, infrastructure vendors, marketplaces, government contractors.
• Smaller companies interview faster and often skip the timed assessment. Larger ones pay in bands and level you formally.
• Ask in round one: the rounds, the on-call rotation and whether it is paid, the band, the location requirement, and what fraction of the year is migration work.
• Cite BLS OES 15-1252 and the posted range rather than a forum figure, and negotiate the level rather than the opening base number.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Backend developer
• Backend engineer
• Server-side engineer
• API developer
• Python
• FastAPI
• Django
• Java
• Spring Boot
• Go
• Node.js
• TypeScript
• NestJS
• C#
• .NET
• Ruby on Rails
• Rust
• REST API
• gRPC
• GraphQL
• OpenAPI
• API design
• API versioning
• Cursor pagination
• Idempotency
• Rate limiting
• Authentication and authorization
• OAuth 2.0
• OpenID Connect
• JWT
• Row-level security
• Multi-tenancy
• PostgreSQL
• MySQL
• SQL
• Window functions
• Query optimization
• EXPLAIN ANALYZE
• Index design
• Database schema design
• Normalization
• Transactions
• Isolation levels
• Row-level locking
• Deadlock
• Connection pooling
• pgbouncer
• Zero-downtime migration
• Expand and contract migration
• Backfill
• Redis
• Caching
• Cache invalidation
• DynamoDB
• MongoDB
• Elasticsearch
• Kafka
• RabbitMQ
• Amazon SQS
• Event-driven architecture
• Transactional outbox
• At-least-once delivery
• Dead-letter queue
• Backpressure
• Exponential backoff
• Circuit breaker
• Distributed systems
• System design
• Microservices
• Monolith
• Concurrency
• Throughput
• p99 latency
• Load testing
• k6
• Capacity planning
• Docker
• Kubernetes
• Terraform
• CI/CD
• AWS
• Google Cloud
• Azure
• Observability
• OpenTelemetry
• Distributed tracing
• Structured logging
• Prometheus
• Grafana
• SLO
• Error budget
• On-call
• Incident response
• Postmortem
• Unit testing
• Integration testing
• Contract testing
• Code review
• AI-assisted development
• LLM integration
• Streaming responses
• Server-sent events
• Retrieval-augmented generation
• pgvector
• Vector search
• Embeddings
• Model evaluation
• Prompt injection
• MCP server
• Secure coding

Mistakes that cost people this job

Questions people ask