The Engineering Manager Technical Interview: How to Test Judgment Without a Coding Test

Engineering managers should not take coding tests. They also should not get a free pass on technical judgment, and most EM loops give them exactly that.

The standard loop is behavioural. Tell me about a conflict on your team. Tell me about a project that slipped. Tell me about someone you had to performance manage. Every one of these is a reasonable question and every candidate above a certain level has answered them a dozen times. What you measure is rehearsal quality, which is why so many EM hires interview beautifully and then make their first genuinely technical call badly.

There is a middle path, and it takes about forty minutes.

What the behavioural loop cannot see

Whether they can tell a loud risk from a real one. A manager's day is a queue of things people are worried about. Deciding which two of nine concerns deserve time is the job, and a rehearsed story about a past incident does not show it, because the story is told backwards from a known outcome.

Whether they can be technical without taking over. Some managers cannot resist fixing it themselves. Others have drifted so far from the systems that they cannot evaluate a plan at all. Both fail the same way: the engineer with the real information stops being consulted.

Whether they will say no to their own manager. Stories about pushing back are always stories where pushing back worked out.

Whether they can read a system they did not build. Every new manager inherits one. The speed at which they build an honest mental model of it, including the parts they do not understand, determines their first six months.

Why not just give them a coding test

Because it measures the wrong decade. Most strong EM candidates wrote production code three to eight years ago. A timed algorithm exercise will sort them by how recently they practised, not by how well they lead, and it will insult the good ones on the way through. If you need to know they can still read code, ask them to read some.

There is a real distinction here between a hands-on tech lead role and a people-management role. Be honest with yourself about which one you are hiring. If the job includes writing code weekly, test that directly and say so in the posting. If it does not, do not smuggle it in.

The ten minute incident

This is the exercise we would keep if we could only keep one.

Put the candidate in front of a running system they did not build, with something wrong in it, and the following framing: you are the manager on duty, it is Tuesday afternoon, the system is degraded, two engineers are online. You have ten minutes. What do you do?

Nobody expects them to fix it. You are watching for five specific things.

Do they establish impact before cause? Who is affected, how badly, is it getting worse. The managers who go straight to the technical cause are usually the ones who cannot answer their own executives later.

Do they ask the engineers, or tell them? The best answer nearly always includes finding out what the people already on the call know, and explicitly not duplicating it.

Do they separate the two jobs? Someone investigates, someone communicates. A manager who tries to do both does neither, and an EM candidate who names that split unprompted has run real incidents.

Do they set a decision point? "If we do not know in twenty minutes, we roll back" is the sentence of somebody who has been in a long one.

Do they read anything themselves? Give them access. A manager who can open the logs, form a rough hypothesis and hold it loosely is a different animal from one who only relays. This is where you find out whether the technical part survived the promotion.

If you already run live incident drills for engineers, the same environment works here, with the seniority of the questions changed and the keyboard mostly untouched.

Three more exercises

The plan review. Hand them a real design document from your team, ideally one with a known weakness, and ask for a fifteen minute review. What you watch: whether they can ask a hard question without making it personal, whether they identify the actual risk or only stylistic issues, and whether they know what they do not know. A manager who writes "I am not close enough to the storage layer to judge this, here is who should" is showing good judgment, not weakness.

The estimate that is wrong. Give a scenario: an engineer says two weeks, you believe it is six, the commitment has been made to a customer. What now? You are listening for whether they go and get information or negotiate with the person. Weak answers manage the engineer. Strong answers break the work down until the disagreement is about something specific.

The disagreement they lost. The only behavioural question worth keeping, because it is the hardest to rehearse well. Ask for a technical decision where they were overruled and were later proved right, and then what they did next. The answer to the second part is the one that matters.

Score the same four things every time

Evidence over instinct. Did they seek information before acting?

Leverage. Did they use the people and systems available, or absorb the work themselves?

Calibration. Do they know the limits of their own technical knowledge and say so out loud?

Communication under pressure. Could a non-engineering stakeholder have understood their update?

Write those down before you interview anyone, score independently, and compare afterwards. Manager hiring is where unstructured panels do the most damage, because charisma correlates with the thing you are trying to measure without being it. The bar raiser problem covers the calibration mechanics.

What not to do

Do not ask them to design a system on a whiteboard. You will get a rehearsed architecture and learn nothing about their judgment, which is exercised on systems that already exist and cannot be redrawn.

Do not let the loop become a culture conversation. Four rounds of values questions with no technical exposure produces managers who are pleasant to work with and cannot be trusted with a decision.

Do not skip a session with the engineers they would manage. They are the only people in the process who can tell whether the technical depth is real, and they are the ones who will find out either way.

What is the last decision your engineering managers made that your interview process would not have predicted?