Explain technical details of a past project

When asked for technical details, your goal is to **go deeper, but stay structured**. You want to show depth without rambling. ### Use a layered approach 1. **Start with architecture** - Draw or describe the main components and how they interact: clients, services, databases, queues, caches, external dependencies. - Mention the key technologies (languages, frameworks, data stores, infra) and why they were chosen. Example: > "At a high level, we have clients sending requests to a load-balanced API service. The API service publishes events to Kafka, which are then processed by a set of worker services. Results are stored in PostgreSQL for OLTP and in a columnar warehouse for analytics. We chose Kafka for durability and scaling consumers independently." 2. **Zoom into the part you owned** - Focus on the components you designed or implemented. - Explain data flows, important algorithms, and key abstractions. Example: > "I owned the worker service that consumes from Kafka. It uses a pool of consumers to read messages, validates and transforms them, and then batches writes to the warehouse. I implemented batching with size and time thresholds to balance throughput and latency." 3. **Discuss trade-offs and design decisions** Interviewers care about **how you think**, not just what you built: - Why this database vs. another? - Why this consistency or partitioning model? - Performance vs. simplicity decisions. Example: > "We considered using a document store, but chose a relational database because we needed transactional guarantees and complex joins for some dashboards. We accepted slightly higher write latency in exchange for better consistency and query capabilities." 4. **Address reliability, performance, and observability** - How you handled failures (retries, idempotency, circuit breakers). - Performance tuning (indexes, caching, concurrency control). - Monitoring and alerting (metrics, logs, traces, dashboards). Example: > "To handle transient failures, we implemented retry with exponential backoff and made our writes idempotent using a unique event ID. We exposed metrics like processing latency and DLQ size to Prometheus and created alerts when they crossed thresholds." 5. **Mention significant issues and how you debugged them** - A production incident or bug that required deep technical understanding. - How you identified root cause and what you changed. Example: > "We once saw a sudden increase in processing latency. Using our dashboards, we traced it to a hot partition in Kafka due to a skewed partition key. I changed the partitioning strategy to distribute load more evenly and added a check in CI to detect skew in test data." ### Tips - Keep jargon under control; explain briefly if something is nonstandard. - Periodically pause and ask: *"Should I go deeper on any of these parts?"* - Tailor depth to the role (e.g., more on networking and caching for infra roles; more on data modeling and queries for data roles).