EM Loop: The Tech Deep-dive Interview
Explore how to confidently present and discuss technical design aspects of past projects during engineering manager interviews. Understand key focus areas like customer impact, data-driven decisions, system observability, and scalability trade-offs. Gain practical tips to prepare and communicate clearly using architecture diagrams and real examples.
In this type of interview, you’re expected to dive into one of your past projects and explain its technical aspects and design in detail. Remember that the interviewer is mainly looking at your capability to confidently hold a tech discussion and discuss things like trade-offs. The interviewer also looks at how well you communicate when presenting difficult concepts. Practice ahead of time by drawing design and architecture diagrams and walking through the design of a past project. Think of it more like an informal system design review presentation or discussion.
Note: Make sure to check with the recruiter which tools (a physical whiteboard, Google Jamboard) will be available to you during the interview and practice with the same tools beforehand. It’s a good idea to practice a mock interview with a friend or to record yourself since you can choose the project beforehand and are given the opportunity to prepare.
Useful tips
A few tips to keep in mind when answering questions during this interview are as follows:
-
Lead with the customer: It’s always good to start with who benefits from the project that your team built and how it solves a customer pain point.
-
Know your numbers: It’s important to highlight how your team used data-driven approaches to make key decisions about the architecture of your system. You should know metrics like Daily Active Users and Concurrent Users for user-facing products and request and error rates for back-end products.
-
Operational excellence: You should prepare to talk about how you monitored the health of your system in production. When drawing out the architecture diagram, mention the auxiliary systems that were needed for observability, such as logging, tracing, monitoring, and alerting.
-
Scalability: This is something the interviewer may not explicitly ask. However, with any company operating at scale, the interviewer will be looking for bottlenecks in your system. For instance, when your workload increases 10x or 100x, can your system scale horizontally, or does it fall over?
Situational examples
To bring these tips to life, here are a few examples of how you might frame your responses during the interview to hit these key signals:
Scenario 1: Leading with the customer and knowing your numbers
Context: The interviewer asks why your team decided to prioritize a complex migration to a new payment gateway.
Example response: "Our primary driver for this architectural shift was a 15% drop-off rate at checkout. Customer support tickets revealed users were frustrated by timeout errors. By analyzing our telemetry, we saw the legacy gateway averaged a 2.5-second latency. We scoped the migration to the new gateway with a strict success metric: reduce latency to under 500ms for our 50,000 daily active users, which ultimately recovered $2M in annual recurring revenue by removing that specific customer friction."
Scenario 2: Operational excellence
Context: The interviewer asks how you ensured stability after launching a critical new microservice.
Example response:"Because this service handled our core booking logic, we couldn't rely on customer complaints to tell us if it was down. During the design phase, I ensured the team built in robust observability. We implemented distributed tracing to track requests across services, and set up synthetic transactions that pinged the core endpoint every minute. If our p99 latency spiked above 200ms or error rates exceeded 0.1%, automated PagerDuty alerts triggered, allowing the on-call engineer to initiate a rollback before a wider customer impact."
Scenario 3: Discussing scalability and trade-offs
Context: You are walking through your architecture diagram and explaining your database choice.
Example Response: "We initially considered a standard relational database for our user activity feed. However, given our projections of scaling from 10,000 to 500,000 concurrent users during our peak holiday events, write-heavy bottlenecks became a massive risk. We explicitly chose to trade the strict ACID compliance of a relational database for the horizontal scalability and fast write speeds of Cassandra. To handle the resulting eventual consistency, which was acceptable for a social feed, we built a background reconciliation queue."