Engineering Manager Interview Questions: The Complete Guide

Interviewing for an engineering manager role means stepping into a position that requires you to bridge technical expertise and leadership. Hiring managers want to see that you can lead teams, deliver projects on time, and align engineering with business goals. This guide walks you through the most common engineering manager interview questions and answers you’ll encounter, plus strategies for tackling behavioral, technical, and strategic questions with confidence.

Common Engineering Manager Interview Questions

How do you balance technical debt with feature development?

Why they ask: This question reveals your strategic thinking and how you prioritize competing demands. It’s a reality every engineering manager faces—you can’t do everything at once. Interviewers want to see if you understand the long-term impact of letting technical debt pile up, and whether you can communicate that impact to non-technical stakeholders.

Sample answer: “I categorize technical debt into three buckets: ‘must fix now’ if it’s blocking progress or creating security risks, ‘fix within a quarter’ for items that slow development but aren’t critical, and ‘long-term observation’ for things we monitor. In each sprint, we allocate about 20% of capacity to addressing the immediate debt. When I present this to stakeholders, I focus on the business impact—how debt increases the time to ship new features and drives up maintenance costs. In my last role, this approach helped us reduce deployment time by 30% over six months while still shipping customer-facing features on schedule.”

Personalization tip: Adjust the percentage based on your actual experience, and mention a specific metric or outcome that shows the value of managing technical debt.

Tell me about your management style and philosophy.

Why they ask: This open-ended question gauges whether your leadership approach aligns with the company’s culture. They’re also assessing self-awareness—do you know yourself as a leader?

Sample answer: “I’d call my style ‘collaborative with clear ownership.’ I believe engineers perform best when they understand the why behind their work and have autonomy in how they solve problems. I set context and goals, then trust my team to execute. That said, I’m very hands-on with code reviews and technical discussions—I need to stay in the technical trenches to earn credibility. I also prioritize one-on-ones with each person on my team every two weeks, where we talk about their growth, blockers, and career aspirations. I’ve found this builds trust and helps me catch problems early.”

Personalization tip: Share a specific example of how your philosophy has paid off—better retention, faster shipping, higher team morale. Make it concrete, not theoretical.

How do you handle a situation where a team member isn’t meeting expectations?

Why they ask: This tests your ability to manage performance issues with maturity and fairness. They want to know if you’re direct but empathetic, and if you try to develop people before resorting to harder actions.

Sample answer: “First, I make sure I understand the root cause. Sometimes underperformance signals misalignment, personal struggles, or skill gaps rather than lack of effort. I’d have a private conversation, be specific about what I’m observing, and ask what’s going on. Once I understand the issue, we create a concrete improvement plan together. For example, I had an engineer who was shipping code with more bugs than usual. Turned out they were new to the codebase and felt overwhelmed asking for help. We paired them with a mentor, increased code review feedback, and within a month, their output quality was excellent. If someone isn’t improving after we’ve tried to support them, then we have a harder conversation about fit.”

Personalization tip: Share a real example where you helped someone improve, or a case where you made the difficult call to part ways. This shows you’ve actually dealt with the situation.

How do you stay current with technology trends?

Why they ask: They want to know if you’re intellectually curious and if you invest in continuous learning. As an engineering manager, you’re expected to help guide technical decisions, so staying informed matters.

Sample answer: “I’m intentional about this. I follow key engineering blogs and newsletters—I subscribe to The Pragmatic Engineer and a few others—and I attend at least one major conference a year, usually something like QCon or a cloud-focused event. I also encourage my team to share knowledge during our weekly tech talks, which keeps me in the loop on what’s emerging. Recently, I dug into observability tools because I knew we needed to upgrade our monitoring. I spent a weekend working through tutorials, then brought recommendations to the team. I think staying current doesn’t mean being an expert in everything, but it means having enough context to make informed decisions and ask smart questions.”

Personalization tip: Mention specific resources you actually use, and a recent technology or trend you’ve dug into. Avoid listing generic learning methods.

How would you approach onboarding a new engineer to your team?

Why they ask: This reveals your organizational skills and your investment in team success. Onboarding significantly impacts retention and time-to-productivity, so they want to see a structured, thoughtful approach.

Sample answer: “I treat onboarding as a 30-60-90 day process. In the first 30 days, I pair new hires with a mentor who helps them get their environment set up, understand our codebase structure, and ship their first small fix—something that gets merged quickly to build confidence. I also have a one-on-one with them every other day during the first week. By day 30, they should understand our architecture and coding standards. In the next 60 days, they own small features end-to-end, with plenty of code review feedback. By 90 days, they’re contributing independently to our roadmap. I track this progress and adjust if someone needs extra support. I also make sure to solicit feedback from their mentor and the team—onboarding is a two-way street.”

Personalization tip: If you have metrics like “average time to first PR merge” or “ramp-up time to full productivity,” share those. Real numbers beat general statements.

How do you prioritize when everything feels urgent?

Why they asks: Priorities are constantly shifting in engineering. They want to see if you can make strategic trade-offs and communicate those decisions clearly.

Sample answer: “I use a framework that considers business impact, technical dependencies, and team capacity. I check in with product leadership about which features drive the most value, but I also factor in what needs to happen first from a technical perspective. If we have three equally urgent requests and limited bandwidth, I’ll lay out the trade-offs: ‘If we do A first, B ships two weeks later. If we do B, A and C slip.’ I present this to the relevant stakeholders and let them decide. Once we align on priority, I communicate it clearly to the team so everyone understands the reasoning. This transparency reduces frustration. I also keep a backlog of important things that aren’t urgent yet—technical improvements, tooling, documentation—so we’re not always in reactive mode.”

Personalization tip: Reference a specific decision you made and how it played out. Show that you think about trade-offs holistically.

How do you measure the success of your team?

Why they ask: They’re probing your understanding of metrics and outcomes. Strong engineering managers tie their team’s work to business results, not just output metrics like lines of code or velocity points.

Sample answer: “I track a mix of metrics. On the engineering side, I look at deployment frequency, lead time for changes, and mean time to recovery from incidents—these tell me how efficient we are. I also monitor code quality through defect rates and technical debt indicators. But more importantly, I align these with business outcomes. I work with product to track feature adoption and customer impact. For a recent project, we shipped a performance improvement that reduced load times by 40%, which directly improved user retention. I also measure team health through one-on-one feedback, retention rates, and an internal survey on psychological safety. If my team is shipping fast but people are burning out, that’s not success. I report on these metrics monthly to leadership.”

Personalization tip: Pick 4-5 metrics you’ve actually tracked and can speak to intelligently. Show the connection between engineering work and business value.

Tell me about a time you had to make a difficult decision that your team disagreed with.

Why they ask: This is a behavioral question testing your conviction and communication skills. They want to see if you listen, but ultimately make principled decisions and can bring a skeptical team along.

Sample answer: “We were at an inflection point where we needed to deprecate a legacy API that some internal services still relied on. Most of the team wanted to keep supporting both the old and new APIs indefinitely. I understood their concern—it felt safer. But I’d run the math: maintaining two systems was slowing us down and creating bugs. I presented the analysis to the team: the effort required versus the shrinking number of services using the old API. I acknowledged their concerns about potential migration risks. Then I laid out a specific plan: we’d migrate the last three services in a controlled way, with paired programming and extensive testing. We also built in a rollback plan. By being transparent about the trade-offs and giving them a clear playbook, the team shifted from skeptical to collaborative. The migration went smoothly, and we saved significant time the following quarter.”

Personalization tip: Choose a decision where you had legitimate pushback, not a case where you were obviously right. Show that you listened and refined your approach based on feedback.

How do you foster innovation on your team?

Why they ask: Innovation and technical excellence are competitive differentiators. They want to see if you actively create space for it or if you’re purely in reactive, delivery mode.

Sample answer: “I dedicate 10-15% of our sprint capacity to what I call ‘innovation work’—experiments, new tools, proofs of concept. Every two weeks, we have a ‘tech talk’ where anyone can share something they’ve been working on or learning. I also run quarterly ‘innovation sprints’ where people can self-organize around ideas they’re excited about. A couple of years ago, an engineer had an idea about using containers to speed up our local development setup. We gave them a week to prototype it, and it ended up saving every engineer on my team 3-4 hours per week. When ideas pan out, I make sure leadership knows it was the team’s initiative, not just mine. I also celebrate ideas that don’t work—failure is part of learning.”

Personalization tip: Share a specific innovation that came from your team, the impact it had, and how you supported it. Avoid sounding like you imposed innovation from the top down.

How do you handle conflict between team members?

Why they ask: Engineering teams have strong personalities and technical disagreements. They want to see if you can mediate fairly and keep conflicts from festering or derailing the team.

Sample answer: “I address conflicts early and privately. If two engineers are butting heads over a technical approach, I’ll usually request a meeting with both of them. I let each person explain their position, then I try to reframe it from ‘who’s right’ to ‘what’s best for the project.’ Sometimes the answer is clear once you dig in. Other times, I’ll propose we time-box an experiment—both approaches have merit, so we try one and measure the results. I also watch for personal friction versus technical disagreement. If it’s personal, that’s a different conversation. I make it clear that I expect people to be respectful and to assume good intent. If tension is affecting the team’s morale, I’ll address it more directly. The goal is always to move forward together, not for someone to ‘win.’”

Personalization tip: Describe a specific conflict, how you intervened, and what happened. Real examples carry more weight than generic conflict resolution frameworks.

What’s your approach to code reviews?

Why they ask: Code reviews are a daily reality in engineering teams. They want to understand your philosophy on quality, mentoring, and psychological safety. This also signals whether you’re hands-on technically.

Sample answer: “I think of code reviews as a mentoring opportunity, not a gate-keeping exercise. I look for functional correctness, adherence to our standards, and whether there are simpler ways to solve the problem. But I’m careful about how I phrase feedback—‘Consider using a map here instead of a loop for clarity’ rather than ‘This is inefficient.’ I also review code from my team regularly, especially for risky or cross-cutting changes. I want to stay in touch with the codebase and catch architectural issues early. I also make sure reviews happen within a day or two—letting PRs sit for a week kills momentum. For junior engineers, I’m more thorough and use reviews as a learning touchpoint. For senior people, I focus on higher-level design questions. I also celebrate good code patterns in our team chat to reinforce what we’re optimizing for.”

Personalization tip: Mention a specific standard or practice your team follows, and how you balance thoroughness with shipping velocity.

How would you scale an engineering team from 5 to 15 people?

Why they ask: This tests your thinking on hiring, structure, culture, and delegation. Scaling is hard, and most growing companies struggle with it. They want to see if you’ve thought about it.

Sample answer: “Scaling is less about hiring and more about intentionality. With 5 people, you can be informal. With 15, you need structure. I’d approach it in phases. At 8-10, I’d probably bring on a tech lead who can help with mentoring and architecture discussions, freeing me up for hiring and longer-term strategy. I’d also establish clear coding standards, better documentation, and more structured communication—daily standups shift from conversational to more asynchronous. We’d also need to think about on-call rotations and runbook documentation. At 15, I’d likely hire a second engineering manager to lead a sub-team, and we’d formalize our sprint process and architecture reviews. Throughout, I’d protect our culture—I’d be deliberate about who we hire, and I’d maintain my one-on-ones even as the team grows. I’ve seen too many managers scale their team but lose their connection to it.”

Personalization tip: If you’ve experienced scaling, share the numbers and what worked. If not, root your answer in what you’ve observed at companies you’ve worked at or studied.

Describe your experience with hiring and building a team.

Why they ask: Hiring is one of the highest-leverage things an engineering manager does. They want to see if you’re thoughtful about it and whether you’re building teams or just filling seats.

Sample answer: “I treat hiring as one of my most important responsibilities. I start by defining what we actually need—not just ‘a senior backend engineer’ but what specific gaps we’re filling and what would make someone successful here. I’m involved in every stage: I write job descriptions, I screen candidates, I conduct technical interviews, and I always do the final conversation with finalists. I’m looking for both technical capability and cultural fit—do they care about learning? Are they collaborative? I also deliberately hire for diversity in background and thinking. For onboarding, I have a structured plan to help people ramp quickly. I also stay in touch with our recruiting team and keep a running list of potential candidates I meet at conferences or through the network. Building a strong team isn’t a one-time event; it’s ongoing.”

Personalization tip: Mention specific numbers—how many people you’ve hired, your interview process, and any outcomes (retention rates, or a standout hire who had unexpected impact).

How do you communicate with non-technical stakeholders?

Why they ask: Engineering managers are translators between two worlds. They want to see if you can explain technical concepts in business terms and advocate for your team.

Sample answer: “I learned early that stakeholders don’t care about our technology stack—they care about timelines, costs, and impact. I translate technical work into those terms. Instead of ‘We need to refactor our authentication system,’ I say, ‘We’re investing two weeks to reduce our authentication-related bugs by 80% and improve login performance, which will reduce support tickets and improve user experience.’ I also make sure to communicate what we can and can’t do realistically. If product wants to ship a feature in two weeks and it would realistically take four, I say so upfront and explain why. I propose alternatives: ship a scaled-back version in two weeks, or do it fully in four. I also bring leadership into technical decisions that have business implications. If we’re choosing between two architectures with different trade-offs, I explain the pros and cons in business language—speed to market, maintenance burden, scalability limits.”

Personalization tip: Share an example of a technical decision you had to explain to non-technical leaders and how you framed it.

Behavioral Interview Questions for Engineering Managers

Behavioral questions ask you to recount specific past experiences. Use the STAR method: Situation (the context), Task (your responsibility), Action (what you did), Result (the outcome). The key to strong behavioral answers is specificity—concrete details beat vague generalities.

Tell me about a time you had to deliver a project on a tight deadline.

Why they ask: They want to see your project management skills and how you handle pressure without sacrificing quality or burning out your team.

STAR framework:

• Situation: Set the scene. What was the project, and why was the deadline tight? (e.g., “We were launching a new payment flow two weeks before a major holiday, and the timeline was non-negotiable because of business goals.”)
• Task: What was your specific responsibility? (e.g., “I was managing a team of 6 engineers responsible for the backend and integrations.”)
• Action: What did you do to make it work? This is where specifics shine. Did you simplify scope? Bring in extra resources? Add team members temporarily? Restructure the work? (e.g., “I met with product to identify the absolute MVP—what was required versus nice-to-have. We cut scope by 30%. I also paired junior engineers with seniors to unblock them faster, and I increased code review frequency to catch issues early. I also made sure we had a 48-hour buffer before launch for final testing.”)
• Result: What happened? Ship on time? Quality metrics? Team morale? (e.g., “We shipped on time with zero critical bugs. The team was tired but proud. I made sure to give them a day off the following week and celebrated the win publicly.”)

Tip: Don’t present yourself as a hero who saved the day alone. Highlight how you enabled your team to perform under pressure. Also, mention what you learned—this shows reflection.

Describe a situation where you had to give critical feedback to a senior engineer.

Why they ask: Senior engineers can be prickly, and managers often avoid giving them feedback. They want to see if you can manage up-and-across the organization tactfully.

STAR framework:

• Situation: Who was this person, and what was the issue? Be factual, not judgmental. (e.g., “I had a senior engineer who was highly technically skilled but whose code reviews were sometimes dismissive of newer engineers’ ideas. It was creating friction.”)
• Task: What needed to happen? (e.g., “I needed to give him feedback without making him defensive or losing a valuable team member.”)
• Action: How did you approach it? Private setting? Specific examples? Connection to team values? (e.g., “I asked him for a one-on-one and shared specific examples of recent code review comments that came across as harsh. I acknowledged his expertise and said I valued his technical leadership, then explained how his approach was affecting team morale and psychological safety. I asked for his perspective. He admitted he didn’t realize the impact.”)
• Result: What changed? Did behavior improve? (e.g., “He started mentoring junior engineers more intentionally. Within a couple of months, I noticed the team was more collaborative. He also became a sponsor for one of our newer hires, which was great.”)

Tip: Show you care about the person, not just the problem. Also, admit if the conversation was hard—that’s realistic. Avoid sounding like you “fixed” them.

Tell me about a time you made a mistake as a manager and how you handled it.

Why they ask: This tests self-awareness and accountability. Perfect managers don’t exist. They want to see if you can acknowledge errors, learn, and communicate transparently with your team.

STAR framework:

• Situation: What mistake did you make? (e.g., “I committed my team to a project timeline without fully understanding the technical complexity. We missed the deadline by three weeks.”)
• Task: How did it affect people? (e.g., “My team had committed to the timeline publicly, so they felt pressure and worked extra hours. It also affected downstream teams who were depending on our delivery.”)
• Action: What did you do about it? (e.g., “I immediately met with my team, apologized for not asking better questions upfront, and took responsibility for the miss. I then worked with the teams we’d delayed to reset expectations. I also changed my process—now I always do a technical feasibility check before committing to timelines, and I build in buffer time.”)
• Result: How did it turn out? What did you learn? (e.g., “The teams understood, and we rebuilt trust through delivering the next project on time. I also mentored another manager on the importance of technical due diligence. The experience made me a more thoughtful planner.”)

Tip: Pick a real mistake, not a humble-brag disguised as an error. (“I worked too hard”) Show genuine learning and how you applied it.

Describe a time you had to advocate for your team or push back on leadership.

Why they asks: They want to see if you’re a team advocate, not just a leadership mouthpiece. Can you push back when it’s right?

STAR framework:

• Situation: What was the situation where your team’s interests conflicted with what leadership wanted? (e.g., “Leadership wanted to add three new high-priority features to the upcoming quarter, but my team was already at 90% capacity and we had significant technical debt.”)
• Task: What was at stake? (e.g., “I needed to protect my team from burnout and degradation of our systems, but I also couldn’t just say no to leadership.”)
• Action: How did you handle it? (e.g., “I asked for a meeting with the product lead and engineering leadership. I brought data: current velocity, quality metrics, on-call incidents related to technical debt. I presented three scenarios: ‘If we add three features, we hit capacity and quality drops.’ ‘If we do two features and dedicate 20% to tech debt, we sustain quality.’ ‘If we want to keep quality and add features, we need to add a person.’ I also offered to prioritize which features would have the most business impact.”)
• Result: What did they decide, and how did your team fare? (e.g., “We went with scenario two. The team shipped great work, quality stayed strong, and we reduced technical debt. It proved that pushing back with data and respect was more effective than just saying no.”)

Tip: Show that you advocated thoughtfully, not just stubbornly. Include data. Also, respect the decision even if you didn’t get everything you wanted—that shows maturity.

Tell me about a situation where you had to rapidly learn something new to lead your team effectively.

Why they ask: Technology and business contexts change. They want to see if you’re curious and adaptable, and if you’re humble about knowledge gaps.

STAR framework:

• Situation: What did you need to learn? Why? (e.g., “My company decided to migrate from a monolithic architecture to microservices, and I’d spent most of my career in monolithic systems. I needed to understand the trade-offs and challenges to guide my team.”)
• Task: What was your responsibility? (e.g., “I needed to make informed decisions about architecture, help with design reviews, and support my team through the transition.”)
• Action: How did you learn? Be specific. (e.g., “I read three books on microservices, took an online course, and brought in a consultant for a few weeks. I also had deep conversations with architects at other companies. Most importantly, I stayed in the trenches with my team—I reviewed designs, attended tech talks, and asked a lot of questions. I didn’t pretend to know things I didn’t.”)
• Result: How did it pay off? (e.g., “I was able to anticipate technical challenges and help the team avoid pitfalls. The migration took about 18 months instead of the feared 2+ years, and the team felt supported rather than abandoned.”)

Tip: Emphasize that you didn’t know everything, but you were intentional about closing the gap. Show humility and a bias toward action.

Describe a time you had to improve team performance or deliver a project with a struggling team.

Why they ask: Can you diagnose problems and drive improvement? Are you a fixer, or do you just accept underperformance?

STAR framework:

• Situation: What was the performance issue? (e.g., “My team was consistently missing sprint commitments. Our velocity was unpredictable, and morale was declining.”)
• Task: What did you need to achieve? (e.g., “I needed to understand root causes and improve predictability without pushing people harder.”)
• Action: How did you investigate and fix it? (e.g., “I conducted a retrospective specifically focused on blockers. I found that we were getting interrupted constantly by production incidents, which derailed sprints. I also discovered that our sprint planning was too optimistic because we weren’t accounting for code review time. I implemented several changes: we assigned a rotating on-call engineer to handle incidents, we reduced their sprint capacity by 30%. In planning, we now reserve 25% for reviews, documentation, and unknowns. I also started daily standups to catch blockers earlier instead of discovering them mid-sprint.”)
• Result: What improved? (e.g., “Within two sprints, our velocity became more predictable. Sprint success rate went from 65% to 90%. More importantly, team morale improved because we stopped overpromising. People started volunteering for stretch projects again.”)

Tip: Show diagnostic thinking, not just firefighting. You identified root causes, not just symptoms. That’s what separates good managers from reactive ones.

Technical Interview Questions for Engineering Managers

Technical questions for engineering managers focus on system design, architecture, trade-offs, and technical judgment—not coding. You’re being assessed on whether you can think strategically about technical problems and guide your team toward sound decisions.

Walk me through how you’d design the architecture for a new microservices-based platform.

Why they ask: This tests your technical depth and whether you think about scalability, maintainability, and team structure together.

Framework for answering:

1. Ask clarifying questions first. What’s the scale? (1000 requests/sec or 1M?) What’s the user profile? What’s the latency requirement? This shows you think about constraints.
2. Start with the business context. Why microservices? What problem does it solve? (Faster feature velocity? Independent scaling? Organizational structure?) Bad technical decisions often come from applying solutions to problems they don’t solve.
3. Outline the major components. API gateway, auth service, core business services, data layer, monitoring/observability. Explain the trade-offs of your choice.
4. Address cross-cutting concerns: How do services communicate? (Sync REST or async events?) How do you handle distributed tracing? Where’s the data consistency story? What happens if a service goes down?
5. Think about the team. If you’re splitting into microservices, you’re also implicitly splitting the team. How many teams do you expect? How do they own services?
6. Acknowledge trade-offs. Microservices aren’t always the answer. They introduce complexity—distributed tracing, testing, deployment. What are you accepting with this approach?

Sample answer structure: “For a platform processing 10k requests per second with B2B customers who need 99.9% uptime, I’d use microservices. I’d start with an API gateway handling auth and rate-limiting, then core domain services: user management, billing, the main product logic. Each service has its own database—yes, this creates data consistency challenges, but it gives us independent deployment and scaling. I’d use Kafka for async events between services, which makes integration looser and more testable. For orchestration, I’d use Kubernetes. I’d invest heavily in observability from day one—distributed tracing with something like Jaeger, structured logging, metrics. On the team side, I’d expect teams to own services end-to-end. This works best if you have senior engineers who can make independent technical decisions. The big trade-off is operational complexity—you’re managing more moving parts. For a small startup, this is overkill. For something at scale, it’s worth it.”

Tip: Show you think about trade-offs, not just technology. Also, tie it back to team structure—that shows you’re thinking holistically.

How would you approach reducing a high defect rate in production?

Why they ask: This is real-world and common. They want to see your diagnostic thinking and whether you reach for technology fixes or consider process and human factors.

Framework for answering:

1. Define the problem precisely. How many defects? What’s the trend? Are they in specific areas or random? Are they regressions or new issues?
2. Investigate root causes. Don’t jump to solutions. Is it a testing gap? Are engineers shipping without running tests? Is the codebase so messy that changes have unexpected effects? Are you deploying too fast to catch issues?
3. Propose a multi-pronged approach. Rarely is there one fix. You might add automated testing, improve code review rigor, slow down deployment cadence short-term, or refactor high-risk areas.
4. Measure the impact. How will you know if it’s working? Defect count? Defect severity? Time to fix?

Sample answer structure: “I’d start by analyzing the defects. Where are they? What’s the pattern? If they’re mostly in one service or area, that’s a clue—maybe complexity or insufficient testing. I’d look at our testing coverage—what’s not tested? I’d also ask: are engineers running tests locally before pushing? Are reviews catching issues? Once I understand the root causes, I’d address them. Maybe it’s adding integration tests. Maybe it’s slowing down our deployment pipeline short-term to add a staging environment. Maybe it’s refactoring a particularly messy module. I’d also make sure the team understands the cost of defects—if they see it as someone else’s problem, nothing changes. I’d measure progress weekly: defect count, types, time to resolution. I’d aim for a specific target—‘reduce defects by 50% in two months’—and communicate progress.”

Tip: Show a scientific approach, not blame. Also, acknowledge that some fixes take time (refactoring) versus quick wins (testing).

How do you evaluate whether to build something internally or use a third-party vendor solution?

Why they ask: This is a common engineering manager decision. They want to see your judgment on make vs. buy.

Framework for answering:

1. Define the decision clearly. What exactly are you deciding on? (Hosting, monitoring, payment processing, testing framework?)
2. Consider time-to-market. How fast do you need it? Can you build it in the timeframe required?
3. Think about core competency. Is this a competitive differentiator, or just infrastructure? If it’s not core to your product, the bar for building is higher.
4. Calculate total cost of ownership. Vendor cost is obvious. Internal build includes engineering time, maintenance, on-call, scaling, upgrades. For many things, this is higher than you initially estimate.
5. Assess risk. What if the vendor goes down? Can you migrate? What if you need deep customization? Can you do it internally?
6. Think about your team. Do they have the skills? Do they want to? Or would they rather focus on product?

Sample answer structure: “For critical infrastructure like payment processing, I’d almost always use a vendor unless I had a compelling reason not to—Stripe is really good at this, and building it ourselves would eat months of engineering time plus create ongoing risk. For something like our deployment pipeline or internal analytics tools, it’s different. These are things we might build because they’re unique to our architecture or workflows, and building gives us control. I’d weigh: Can we ship fast enough with a vendor? What’s the total cost? Is there vendor lock-in risk? For our logging solution, we evaluated three vendors but ultimately open-sourced ELK because we have the DevOps expertise and wanted deep customization. For our CI/CD, we use CircleCI as a vendor because building it ourselves would be a resource sink with uncertain payoff. I always review these decisions quarterly—what was the right call then might be wrong now as we scale.”

Tip: Show you’re thinking about trade-offs, not technology for its own sake. Also, mention that you revisit decisions as circumstances change.

Tell me about a complex technical problem you’ve had to solve. How did you approach it?

Why they ask: This is open-ended and tests your technical thinking, collaborative instincts, and how you communicate about complex topics.

Framework for answering:

1. Set context concisely. What was the problem, and why did it matter? (e.g., “Database query performance was degrading as data volume grew. Page loads were hitting timeouts.”)
2. Explain your investigation. How did you diagnose the issue? (e.g., “I worked with the database specialist to run query analysis. We found N+1 queries in a hot path. We also discovered that indexes weren’t being used optimally.”)
3. Describe the approach you recommended. What options did you consider? What trade-offs? (e.g., “We could refactor queries, add indexes, denormalize data, or implement caching. Indexes had the fastest ROI. Caching was riskier because of staleness. Denormalization made sense for certain queries.”)
4. Highlight collaboration. Did you work with other engineers, DBAs, or teams? Good managers involve others, not just solve it alone.
5. Talk about the outcome and learning. What fixed it? How much did it improve? What did you learn about your system?

Sample answer structure: “We were experiencing P99 latency spikes when users created reports. Our database queries were scanning millions of rows. I paired with our senior backend engineer to analyze the query patterns. We discovered that we were fetching user data in a loop, then falling back to table scans when indexes weren’t hit. We tried three approaches: refactoring the query to join properly instead of looping, adding indexes on the right columns, and implementing a caching layer. We benchmarked all three. The combination of query refactoring plus indexes gave us a 10x improvement with minimal risk. We implemented it over two sprints. The learning: we needed to invest in query analysis tooling so we’d catch these issues earlier. We’ve since added query performance monitoring to our CI/CD—if a PR introduces a query that’s slower than a threshold, it fails.”

Tip: Show that you investigated before jumping to solutions. Also, emphasize collaboration—you didn’t solve it alone. Finally, talk about systemic learning.

If you joined our company today and noticed that our technical practices were outdated, how would you approach modernizing them?

Why they ask: This tests your political skill, your judgment about which battles to fight, and whether you’re an arsonist or a builder.

Framework for answering: