Engineering Manager Interview Questions and Answers

SQL databases store data in tables with a fixed schema. They support joins and ACID transactions (changes are all-or-nothing), and they scale up easily. NoSQL is a group of stores (document, key-value, wide-column, graph). They have flexible schemas and scale out easily. They often give up strict consistency for availability and speed.

Choose by access pattern:

• Related data, reports, and multi-row transactions (payments, orders): SQL.
• Huge write volume, simple lookups by key, or document shapes that change often (sessions, catalogues, event logs): NoSQL.
• Many teams use both. PostgreSQL holds the main data, and Redis or a document store handles specific jobs.

Do not choose NoSQL only because it sounds scalable. One well-indexed PostgreSQL server handles far more than most products ever need. Giving up joins and transactions has a real cost.

What they are checking: Whether you choose storage from access patterns and consistency needs, not hype

Stateless means each request carries everything the server needs. That includes the identity token, parameters, and body. The server keeps no client session between requests.

Why it matters:

• Any server can handle any request. A load balancer can use simple round robin, and you can add or remove servers freely.
• A crashed server loses no user session.
• Requests are easier to cache, log, and replay.

State does not disappear. It moves. Login usually uses a signed token such as a JWT. Saved data lives in a shared database or cache. If you must keep a session, store it in Redis, not in server memory. The cost is slightly larger requests, because credentials travel with each call.

What they are checking: Whether you connect a REST rule to a practical scaling result

DORA metrics measure how well a team delivers software:

Vertical scaling (scale up) means giving one machine more CPU, memory, or disk. It is simple and needs no code change. But there is a hardware limit, resizing often needs downtime, and you still have one point of failure.

A tech lead owns the technical direction of the team's work. An engineering manager owns the people and the way the team delivers.

I plan the first 90 days before the person arrives.

I give feedback soon after the event, in private. I focus on behaviour and impact, not personality.

A blameless postmortem is a written review of an incident. It looks at how the system and process allowed the failure. It does not look at who made the mistake.

People mostly stay for meaningful work, growth, freedom to decide, fair treatment, and a good manager. Pay matters, but it rarely fixes the others.

A collision happens when two different keys give the same bucket index after hashing. The hash space is limited, so collisions cannot be avoided.

A good review culture finds bugs early, spreads knowledge, and stays respectful.

Start with the team and the problem, not the trend. A well-structured monolith is the right default for a small team and a new product. Microservices help when separate teams need to deploy and scale parts of the system on their own.

My rule: split only when there is a clear pain. Examples are teams blocking each other on releases, one part with very different scaling needs, or a strict need to isolate faults. Before that, build a modular monolith with clean boundaries. Then a later split is cheap. The common failure is a distributed monolith. It has many services that still deploy and fail together. You pay all the cost and get none of the benefit.

What they are checking: Whether you weigh team and operations cost, not just technical fashion

First find what is worth caching. Good data is read often, costly to compute, and fine to be a little old. Then pick a pattern and a freshness rule.

Common patterns:

• Cache-aside: the app checks the cache first. If the data is missing, it reads the database and fills the cache. This is the most common and the simplest.
• Write-through: a write updates the cache and the database together. Reads are fresh, but writes cost more.
• Write-behind: a write goes to the cache and is saved later. It is fast, but you can lose data.

Ways to remove old data, from simplest:

• A short TTL (time to live). You accept data that is a little old.
• Delete or update the entry on every write.
• Versioned keys (for example product:42:v7), so old entries just expire.

Also plan for a cache stampede. This is when a popular key expires and thousands of requests hit the database at once. Combine duplicate requests, or add random time to each TTL. Use several cache layers (CDN, app cache, database buffer). Measure the hit ratio. A cache below about 80 percent hit rate often needs a new design.

What they are checking: Whether you know the patterns, the trade-offs of old data, and failures such as stampedes

Treat debt as a visible, ranked backlog, not a vague complaint.

• Sort it: debt that slows delivery every day, debt that risks outages or security, and cosmetic debt. Only the first two get real time.
• Make it measurable. Link each item to a cost, such as incident count, extra days per feature, or lost build time.
• Reserve capacity: a steady share of each sprint (often 15 to 20 percent). Then you never need a special fight with product.
• Pay it down with features. Refactor the area you are about to change. Avoid big standalone rewrites that show nothing.
• Stop creating it. The definition of done includes tests, review, and docs. Planned shortcuts are logged with an owner and a payback date.

With stakeholders I use business words. "This module adds about three days to every checkout feature" works far better than "the code is ugly".

What they are checking: Whether you can balance debt and delivery using data and the right words for stakeholders

A 1:1 belongs to the team member, not to the manager's status agenda.

• Cadence: weekly or every two weeks, 30 minutes, rarely cancelled. Cancelling tells the person they are low priority.
• Agenda: they own it, and I keep a shared doc. If they have nothing, I ask standard questions. What is blocking you? What gives you energy or drains you? How is your workload? What feedback do you have for me?
• Rhythm: mostly current work and blockers. Once a month, talk about career growth and goals.
• Feedback: give small, specific feedback often, so reviews hold no surprises. Ask for feedback on me too.
• Follow-through: write down actions and review them next time. Trust grows when I do what I said.
• Signals: watch for changes in energy, mentions of other offers, or withdrawn behaviour. Ask about them gently.

I keep status updates out of the 1:1, because I can read tickets for that.

What they are checking: Whether you build trust and use 1:1s for growth, not status reports

I estimate as a team, treat estimates as ranges, and promise outcomes with a confidence level.

• Break work into small slices (a few days each). Large items are estimated badly.
• The team estimates with planning poker or relative sizing. When numbers differ, this shows hidden assumptions.
• Use past data. Throughput or velocity from the last several sprints gives a range, not a promise. For example: "70 percent likely by mid-June, 90 percent by end of June".
• Add clear buffer for unknowns and dependencies, and track risks.
• Keep estimate and commitment apart. Engineers give effort. The date is a talk about scope, capacity, and risk.
• Re-forecast every sprint and tell people early when the range moves.

If someone presses for one date, I give a date with a stated confidence. I offer to trade scope to hit an earlier one. I do not quietly squeeze the team.

What they are checking: Whether you use ranges based on data and avoid turning estimates into hidden pressure

My job is to help the team recover fast and communicate clearly. It is not to debug myself.

I treat it like any other engineering change: pilot, measure, set guardrails, then scale.

A good answer shows you are drawn to the work. It should not sound like running away from coding or wanting a title.

I define the role first. Then I run a structured, consistent interview process.

I track a small set that shows results and flow. The team reviews it. I do not use it to rank people.

An SLI (service level indicator) is a measured number. An example is the share of requests answered successfully in under 300 ms. An SLO (service level objective) is the target for it, for example 99.9 percent over 30 days. The error budget is the failure you allow. It is 100 percent minus the SLO, so 0.1 percent. That is about 43 minutes of full downtime per 30 days.

I rarely give a bare no. I show the trade-off and let priorities decide.

State your real number and show how you changed the structure as the team grew. For example: "I manage eight engineers directly, across two squads, in a group of about 20."

I compare the total cost of ownership and the strategic value, not just the licence price.

I match the release strategy to the risk and what the system can do.

I base decisions on published expectations and on evidence collected through the year.

I would avoid vanity numbers like the count of accepted suggestions. I would measure results against a baseline.

The CAP theorem says this. In a distributed data store, when a network partition (a break in the network) happens, you must choose between consistency and availability. Consistency means every read sees the latest write. Availability means every request gets a response. You cannot skip partition tolerance in a real network. So the real choice during a partition is C or A.

I design for async work (work that does not need everyone online at once) by default. I protect a small overlap for real conversation.

I would check the risk first. Then I would give the business a choice with numbers, not a refusal.

1. Ask the engineers to put numbers on it: what fails, how likely it is, and what a failure costs (downtime, bad data, support work).
2. Look for a smaller option. Ship the feature as a thin slice behind a feature flag. Fix the fragile module only where the feature touches it.
3. Show the product owner two or three options: full scope later, reduced scope on time with named risks, or on time with extra people. Include effort, risk, and what we stop doing.
4. Write down the decision, including the monitoring and rollback we will have.
5. After launch, schedule the proper fix so the shortcut does not become permanent.

Good judgement here means I do not simply side with engineers or with product. I make the trade-off clear. The person who is accountable decides with full information. Then I fully support that decision with the team.

What they are checking: Whether you handle engineering versus business tension with options and ownership, not conflict

I start by understanding. Then I make expectations clear, then I support, and only then do I escalate.

1. Check the facts. Compare against the role expectations with examples (missed deadlines, review quality, bugs), not impressions. Rule out my own failures, such as unclear goals or the wrong task for the person.
2. Talk in private. Describe specific things I saw, ask for their view, and listen for causes. These may be personal issues, a skill gap, unclear priorities, or burnout.
3. Agree a written plan: 30 to 60 days, clear measurable outcomes, support (pairing, training, smaller scope), and weekly checkpoints.
4. Give feedback often and write it down. Involve HR early if it may become formal.
5. Decide. If they improve, recognise it in public. If they do not improve despite support, move to a formal improvement process or an exit. Handle it with respect and follow the law.

Meanwhile I protect the rest of the team from quietly carrying the load. The goal is to give a fair chance to succeed. But keeping a long-term underperformer also harms everyone else.

What they are checking: Whether you balance care, clarity, and fairness, with written steps and an end point

First understand why. Then choose among scope, time, people, and quality, with the stakeholder involved.

1. Find the cause. Was it scope growth, wrong estimates, dependencies, people leaving, or rework from bugs? Use the sprint burndown and blocked-item data, not guesses.
2. Reset the plan. Re-estimate the remaining work, rank it by value, and find the smallest release that still works.
3. Show the options. Cut or delay lower-value scope (usually best), move the date, or add people. Explain that adding people late often slows delivery because of onboarding cost. Overtime and cutting tests create hidden debt.
4. Remove blockers myself. Escalate dependencies, shield the team from new requests, and simplify the process.
5. Tell people now, and then every week: what changed, the new forecast, and the decisions needed.

The wrong path is staying silent and hoping. Early honest news gives stakeholders options. Late news only gives them surprises.

What they are checking: Whether you find the cause, offer trade-offs, and communicate early instead of asking for heroic overtime

I would measure first, then fix the real bottleneck, then prove it with load tests.

I separate the technical question from the personal friction. Then I drive to a decision with a deadline.

Repeated incidents mean the postmortem actions are not working. So I look at the follow-up process itself.

I lead with the impact and the plan. Then I give the cause in plain words. I never surprise them.

I handle the incident first. Then I handle the behaviour and the system.

First I listen. I do not react defensively and I do not rush to make a counter offer.

I would ask the team to follow evidence, not guesses. I would keep the investigation moving.

I would manage it like a product team. The users are analysts, data scientists, and downstream services. The main promise is reliability.