Home
All roadmaps

Back-End Track

Mentoxis Back-End Interview Roadmap

A start-to-offer path for the back-end interview at product companies — language depth, DSA, databases and the two design rounds that decide the loop.

9 stages16–20 weeksBuilt for students and working engineers targeting SDE-1 / SDE-2 back-end and platform roles.
1Core · sequential◇Optional · parallel∞Ongoing

  1. Why it matters · Interviewers expect fluency in one language's memory model, concurrency and standard library. Java is the safe default at most product companies; Go, Node or Python are all fine if you own them.

    Language core

    • Type system & memory model
    • Error / exception handling
    • Standard library & collections
    • Build & deps (Maven/Gradle, npm, go mod)

    OOP & paradigms

    • Encapsulation, inheritance, polymorphism
    • Interfaces & abstraction
    • Composition over inheritance
    • Functional touches: immutability, streams/lambdas

    Concurrency in the language

    • Threads / goroutines / event loop
    • Locks, atomics, thread pools
    • async / await, futures
    • Memory management & GC

    Testing

    • Unit tests & mocking
    • TDD basics
    • Integration test structure
    Mock this roundTutorials coming soon

  2. Why it matters · Unlike front-end, back-end loops lean hard on data structures and algorithms. Expect timed medium/hard problems across arrays, trees, graphs and dynamic programming.

    Foundations

    • Big-O time & space, amortized analysis
    • Arrays, strings, hashing
    • Two pointers & sliding window

    Recursion & structures

    • Recursion & backtracking
    • Linked lists, stacks, queues, deque
    • Trees, BST, tries, traversals
    • Heaps / priority queues

    Graphs & search

    • BFS, DFS, topological sort
    • Dijkstra & union-find
    • Binary search & variants

    Advanced

    • Dynamic programming (1D/2D, knapsack, LIS)
    • Greedy & intervals
    • Bit manipulation

    Practice plan

    • Pattern lists (Blind 75 / NeetCode 150)
    • Timed mock rounds
    • Explaining approach out loud
    Mock this roundTutorials coming soon

  3. Why it matters · Almost every back-end system-design and practical round touches schema design, indexing and transactions. Query-optimization and the N+1 problem come up constantly.

    Relational (SQL)

    • Schema design & normalization (1NF–3NF)
    • Joins, subqueries, aggregations
    • Window functions

    Indexing & queries

    • B-tree / hash / composite / covering indexes
    • EXPLAIN & query plans
    • Query optimization & the N+1 problem

    Transactions

    • ACID & isolation levels
    • Locking, MVCC, deadlocks

    NoSQL & scale

    • Key-value / document / wide-column / graph
    • CAP & when to pick each
    • Replication, sharding, partitioning
    • Caching: Redis, cache-aside, write-through
    Mock this roundTutorials coming soon

  4. Why it matters · You'll be asked to design and critique APIs, reason about auth, and explain what happens on the wire. Security fundamentals (OWASP, rate limiting) are expected, not bonus.

    HTTP & protocols

    • Methods, status codes, headers
    • HTTP/1.1 vs 2 vs 3, keep-alive
    • WebSockets, SSE, long polling

    API styles

    • REST: resources, versioning, idempotency, pagination
    • GraphQL: schema, resolvers, N+1
    • gRPC / Protobuf & when to use

    Auth & security

    • Sessions vs JWT, OAuth2, OIDC
    • RBAC, refresh tokens, API keys
    • OWASP Top 10, rate limiting, input validation

    Networking

    • TCP vs UDP, DNS, TLS
    • Load balancers, reverse proxy, CDN
    • Webhooks & API gateways
    Mock this roundTutorials coming soon

  5. Why it matters · Concurrency bugs, process vs thread, and how the OS schedules work show up in both coding and design rounds. This is the layer strong back-end candidates can actually reason about.

    Operating systems

    • Processes vs threads, context switching
    • Scheduling & virtual memory / paging
    • Stack vs heap, GC algorithms

    Concurrency

    • Race conditions & critical sections
    • Mutex, semaphore, deadlock, starvation
    • Producer-consumer, thread pools, async I/O

    Networking & Linux

    • OSI model, TCP handshake, sockets
    • Congestion & flow control
    • Linux: processes, permissions, signals, common commands
    Mock this roundTutorials coming soon

  6. Why it matters · High-level design decides most SDE-2+ loops. You need a repeatable framework, the standard building blocks, and the distributed-systems vocabulary to defend trade-offs under pressure.

    Fundamentals

    • Scalability (vertical/horizontal)
    • Latency vs throughput, availability, reliability
    • Back-of-envelope estimation (QPS, storage)

    Building blocks

    • Load balancers, caching, CDN
    • SQL vs NoSQL selection & scaling
    • Message queues (Kafka / RabbitMQ / SQS)
    • Search (Elasticsearch), API gateway

    Distributed systems

    • CAP & consistency models (strong / eventual)
    • Replication, partitioning, sharding
    • Consensus (Raft/Paxos) — awareness
    • Idempotency, circuit breakers, backpressure

    Framework

    • Requirements → estimation → API → data model
    • High-level design → deep dives → bottlenecks
    • Sync vs async & event-driven design
    • Microservices vs monolith

    Classic problems

    • URL shortener, rate limiter, typeahead
    • News feed, chat (WhatsApp), Twitter
    • Uber, YouTube/Netflix, Google Drive
    • Notification & payment systems, web crawler
    Mock this roundTutorials coming soon

  7. Why it matters · The LLD / OOD round checks whether you can turn requirements into clean, extensible classes. Product companies use it to gauge day-to-day code quality, not just system breadth.

    Principles

    • SOLID, DRY, KISS, YAGNI
    • Composition over inheritance
    • Thread safety & immutability in design

    Design patterns

    • Creational: Singleton, Factory, Builder
    • Structural: Adapter, Decorator, Facade, Proxy
    • Behavioral: Observer, Strategy, State, Command

    Modeling

    • UML class diagrams & relationships
    • Entities → classes → interfaces → APIs
    • Designing for extensibility & edge cases

    Classic problems

    • Parking lot, elevator, vending machine
    • BookMyShow, Splitwise, ride-sharing
    • LRU cache, rate limiter, logging framework
    • Chess / tic-tac-toe, notification service
    Mock this roundTutorials coming soon

  8. Why it matters · Rarely the main round, but strong answers on containers, CI/CD and observability signal production maturity — and they turn system-design deep-dives concrete.

    Containers & delivery

    • Git workflows, branching, PRs
    • Docker: images, containers, Compose
    • Kubernetes basics (pods, services, deployments)
    • CI/CD: pipelines, blue-green, canary, rolling

    Cloud

    • AWS/GCP/Azure: compute, storage, networking
    • IAM & serverless basics
    • Infrastructure as Code (Terraform basics)

    Observability & reliability

    • Logging, metrics, tracing
    • Monitoring (Prometheus/Grafana), alerting
    • SLI / SLO / SLA, incident response, on-call
    Mock this roundTutorials coming soon

  9. Why it matters · The hiring-manager and bar-raiser rounds decide close calls. Back-end candidates should have incident, on-call and scaling-decision stories ready alongside the usual set.

    Frameworks

    • STAR: Situation, Task, Action, Result
    • Quantifying impact with metrics
    • Structuring a concise answer

    Story bank

    • Ownership, incidents & on-call
    • Conflict, failure, ambiguity
    • Scaling / architecture decisions
    • Mentoring & disagreement

    Values & project

    • Company values / leadership principles
    • Project deep-dive: architecture & trade-offs
    • Whiteboarding your own system

    Closing the loop

    • Questions to ask the interviewer
    • Handling 'tell me about yourself'
    • Offer handling & negotiation
    Book this mockTutorials coming soon

Don't wait for the offer stage.

Book a 1:1 mock interview with a mentor at any point on this path — after a single stage or a full loop. Get scored, honest feedback on the exact round you're prepping, plus a plan for what to fix next.

Book a mock interview

Back-End interview FAQ

How long does it take to prepare for a back-end interview?
Plan for 16–20 weeks. Back-end loops lean hard on DSA plus two design rounds (HLD and LLD), so there's more ground than front-end. The Mentoxis back-end roadmap sequences language depth, DSA, databases, APIs, CS fundamentals, and system design so nothing is left to the last minute.
What should I study for a back-end developer interview?
Go deep on one language, master DSA, and learn databases (SQL indexing, transactions, NoSQL trade-offs), API and networking design, OS/concurrency fundamentals, high-level system design, and low-level object-oriented design. Behavioural rounds decide close calls. The roadmap breaks down every topic.
Is DSA important for back-end interviews?
Yes — it's core. Back-end coding screens use medium/hard problems across arrays, trees, graphs and dynamic programming. Budget the most time here and drill patterns (Blind 75 / NeetCode 150) with timed mock rounds.
What is the difference between HLD and LLD?
High-Level Design (HLD) is system design — scalability, distributed systems, databases, queues, and trade-offs for problems like a URL shortener or news feed. Low-Level Design (LLD) is object-oriented design — SOLID, design patterns, and clean class modeling for problems like a parking lot or Splitwise. Product companies test both.
Which language should I use for back-end interviews?
Java is the safe default at most product companies, but Go, Node.js or Python are all fine if you own the language's memory model, concurrency and standard library. Depth in one language beats shallow breadth across several.
What is the best back-end interview roadmap?
The best roadmap orders language, DSA, databases, and the HLD/LLD design rounds so each compounds, and ties them to real practice. The Mentoxis back-end roadmap does exactly that and connects each stage to 1:1 mock interviews with senior engineers.