Question 1

What is the difference between a tech lead and an engineering manager?

Accepted Answer

In short: A tech lead owns technical direction for a team: architecture and design decisions, code quality, breaking down work, unblocking developers and mentoring — and still writes significant code. An engineering manager owns people and delivery: hiring, career growth, performance reviews, team health, process and cross-team coordination, with less hands-on coding. In smaller teams (and in many Indian IT services companies team lead roles) one person does parts of both.

Question 2

Explain Scrum roles, events and artifacts.

Accepted Answer

In short: Accountabilities: Product Owner (maximises value, owns and orders the Product Backlog), Scrum Master (coaches the team and organisation in Scrum, removes impediments), Developers (create the increment, own the Sprint Backlog). Events: the Sprint (container), Sprint Planning, Daily Scrum (15 min), Sprint Review, Sprint Retrospective. Artifacts with commitments: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done (2020 Scrum Guide).

Question 3

What is the difference between Agile and Waterfall?

Accepted Answer

In short: Waterfall is sequential — requirements, design, build, test, deploy — each phase completed before the next, with change being costly; it suits fixed, well-understood requirements and regulated contexts. Agile delivers in short iterations with working software each cycle, continuous feedback, and embraces change; it suits evolving requirements. Many enterprises use hybrids (fixed milestones with agile execution).

Question 4

How do you estimate a project or a large feature?

Accepted Answer

In short: Clarify scope and acceptance criteria; break it into small tasks (≤ 2–3 days) including testing, reviews, deployment and documentation; estimate with the people doing the work (planning poker or three-point estimates); add buffers for risks and unknowns (spikes for unclear areas); account for real capacity (meetings, support, leaves); state assumptions and dependencies explicitly; give a range rather than a single date; re-forecast as you learn and communicate changes early.

Question 5

How do you delegate work in your team?

Accepted Answer

In short: I delegate outcomes with context: why it matters, what done looks like, constraints, deadline and check-in points. I match tasks to skills and growth goals — a stretch task for a junior with a senior pairing, critical-path work for experienced people — and adjust my involvement to their experience (directing for new members, delegating to experts). Work is tracked on the board, I stay available to unblock, and I avoid taking the hardest tasks myself all the time so the team grows and I don t become a bottleneck.

Question 6

How do you mentor junior developers?

Accepted Answer

In short: Regular 1:1s and pairing sessions; clear coding standards and examples; code reviews that explain the why rather than just fixing things; gradually larger tasks with support (first a bug fix, then a small feature, then owning a module); encouraging questions and making it safe to make mistakes; sharing resources and certification paths; and celebrating progress publicly. I measure success by how independently they can deliver after a few months.

Question 7

How do you handle a team member who is underperforming?

Accepted Answer

In short: Gather facts first, then talk privately and early with specific examples, and listen to understand the cause (unclear expectations, skill gap, personal issues, motivation, wrong role). Agree on a concrete improvement plan with support — training, pairing, smaller scoped tasks — and regular check-ins. Recognise improvements. If there s no progress after a fair period, involve my manager and HR for a formal plan, documenting everything and treating the person with respect throughout.

Question 8

How do you resolve a conflict between two team members?

Accepted Answer

In short: Speak with each privately to understand their perspective and underlying concerns, then bring them together focused on facts and the shared goal. For technical disagreements, agree criteria and use data or a quick spike to decide; if still split, I make the call, explain the reasoning, record it (ADR) and ask both to commit. For personal friction, set expectations for respectful behaviour and follow up. I address conflict early, before it affects the team.

Question 9

How do you handle scope changes requested in the middle of a sprint?

Accepted Answer

In short: Protect the Sprint Goal. I acknowledge the request, assess urgency and impact with the Product Owner: if it s truly critical (production issue, regulatory), we swap out work of similar size and make the trade-off visible; otherwise it goes into the backlog for the next sprint planning. For client projects, significant changes go through impact analysis and a change request covering effort, timeline and cost.

Question 10

How do you report project status to stakeholders?

Accepted Answer

In short: Regular, concise updates: progress vs plan (with a RAG status), key achievements, risks and issues with mitigation plans, decisions needed from them, and next steps. I share bad news early with options and a recommendation, back statements with data (burnup charts, defect counts), tailor the detail to the audience (executives vs product owners), and keep a written record.

Question 11

How do you make architecture or technology decisions in a team?

Accepted Answer

In short: Start from requirements (including non-functional ones and constraints like budget, skills and timelines), list options, evaluate them against agreed criteria, run a spike or proof of concept for risky unknowns, involve the team and relevant experts, decide (and own the decision), and document it in an Architecture Decision Record with context, alternatives and consequences. Revisit decisions when context changes. I prefer reversible decisions made quickly and irreversible ones made carefully.

Question 12

How do you measure your team's performance?

Accepted Answer

In short: At team level, never individuals by raw output: DORA metrics (deployment frequency, lead time, change failure rate, time to restore), flow metrics (cycle time, throughput, WIP), quality (escaped defects, incident trends), predictability (planned vs delivered), and team health (engagement, attrition, on-call load). Business outcomes — features adopted, customer issues resolved — matter most. I use metrics to find improvement opportunities, not to rank people.

Question 13

Your project is two weeks from the deadline and you realise it will be late by one week. What do you do?

Accepted Answer

In short: Verify the estimate with the team and find the cause. Inform stakeholders immediately — no surprises — with options: reduce scope (ship must-haves first, defer nice-to-haves), add focused help where it actually speeds things up (not late-stage new joiners on complex code — Brooks s law), remove distractions from the team, parallelise testing, or move the date. Give a recommendation, get a decision in writing, update the plan, and run a retrospective later on why the risk wasn t spotted earlier.

Question 14

A critical production issue occurs on Friday evening. Walk me through how you handle it.

Accepted Answer

In short: Acknowledge and assess severity; assemble the right people (on-call, owners) and appoint an incident lead; open a communication channel and inform stakeholders with regular updates. Prioritise restoring service — roll back the last deployment, toggle a feature flag, fail over, scale up — before deep root-cause analysis. Once stable, monitor, then do a blameless post-mortem the next week with a timeline, root causes (5 Whys), and owned action items (tests, alerts, runbooks, safer deployments). Make sure people who worked late get time off.

Question 15

The client keeps adding requirements without changing the deadline. How do you manage it?

Accepted Answer

In short: Make the impact visible: maintain a prioritised backlog with estimates, show the client what each new request displaces, and agree priorities together (MoSCoW: Must/Should/Could/Won t). Use a change-request process for contractual scope, protect the current sprint, and propose phased delivery — an MVP by the date, the rest in later releases. Document decisions and keep the relationship collaborative rather than confrontational.

Question 16

Your best developer resigns in the middle of a critical release. What do you do?

Accepted Answer

In short: Have an honest conversation to understand the reasons — if it s fixable (role, growth, compensation) and appropriate, explore a counter-offer with my manager, but don t rely on it. Immediately plan the knowledge transfer: document their modules, pair them with others during the notice period, record walkthroughs, and review critical code together. Re-plan the release with stakeholders based on reduced capacity. Longer term, reduce single points of failure by rotating ownership, and look at retention across the team.

Question 17

What is the difference between HLD and LLD?

Accepted Answer

In short: HLD shows the architecture of the whole system: components (clients, load balancers, services, databases, caches, queues, CDN), how they interact, data flow, scaling and failure handling. LLD details the inside of components: classes, interfaces, methods, design patterns, database tables and APIs. HLD answers what pieces and how they connect ; LLD answers how each piece is built .

Question 18

Vertical vs horizontal scaling?

Accepted Answer

In short: Vertical: give one machine more CPU/RAM — simple, no code change, but limited and a single point of failure. Horizontal: add more machines behind a load balancer — almost unlimited and fault tolerant, but services must be stateless and data must be replicated/partitioned. Typical path: scale up first, then out.

Question 19

What is caching? Explain cache-aside.

Accepted Answer

In short: Storing frequently read data in faster storage (memory/Redis/CDN) to reduce latency and database load. Cache-aside: on read, check the cache; on miss, read from the database and put the result in the cache with a TTL; on write, update the database and delete (or update) the cache key. Watch for stale data, stampedes and hot keys.

Question 20

What does a load balancer do?

Accepted Answer

In short: Distributes requests across multiple servers to increase capacity and availability, performs health checks to stop sending traffic to failed servers, and can terminate TLS and route by URL (L7). Algorithms: round robin, least connections, IP hash/consistent hashing, weighted.

Question 21

Explain the CAP theorem with examples.

Accepted Answer

In short: In a distributed system, during a network partition you can t have both strong consistency and full availability. CP systems reject or delay requests to avoid stale data (bank balances, configuration stores like etcd); AP systems keep answering and reconcile later (social feeds, DNS, carts in Dynamo-style stores). When there is no partition, the trade-off is latency vs consistency (PACELC).

Question 22

SQL or NoSQL — how do you choose?

Accepted Answer

In short: Start from the data and access patterns. SQL for structured, related data needing transactions, joins and constraints (orders, payments). NoSQL when you need massive horizontal scale for simple key-based access, flexible schemas, very high write throughput, or special models (documents, graphs, time-series). Many systems combine them: SQL as the source of truth, Redis cache, search index, blob storage.

Question 23

What is sharding? How do you choose a shard key?

Accepted Answer

In short: Splitting a dataset horizontally across multiple database nodes so each stores a subset, increasing capacity and throughput. A good shard key has high cardinality, spreads reads and writes evenly (no hot shard) and matches the main query pattern so most queries hit one shard (e.g. customer id for orders). Use consistent hashing or a directory to allow adding shards with minimal data movement.

Question 24

What is consistent hashing and why is it useful?

Accepted Answer

In short: Nodes and keys are placed on a hash ring; each key belongs to the next node clockwise. When a node is added or removed, only the keys between it and its neighbour move (~1/N of keys), unlike hash % N where almost all keys move. Virtual nodes (many points per server) spread load evenly. Used in distributed caches and databases (Dynamo, Cassandra) and load balancers.

Question 25

Why use a message queue in system design?

Accepted Answer

In short: To decouple services (the producer doesn t wait for or depend on the consumer being up), absorb traffic spikes (load levelling), process work asynchronously (emails, video encoding), retry failures with dead-letter queues, and fan out events to multiple subscribers. Consumers must be idempotent because delivery is at-least-once.

Question 26

Design a URL shortener (high level).

Accepted Answer

In short: Write API creates a short code (base62 of a unique id or random 7 chars with collision check) and stores code → long URL in a key-value store or SQL with a unique index; read path GET /{code} checks Redis, then the store, and returns a 301/302 redirect. Reads dominate (100:1) → cache and CDN/edge. Analytics: send click events to a queue/stream and aggregate asynchronously. Scale: shard by code; custom aliases, expiry and abuse checks as extras.

Question 27

Design a news feed. Push or pull?

Accepted Answer

In short: Fan-out on write pushes post ids into followers precomputed feeds (fast reads, expensive for celebrities); fan-out on read builds the feed at read time (cheap writes, slow reads). Use a hybrid: push for normal users, pull and merge for celebrity accounts. Store feeds in Redis lists, posts in a sharded store, media via CDN, use cursor pagination, and rank asynchronously.

Question 28

Your read-heavy API's database is at 90 % CPU. What steps do you take, in order?

Accepted Answer

In short: Measure the top queries first; add/fix indexes and remove N+1 queries; add caching (in-memory/Redis) for hot data and HTTP caching/CDN where possible; route reads to read replicas; reduce payloads with projection and paging; scale the database up as a quick fix; finally partition/shard if data or write volume demands it. Monitor after each step.

Question 29

A flash sale will bring 50× normal traffic for 10 minutes. How do you prepare?

Accepted Answer

In short: Load test beforehand; pre-scale and warm caches; serve static content from the CDN; put a virtual waiting room/queue in front of checkout; rate limit per user; make inventory reservation atomic (conditional update) to prevent overselling; move non-critical work (emails, analytics) to queues; use feature flags to switch off expensive features; monitor dashboards and have a rollback plan.

Question 30

How do you approach an LLD question?

Accepted Answer

Clarify requirements and scope → list use cases → find entities (nouns) and behaviours (verbs) → define relationships (composition, inheritance, interfaces) → draw a class diagram → apply SOLID and suitable patterns (Strategy, State, Factory, Observer) → write code for the main flows → discuss edge cases, concurrency, extensibility, testing and persistence.

Question 31

Composition vs inheritance — which do you prefer in LLD and why?

Accepted Answer

In short: Prefer composition ( has-a ) because it keeps classes small and flexible: behaviour can be swapped at runtime via interfaces (Strategy) and changes don t ripple through a hierarchy. Use inheritance only for genuine is-a relationships with shared behaviour and substitutability (Liskov). Deep inheritance trees become rigid and fragile.

Question 32

Explain association, aggregation and composition with examples.

Accepted Answer

In short: Association: objects know/use each other (Teacher ↔ Student). Aggregation: whole–part where the part can exist independently (Team has Players; players exist without the team) — hollow diamond. Composition: strong ownership where the part s lifetime depends on the whole (House has Rooms; Order has OrderLines) — filled diamond.

Question 33

Design a parking lot — what are the key classes and patterns?

Accepted Answer

In short: ParkingLot (facade/singleton via DI) composed of Floors composed of Spots; Vehicle hierarchy (Car, Bike, Truck) or a type enum; Ticket; FeeCalculator with Strategy per vehicle type; optional Observer for display boards; Factory for vehicles. Concurrency: lock or atomic spot allocation so two gates can t take one spot. Extensibility: new vehicle/spot types and pricing rules without modifying existing classes.

Question 34

When do you use the State pattern? Give an LLD example.

Accepted Answer

In short: When an object s behaviour changes with its internal state and you d otherwise have large switch statements on state. Each state is a class implementing the same interface; the context delegates to the current state, and states trigger transitions. Examples: vending machine (Idle, HasMoney, Dispensing, SoldOut), order lifecycle, ATM, elevator, document approval.

Question 35

How do you handle concurrency in an LLD (e.g. seat booking)?

Accepted Answer

In short: Identify shared mutable state and make the critical operation atomic: locks around allocation in a single process, atomic compare-and-set ( Interlocked , ConcurrentDictionary.TryAdd ), optimistic concurrency (row version) or unique constraints in the database, distributed locks with TTL (Redis SET NX PX ) across servers. Seat booking: temporary locks with expiry, confirm on payment, unique (ShowId, SeatId) constraint as the final guarantee.

Question 36

Design an ATM cash dispenser. Which pattern fits?

Accepted Answer

In short: Chain of Responsibility: handlers for ₹2000, ₹500, ₹200 and ₹100 notes; each dispenses as many notes as it can ( amount / denomination , limited by its stock) and passes the remainder to the next handler; if a remainder is left at the end, the request fails and nothing is dispensed (check first, then commit). Around it: ATM with the State pattern (Idle → CardInserted → Authenticated → Transaction), a BankService interface for balance/debit, and transaction logging.

Question 37

Design an LRU cache with O(1) operations.

Accepted Answer

In short: A hash map from key to a node in a doubly linked list ordered by recency. Get: find the node via the map, move it to the front, return the value. Put: if present, update and move to front; otherwise insert at the front, and if capacity is exceeded remove the tail node and its map entry. Add a lock for thread safety. In C#: Dictionary K, LinkedListNode (K,V) + LinkedList (K,V) .

Question 38

In a machine-coding round you have 90 minutes to build a working Splitwise. How do you plan your time?

Accepted Answer

In short: 10 min: requirements and class diagram (User, Group, Expense, Split strategies, Ledger/BalanceSheet). 50 min: implement core — add expense with equal/exact/percent split (Strategy), update pairwise balances, show balances per user, validation (percentages sum to 100, exact amounts sum to total). 20 min: simplify debts (greedy matching of max creditor and max debtor), simple console/driver and a few unit tests. 10 min: refactor names, handle rounding, explain extensions (currencies, persistence, notifications).

Question 39

Explain 3-tier (N-layer) architecture.

Accepted Answer

In short: Presentation (UI), business logic (services/BLL) and data access (DAL/repositories), each calling only the layer below. It separates concerns and lets teams work on layers independently. Layers are logical; tiers are physical machines. Weakness: business logic often depends directly on data access, making it hard to test and change.

Question 40

What is Clean Architecture? What is the dependency rule?

Accepted Answer

In short: An architecture that places the domain (entities, business rules) and application use cases at the centre and frameworks, UI and databases at the outside. The dependency rule: source-code dependencies only point inward — the domain depends on nothing; the application defines interfaces that infrastructure implements; the web project is the composition root that wires everything with DI.

Question 41

How do you structure a typical ASP.NET Core Web API solution?

Accepted Answer

In short: src/ with Domain (entities, value objects), Application (use cases, DTOs, interfaces, validation), Infrastructure (EF Core DbContext, migrations, external services) and Api (controllers/endpoints, middleware, Program.cs) projects; tests/ with unit, integration and functional test projects; shared settings in Directory.Build.props, central package versions, global.json, .editorconfig; Dockerfile and pipelines alongside.

Question 42

Onion vs Clean vs Hexagonal architecture?

Accepted Answer

In short: Same core idea with different vocabulary: business logic at the centre, independent of infrastructure, connected through interfaces. Hexagonal talks about ports (interfaces) and adapters (implementations/drivers); Onion about concentric rings (domain model, domain services, application services, infrastructure/UI); Clean about entities, use cases, interface adapters and frameworks with the explicit dependency rule. In .NET they produce similar project structures.

Question 43

Vertical Slice vs layered architecture?

Accepted Answer

In short: Layered organises by technical concern (controllers, services, repositories) so one feature spans many folders and projects. Vertical Slice organises by feature/use case — request, validation, handler, endpoint together — so changes are local and each slice can choose its data access. Slices can still share a domain model. Vertical slices suit CQRS-style APIs with many independent use cases.

Question 44

Where do you put the repository interfaces and why?

Accepted Answer

In short: In the Application (or Domain) layer — the inner layer defines what it needs ( IOrderRepository ), and Infrastructure implements it. This is Dependency Inversion: the business logic doesn t depend on EF Core or SQL, can be unit-tested with fakes, and the implementation can change without touching use cases.

Question 45

You join a project where controllers contain SQL, business rules and email sending. How do you restructure it safely?

Accepted Answer

In short: Add characterization tests around key endpoints first. Extract business logic into application services/handlers with interfaces for data access and email; move SQL into repositories or query classes in an infrastructure project; introduce DI registration; keep controllers thin (bind, call, return). Do it feature by feature (strangler within the codebase), not as a big-bang rewrite, and agree on the target structure in an ADR.

Question 46

What are microservices? What are their advantages and disadvantages?

Accepted Answer

In short: Small, independently deployable services, each owning one business capability and its own data, talking over HTTP/gRPC or messages. Advantages: independent deployment and scaling, team autonomy, fault isolation, technology freedom per service. Disadvantages: distributed-system complexity (network failures, latency), no cross-service transactions (eventual consistency, sagas), harder testing and debugging, much more DevOps and monitoring work, data duplication.

Question 47

Monolith vs microservices — which would you choose for a new project?

Accepted Answer

In short: Usually start with a modular monolith : one deployable with strict module boundaries and separate schemas. It is faster to build and easier to operate, and the boundaries let you extract services later. Choose microservices when there is a concrete need — independent scaling, separate teams with separate release cycles, very different technology or reliability needs — and the organisation can afford the DevOps cost.

Question 48

How do microservices communicate?

Accepted Answer

In short: Synchronously with REST over HTTP (public/browser APIs) or gRPC (fast internal calls, contracts in .proto ), usually through an API gateway; asynchronously with messages through a broker (RabbitMQ, Azure Service Bus, Kafka) using queues for commands and topics for events. Prefer async for anything that doesn t need an immediate reply — it decouples availability and absorbs load spikes.

Question 49

What is an API gateway and why use one?

Accepted Answer

In short: A single entry point in front of the services. It routes requests, terminates TLS, validates tokens, applies rate limiting and CORS, can aggregate several calls into one response and hides the internal topology from clients. .NET: YARP or Ocelot; Azure: API Management or Application Gateway. A Backend-for-Frontend is a gateway tailored to one client type.

Question 50

What is "database per service" and how do you query data across services?

Accepted Answer

In short: Each service owns its tables; nobody else reads or writes them directly. Cross-service data is obtained by calling the owner s API, by API composition (gateway/BFF calls several services and merges), or by keeping a local read-only copy updated via events (CQRS read model). Reporting usually goes to a separate data warehouse fed by events or CDC.

Question 51

Explain the saga pattern. Choreography vs orchestration?

Accepted Answer

In short: A saga is a sequence of local transactions across services, each with a compensating action to undo it if a later step fails (charge → refund). Choreography: each service listens for events and publishes the next one — simple, decentralised, but the overall flow is hard to see. Orchestration: a central coordinator (state machine) sends commands and tracks state — explicit and easier to monitor and change, but one more component.

Question 52

What is the outbox pattern and what problem does it solve?

Accepted Answer

In short: The dual-write problem: saving to the database and publishing a message are two systems, so a crash between them leaves them inconsistent. With an outbox, the business data and the message are written in one local transaction (message into an Outbox table); a separate relay publishes outbox rows to the broker and marks them sent. Delivery becomes at-least-once, so consumers must be idempotent (often an Inbox table of processed ids).

Question 53

How do you make a service resilient to failures of its dependencies?

Accepted Answer

In short: Timeouts on every call; retries with exponential backoff and jitter for transient, idempotent operations; circuit breaker to fail fast while a dependency is down; bulkheads to limit concurrency; fallbacks/cached data; async messaging so work is queued rather than lost; health checks and auto-restart. In .NET: AddStandardResilienceHandler() / Polly.

Question 54

What is idempotency and why is it important in distributed systems?

Accepted Answer

In short: An operation is idempotent if doing it twice has the same effect as once. Messages are delivered at least once and clients retry on timeouts, so duplicates are normal. Techniques: idempotency keys on POST (store key + result, return the same result on repeat), natural keys/unique constraints, processed-message tables, set operations instead of increment .

Question 55

How do you handle data consistency without distributed transactions?

Accepted Answer

In short: Accept eventual consistency and design for it: keep each aggregate s invariants inside one service and one local transaction; use sagas with compensations for multi-service workflows; outbox + idempotent consumers for reliable events; reservation patterns (reserve stock, confirm later, expire if unpaid); show pending states in the UI. Two-phase commit (MSDTC) is avoided — it blocks and doesn t work across most cloud services and brokers.

Question 56

Explain CQRS. When is it worth it?

Accepted Answer

In short: Separate models for writes (commands that enforce business rules) and reads (queries/views optimised for screens). Worth it when reads vastly outnumber writes, read shapes differ a lot from the write model, or reads and writes need to scale separately. Overkill for simple CRUD. It doesn t require event sourcing or separate databases; a common form is EF Core for commands and Dapper over views for queries.

Question 57

Design a URL shortener.

Accepted Answer

In short: Requirements: create short link, redirect fast, optional expiry and analytics; e.g. 100M links, read-heavy (100:1). API: POST /links → { code } , GET /{code} → 301/302. Key generation: base62 of a unique id (DB sequence or Snowflake-style id) or a random 7-char code with uniqueness check. Store code → URL in a key-value store or SQL with a unique index; cache hot codes in Redis; CDN/edge for redirects. Analytics: publish click events to a queue/stream and aggregate asynchronously so redirects stay fast. Discuss collisions, abuse (rate limits, malware checks) and custom aliases.

Question 58

An order service calls payment, which calls a slow fraud check; under load the whole site times out. What do you change?

Accepted Answer

In short: Cascading failure from synchronous chains. Add timeouts and a circuit breaker around the fraud call, a bulkhead so slow calls can t use every connection, and a fallback (accept low-value orders, flag for review). Better: make the flow asynchronous — accept the order as Pending, send a message for payment/fraud processing, update status by events, and notify the user. Scale the fraud service, and add tracing to prove where the time goes.

Question 59

Customers are charged twice when the client retries a payment request. Fix it.

Accepted Answer

In short: Make the payment endpoint idempotent: the client sends an Idempotency-Key header (GUID per checkout attempt); the server stores the key with the result in the same transaction as the charge; a repeat request with the same key returns the stored result instead of charging again. Also pass an idempotency key to the payment provider (Stripe and others support this) and use a unique constraint on (OrderId, PaymentAttempt).

Question 60

What are design patterns? Name the three GoF categories.

Accepted Answer

In short: Reusable, named solutions to recurring design problems. GoF (1994) lists 23 in three categories: Creational (Singleton, Factory Method, Abstract Factory, Builder, Prototype), Structural (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy), Behavioural (Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor).

Team Lead / Technical Lead — Interview Questions