ChannelPulse
The people-management round
The round that decides most EM loops, and the only behavioral round in tech where the questions are usually hypothetical. "How do you structure your one-to-ones" is not asking for a story — it is asking whether you have a system, and whether that system survives one follow-up.
What you'll be able to do
- Answer a hypothetical people-management question with a system plus a real instance, rather than one or the other
- Handle the six recurring question areas: one-to-ones, delegation, motivation, goals, inherited teams, retention
- Explain what interviewers are listening for underneath each question
- Avoid the two commonest failure modes — principles with no example, and an example with no principle
Before this: what-the-em-loop-tests
Something strange happens in the people-management round. Everywhere else in a tech loop, behavioral questions start with tell me about a time. Here they usually start with how do you.
- How do you structure your one-to-ones?
- How do you decide who to delegate to?
- How do you build credibility with a team you have just inherited?
- How do you balance feature work against technical debt?
- What hiring framework do you use?
- What do you do when a top performer tells you they want to leave?
These are hypotheticals, and candidates respond to them in one of two wrong ways. The first is to answer the question as asked — a clean, sensible, general description of an approach — which reads as theory. The second is to reflexively convert it into a story, which answers a question that was not asked and leaves the interviewer unsure whether you have a repeatable practice or just one anecdote.
Ten questions, answered briskly. The four chapters below are the people-management ones and are the ones to watch for this lesson. Treat the sample answers as a floor rather than a ceiling — they are correctly structured and deliberately generic, which is exactly the gap this lesson is about closing.
Jump to the part you need
The answer shape: system, then instance
The reliable structure for a hypothetical is two-part, and short:
The system. Here is how I do this, and why it is built that way. The instance. Here is a specific time it was tested, and what happened.
Roughly sixty seconds on the first, ninety on the second. The system shows you have a practice rather than instincts. The instance proves the practice is real and shows what it costs when it collides with a difficult person or a bad quarter.
Interviewers rarely ask for the second part explicitly, which is exactly why volunteering it scores. The candidate who describes a one-to-one structure and then says "the time that structure earned its keep was when…" has answered both the asked question and the unasked one.
One-to-ones
The question sounds procedural and is not. It is asking what you think the meeting is for.
A weak answer describes a status meeting: what are you working on, any blockers, anything from me. The problem is not that it is wrong — it is that a good standup already covers it, so a manager who describes this has not explained why the meeting exists.
A strong answer has a stated purpose, a cadence, an owner, and a persistence mechanism:
- Purpose. Their agenda, not yours. Career, friction, feedback in both directions — status only if they raise it.
- Cadence. Weekly for most, and say why you would deviate. Biweekly for a senior engineer who asks for it; twice weekly for someone new or struggling.
- Owner. They bring the agenda. You bring one thing.
- Persistence. A running shared document, so that "we talked about this in March" is checkable rather than remembered.
Then the specific: a one-to-one where something surfaced that would not have surfaced any other way. Those are the ones that justify the format.
Delegation
How do you decide who to delegate to? is a question about growth, not throughput.
The trap is answering it as an allocation problem — give the work to whoever can do it. That is the correct answer for a tech lead under deadline and the wrong answer for a manager, because it produces a team where the strongest engineer gets every interesting problem and everyone else stalls.
The two-axis version scores better: match the work to the person by capability and by stretch. Something clearly inside someone's range gets delegated for speed. Something just outside it gets delegated for growth, with the support level set explicitly — and the support level is the part candidates skip. Saying "I delegated the migration to a mid-level engineer and paired with them on the design review, then stepped back for implementation" demonstrates the actual skill. Saying "I delegate to grow people" demonstrates that you know you should.
And name what you keep. Managers who claim to delegate everything are either exaggerating or bad at the job; some things genuinely should not be delegated, and knowing which is a signal.
Motivation
The unhelpful answer to how do you motivate your team is a list of morale tactics.
The useful answer starts from the observation that motivation is not uniform, so a single lever cannot work. What actually varies is what people want: autonomy, mastery, visibility, stability, proximity to users, technical depth. Your job is to know which one each person is running on, which you learn in one-to-ones, and then to route work accordingly where you can.
That framing lets you say something specific and slightly unflattering, which reads as honest: the engineer for whom the motivating thing was recognition rather than the interesting problem, and what you did about it once you understood that.
Goals and expectations
Two questions hide inside how do you set clear goals and expectations: how the team's goals connect upward to the organisation, and how individual expectations are made explicit enough to be fair.
For the first, describe the mechanism you use — OKRs, a quarterly roadmap, whatever — and, more importantly, the translation step. The team should be able to say what business outcome their work serves without you in the room. If they cannot, priorities get relitigated every time something urgent lands.
For the second, the key claim is that expectations are only clear if they are written and shared before the evaluation. The failure mode this prevents is the review conversation where someone learns for the first time that they were being measured on something they did not know about. Say that out loud; it demonstrates you have been on the wrong end of it or seen it happen.
Inherited teams
How do you build credibility with a team you did not hire? The good version has a sequence and a constraint.
The sequence: listen first, at length. One-to-ones with everyone in the first two weeks, with the same handful of questions so the answers are comparable — what is working, what is broken, what would you fix, what should I not break. Read the last two quarters of the team's actual output. Then find something small, visible and irritating that you can fix quickly, and fix it.
The constraint, which is the part that shows judgment: do not reorganise anything in the first month. Not because change is bad, but because you cannot yet tell which of the things that look wrong are load-bearing. A manager who arrives with a restructure demonstrates that they were not listening.
Retention and the top performer who wants to leave
This question is a judgment test with a wrong answer that feels right.
The wrong answer is to treat it as a retention problem and go straight to what you can offer. It sounds proactive and it is subtly bad, because it skips the diagnosis and because it establishes that threatening to leave is how you get things at this company.
The better shape: find out why, honestly, before responding at all. The reasons split into ones you can act on — scope, growth, compensation banding, a manager relationship, a project they hate — and ones you cannot, like wanting to work in a different domain or city or company stage. Act wholeheartedly on the first category. For the second, be genuinely helpful about the exit, because a strong engineer who leaves well often comes back or refers people, and because the alternative is a resentful three months and a worse handover.
And say the unglamorous part: by the time someone tells you, you are usually late. The real answer to retention is the one-to-one six months earlier where their growth path was discussed and something happened as a result.
What to carry into the next lesson
People management is the round with the most weight. Technical depth is the round with the most confusion, because EM candidates are frequently asked to design a system and then pushed past the level of detail they prepared for — or asked, instead, to talk in depth about something they actually built. Next.