1.How would you design a URL shortener like bit.ly?
mediumHow to approach thisStart with the API contract (POST to create, GET to redirect). Discuss hashing vs. counter-based ID generation, storage trade-offs (SQL vs. KV store), and how you would handle collisions. Mention analytics as a follow-up.
2.Explain the difference between concurrency and parallelism.
easyHow to approach thisConcurrency is about dealing with multiple things at once (structure), while parallelism is about doing multiple things at once (execution). Use a real example: a single-core CPU can run concurrent tasks via context switching, but true parallelism requires multiple cores.
3.Walk me through how you would debug a production issue where latency spikes every 30 minutes.
hardHow to approach thisDescribe a structured approach: check metrics dashboards for correlations (GC pauses, cron jobs, cache expiry), examine logs around the spike windows, use profiling or tracing to isolate the hot path. Mention the importance of reproducing the pattern in staging before deploying a fix.
4.What is the CAP theorem, and how does it affect database choices?
mediumHow to approach thisCAP states that a distributed system can guarantee at most two of: Consistency, Availability, Partition tolerance. Since network partitions are unavoidable, the real choice is between CP (strong consistency, may reject requests) and AP (always available, may serve stale data). Give a concrete example like DynamoDB (AP) vs. Spanner (CP).
5.How do you decide when to refactor code vs. leave it as-is?
easyHow to approach thisTalk about concrete signals: upcoming changes touching the same area, bug frequency in that module, onboarding friction for new team members, or measurable complexity (cyclomatic complexity, file length). Avoid refactoring code that works, is stable, and nobody needs to change.
6.Describe the trade-offs between microservices and a monolith.
mediumHow to approach thisMonoliths are simpler to develop, test, and deploy but can become unwieldy at scale. Microservices enable independent deployment and scaling but add network complexity, data consistency challenges, and operational overhead. The right choice depends on team size and deployment frequency.
7.What happens when you type a URL into your browser and press Enter?
mediumHow to approach thisWalk through the full chain: DNS resolution, TCP handshake, TLS negotiation, HTTP request, server processing, response, HTML parsing, DOM construction, resource loading (CSS, JS, images), rendering, and paint. Focus on the parts most relevant to your role.
8.How would you handle a situation where a critical feature needs to ship but the code has known technical debt?
easyHow to approach thisDescribe a pragmatic approach: ship with the debt but document it explicitly, set a concrete timeline for follow-up, and add monitoring for the risky areas. Explain how you would communicate the trade-off to stakeholders with data on the risk.
9.Explain how you would design a rate limiter for an API.
hardHow to approach thisDiscuss token bucket or sliding window algorithms. Cover where the limiter sits (middleware, gateway, per-service), storage (in-memory vs. Redis for distributed), key design (per-user, per-IP, per-endpoint), and what response to return (429 with Retry-After header).
10.What is your approach to writing tests? How do you decide what to test?
easyHow to approach thisDescribe the testing pyramid: many unit tests for business logic, fewer integration tests for service boundaries, minimal E2E tests for critical user flows. Test behavior, not implementation. Prioritize tests for code that handles money, auth, and data mutations.
11.How would you migrate a database schema with zero downtime?
hardHow to approach thisExplain the expand-contract pattern: add new columns/tables first (expand), deploy code that writes to both old and new schemas, backfill historical data, switch reads to new schema, then remove old columns (contract). Emphasize that each step must be independently deployable.
12.Describe a time when you had to make a significant architectural decision. What was your process?
mediumHow to approach thisUse a real example. Outline: gathering requirements, identifying constraints, evaluating 2-3 options with trade-offs written down, getting input from the team, making the call, and documenting the decision (ADR). Interviewers care about your process more than the specific choice.