Career roadmap
Backend Engineer
Own the data, the contracts and the failure modes: APIs that stay correct under load and under partial failure.
Before you start Backend
- One backend language: Node/TypeScript, Python, Java or Go
- SQL: joins, indexes, and reading a query plan
- Git, Linux command line, and HTTP fundamentals
APIs that hold up
Design and build an API a second team could consume without asking you questions.
Most candidates know the verbs. Fewer can explain idempotency or correct status codes under failure.
Ch — Node.js Event Loop- Verbs, status codes, and idempotency
- Caching headers, ETags and conditional requests
- Content negotiation and versioning strategies
- Pagination: offset vs cursor
The boundary between your service and the world is where most production bugs enter.
- Schema validation at the edge
- OpenAPI / JSON Schema as the contract
- Error shapes and problem+json
- Backwards-compatible API evolution
Asked in almost every backend interview, and answered badly in most of them.
- Sessions vs JWT, and when each is wrong
- OAuth 2.1 and OIDC flows
- Refresh token rotation and revocation
- RBAC vs ABAC, and enforcing it in one place
Knowing when not to use REST is a senior signal. Both appear in job specs regularly.
- GraphQL schema design and the N+1 problem
- DataLoader and batching
- gRPC, protobuf and streaming
- Choosing between REST, GraphQL and RPC
Layering and dependency direction are what code review actually catches you on.
- Controllers, services and repositories
- Dependency injection and testability
- Domain modelling basics
- Configuration and the twelve-factor app
BuildA REST API with authentication, pagination, validation, and an OpenAPI spec generated from the code.
Databases in anger
The single highest-value backend skill: knowing why a query is slow and what to do about it.
Window functions and CTEs come up constantly once you are past the junior filter.
Ch — Mongoose Schemas- Joins, subqueries and CTEs
- Window functions for ranking and running totals
- Aggregations and GROUP BY semantics
- NULL behaviour and three-valued logic
'This query is slow, here is the plan, what would you do?' is a standard live exercise.
- B-tree, composite and covering indexes
- Reading EXPLAIN ANALYZE
- Selectivity, cardinality and index choice
- When an index makes things worse
Isolation levels are where interviews separate people who have run production databases from people who have not.
- ACID and the four isolation levels
- Lost updates, phantom reads, write skew
- Optimistic vs pessimistic locking
- Deadlocks: causes and avoidance
Normalisation, and the deliberate decision to denormalise, with reasons.
- Normal forms and when to break them
- Soft deletes, audit trails, temporal data
- Migrations that run against live traffic
- Document vs relational trade-offs
Picking the right store, and being able to defend the choice, is the actual test.
- MongoDB document design and indexing
- Redis data structures and eviction policies
- Cache invalidation strategies
- Search engines: when you need one
BuildLoad ten million rows, find the slow queries, and fix them with indexes and schema changes. Document the plans before and after.
Distributed behaviour
Systems that keep working when a dependency is slow, down, or lying to you.
Background jobs are in nearly every backend codebase and nearly every backend interview.
- Producer/consumer with Kafka, SQS or RabbitMQ
- At-least-once delivery and idempotent consumers
- Dead letter queues and poison messages
- Ordering guarantees and partitioning
Retries without backoff are how one slow service takes down four others.
- Timeouts, retries and exponential backoff with jitter
- Circuit breakers and bulkheads
- Graceful degradation and fallbacks
- Backpressure and load shedding
The vocabulary senior interviews expect: CAP, eventual consistency, and the saga pattern.
- CAP and PACELC in practical terms
- Eventual consistency and read-your-writes
- Sagas and compensating transactions
- Outbox pattern for reliable publishing
Where to cache, how to invalidate, and how to avoid a stampede when it expires.
- Cache-aside, write-through, write-behind
- TTL choice and cache stampede prevention
- CDN and edge caching
- Cache key design and hot keys
'The API is slow' — walk me through how you find out why. Expect this question.
- Structured logging with correlation ids
- RED and USE metrics
- Distributed tracing with OpenTelemetry
- Alerting on symptoms, not causes
BuildSplit one service in two, connect them with a queue, and make the flow survive a consumer crash without losing or duplicating work.
Running it in production
Backend engineers are expected to own deployment and operations, not hand them over.
Docker literacy is assumed. Multi-stage builds and small images are the differentiator.
- Dockerfiles and multi-stage builds
- Health checks and graceful shutdown
- Rolling, blue/green and canary deploys
- Configuration and secrets injection
OWASP Top 10 questions appear in most backend loops and almost all of them in fintech.
- Injection, SSRF, IDOR and mass assignment
- Password storage and rate limiting
- Secrets management and key rotation
- Dependency and supply-chain scanning
Numbers beat adjectives. Being able to produce a load test result is a strong signal.
- Load testing with k6 and interpreting results
- Connection pooling and pool sizing
- Profiling CPU and memory
- N+1 queries and batch loading
Testcontainers changed the standard answer: test against the real database.
- Unit vs integration vs contract tests
- Testcontainers for real dependencies
- Contract testing between services
- Seeding and test data management
Increasingly asked at senior level: what does your design cost to run?
- Cost of egress, storage and compute
- Right-sizing and autoscaling
- Query cost and read replicas
- Build vs buy for infrastructure
BuildContainerise a service, deploy it with zero-downtime rollout, and add a dashboard plus one meaningful alert.
System design and interviews
The round that decides your level and your offer band.
Structure beats brilliance. A repeatable method is what interviewers are scoring.
Ch — Scalable APIs- Requirements, scale estimates, and constraints first
- API design, then data model, then bottleneck
- Sharding, replication and read scaling
- Trade-off articulation and rejected options
Heavier than frontend interviews. Graphs and heaps do appear at product companies.
DSA Coding Questions- Arrays, hash maps, two pointers, sliding window
- Trees, graphs, BFS and DFS
- Heaps and priority queues
- Time and space complexity under pressure
Very common in Indian product and service company loops: design classes for a real problem.
- SOLID applied to a real feature
- Common patterns: strategy, factory, observer
- Designing for testability
- Concurrency in object design
An increasingly common format: here is an incident, find the cause.
- Reading logs, traces and metrics together
- Bisecting a regression
- Reproducing under load
- Writing the postmortem
Backend interviews weight ownership stories heavily — you are being trusted with data.
- An incident you owned end to end
- A migration you ran without downtime
- Pushing back on an unsafe deadline
- Mentoring and code review stories
BuildWrite three design documents for systems you have not built, each with capacity estimates and a rejected alternative.
Backend tools on your CV
- TypeScript / Python / Go
- PostgreSQL
- Redis
- Kafka
- Docker
- OpenTelemetry
- k6
- Testcontainers
What Backend employers ask to see
- An API with an OpenAPI spec, auth, and a published rate limit policy
- A query optimisation write-up with EXPLAIN plans before and after
- A service that survives a chaos test: killed consumer, no lost messages
- Three system design documents with capacity estimates
Consistently the deepest hiring pool alongside frontend, and the usual route into distributed systems and platform work. Node, Java, Python, Go and .NET all hire heavily.
Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.