Start with fundamentals you can defend under pressure, not memorise: load balancing, caching strategies, SQL vs NoSQL trade-offs, sharding and partitioning, replication, message queues, and CAP/consistency trade-offs. Then work through 10–15 canonical designs — URL shortener, rate limiter, chat system, news feed, notification service, delivery tracking. For experienced candidates the bar is different from freshers: interviewers expect you to handle ambiguity, drive requirements yourself, and justify *why* you chose Kafka over RabbitMQ or Cassandra over Postgres — not just name them. Finish with 2–3 timed mock interviews where you design out loud in 40–45 minutes. Most rejections I see aren't knowledge gaps; they're candidates who started drawing boxes before asking what the system actually needs to do.

HLD (High Level Design) is system architecture — services, databases, caches, queues, sharding, replication, and how the whole thing behaves at scale. LLD (Low Level Design) is code-level — class diagrams, interfaces, SOLID principles, design patterns, and writing extensible object-oriented code for problems like a parking lot, Splitwise, or an elevator system. Most Indian product companies test both in separate rounds. Freshers and SDE-1 candidates get weighted toward LLD; SDE-2 and above face full distributed-systems HLD. If you're interviewing at LinkedIn, Microsoft, Google, Amazon, Walmart or Atlassian at SDE-2+, assume you'll face both and prepare accordingly.

Yes, and using one visibly is itself a scoring signal. Five steps: (1) clarify functional and non-functional requirements — spend the first five minutes here, do not skip it; (2) back-of-the-envelope estimates for QPS, storage and bandwidth; (3) define core APIs and the data model; (4) draw the high-level architecture, then deep-dive into one or two interesting components — usually the data layer or the caching/queueing strategy; (5) close by naming bottlenecks, failure modes and what you'd change at 10x scale. Narrate throughout. Interviewers score your reasoning and communication at least as heavily as the final diagram.

Roughly 250–350 well-understood problems, weighted toward medium difficulty, beats 800 solved randomly. What matters is pattern recognition, not volume: two pointers, sliding window, binary search variants, BFS/DFS on graphs, trees, heaps, intervals, backtracking, and dynamic programming. Re-solve the ones you failed a week later — that's where the retention actually happens. Keep an error log. Always state time and space complexity out loud. Experienced candidates can compress DSA slightly but cannot skip it: coding rounds at SDE-2+ still test medium-to-hard problems, and the most common failure mode is a senior engineer who neglected DSA because they assumed system design would carry them.

Backend loops at product companies typically have four parts: DSA coding, LLD, HLD/system design, and a deep-dive on your actual work. For the Java/Spring Boot stack, know the collections framework and its complexities cold, understand concurrency and the memory model, and be able to explain microservice communication patterns, idempotency, retries, circuit breakers, and how you'd handle partial failure. Be ready for depth on whatever is on your resume — if you list Kafka, expect questions on consumer groups, offset management, rebalancing, and exactly-once vs at-least-once semantics. The resume deep-dive is where most experienced candidates either separate themselves or get exposed.

Data engineering interviews test four areas: SQL and data modelling, a distributed processing framework (Spark/PySpark), pipeline and streaming architecture, and general system design applied to data. Expect questions on batch vs streaming trade-offs, ETL vs ELT, schema evolution, partitioning strategy, handling late-arriving and out-of-order data, backfills, and idempotent pipeline design. If you're moving from data analyst to data engineer, the gap is usually engineering rigour — version control, testing, orchestration, and thinking about failure and replay — rather than SQL skill. I work on LinkedIn's Brooklin, an open-source distributed streaming platform, building Change Data Capture and Kafka mirroring pipelines at trillion-message scale, so I can be specific about what production actually demands versus what tutorials teach.

Beyond basic producer/consumer APIs, interviewers probe: partitioning and key design (and what happens with hot keys), consumer groups and rebalancing, offset management, delivery semantics — at-most-once, at-least-once, exactly-once and what exactly-once really costs, ordering guarantees and their limits, retention and compaction, replication and ISR, and backpressure. Design questions typically ask you to build a CDC pipeline, an event-driven order system, or a mirroring setup across regions. The strongest answers come from people who have operated these systems and can talk about what breaks — consumer lag, rebalance storms, poison messages, schema evolution — not just what the docs say.

Stagnation is almost never a coding-ability problem — it's a scope, visibility and evidence problem. Promotion committees assess the level you're *already operating at*, not potential. So the work is: honestly audit your current scope against your next level's expectations, identify whether the gap is technical depth, cross-team influence, or documented impact, then deliberately choose projects that create that evidence — and decline the ones that don't. Build a written artifact trail (design docs, postmortems, RFCs) because that's what gets read in calibration when you're not in the room. Then run the conversation with your manager early and explicitly. I went through this to Staff at LinkedIn and have seen how these decisions get made from the other side.

Three filters, in order: ATS parsing, a recruiter's six-second scan, and a hiring manager's depth check. So: clean single-column format, no tables or graphics that break parsers, standard section headings, and the keywords from the actual job description. Every bullet should show measurable impact and scope, not responsibilities — "reduced p99 latency from 800ms to 120ms for a service handling 1M daily requests" beats "worked on backend performance". Order projects by relevance to the target role, not chronology. Most importantly, your resume should read at the level you're targeting: if you want SDE-2, the scope described must look like SDE-2 work. In India especially, product companies shortlist heavily on resume quality plus referrals, so this is often the actual bottleneck — not your coding skill.

Infrastructure rounds test whether you've operated systems, not just deployed them. Expect questions on container orchestration, pod scheduling and resource limits, service discovery, rolling and blue-green deployments, autoscaling behaviour, and observability — metrics, logging and distributed tracing. On the microservices side: inter-service communication patterns, idempotency, retries with backoff, circuit breakers, distributed transactions and the saga pattern, and how you handle partial failure. The strongest candidates describe a real incident they debugged and what they changed afterwards. Textbook answers are easy to spot.

Do DSA first if you're a student, fresher or SDE-1 — coding rounds are the gate you must clear before system design even matters. If you have two or more years of experience, run them in parallel, weighted toward system design, because that's where SDE-2 and above candidates are actually differentiated and rejected. The common mistake experienced engineers make is assuming seniority excuses weak DSA; it doesn't, coding rounds remain medium-to-hard. The mistake freshers make is studying HLD early when their interviews will be LLD-weighted.

Scope and influence, not coding ability. SDE-2 delivers well-defined projects reliably. Senior owns ambiguous problems end to end, makes design decisions others depend on, and improves the team's systems beyond their own tickets. Staff operates across teams — setting technical direction, resolving cross-org disagreements, and making decisions whose impact shows up quarters later. The practical implication is that you get promoted for evidence of already operating at the next level, so the work is choosing projects that create that evidence and documenting it in design docs and RFCs that get read when you're not in the room.