The Manager Interview: The People Questions, and How to Answer Them Without Sounding Like a Textbook

A manager loop usually has a recruiter call, a hiring manager round, a people-management round, a cross-functional round and, for engineering managers, a round on technical credibility. Most of them can be survived on a good day. The people round is different. Hello Interview's guide to Meta's manager loop says it often makes or breaks the decision.

The reason is simple. Everything else in the loop asks whether you can do the work. This round asks whether people would want to work for you, and whether you can get a team through a bad quarter. Panels cannot see that on a resume, so they ask for stories, and they listen closely to how you tell them.

It is also the round where strong individual contributors trip. They answer a people question the way they would answer a production incident: timeline, root cause, fix. That is a good answer to a different question.

You may know STAR: situation, task, action, result. It works for most behavioral questions. For a people question, the panel wants something a little different. They want to hear how you thought about the person, not only what you did. Use five parts, in this order.

1. 1Diagnosis. What was really going on, for the person or the team. Not only the symptom.
2. 2Plan. What you agreed with the person, and who would do what.
3. 3Action. What you did, including the conversation that did not land the first time.
4. 4Outcome. What happened for the person, the team and the work.
5. 5What changed in you. One thing you do differently since.

Keep the situation to two sentences, with the team size in it. Then spend most of your time on the diagnosis and the plan. That is where the panel learns how you manage. A story that jumps from "there was a problem" to "so I fixed it" tells them nothing.

"Tell me about someone on your team who was not meeting the bar." This is the most common people question, and the one with the clearest signals. Panels look for four things: you noticed early, you said so plainly, you made a plan with the person, and you wrote it down.

Start with the diagnosis. Was it skill, clarity, motivation, or something outside work? "He missed three sprint goals" is the symptom. "He did not know what good looked like at the new level, and I had never told him" is a diagnosis, and it puts some of the cause on you, which panels respect.

Then tell the plan as an agreement, not a decree. What did you agree, by when, and how would you both know? If it ended with the person leaving, say so, and say how you kept their dignity: you told them in private, nothing came as a surprise, and the team heard it from you. A surprise PIP is the answer panels fear most.

The strongest version of this story is the messy one. The first conversation did not land. You went back, tried a different way, and it worked the second time, or it did not. A story that worked perfectly first time sounds rehearsed, and panels will probe until they find the mess.

"Tell me about a project that slipped." This is where the engineer habit shows most. The tempting answer explains the root cause: the vendor API changed, the estimate was wrong, another team was late. All of that may be true. None of it is what the panel asked.

Own the miss first. Say what your part was: "I said yes to the date before I asked the team", or "I saw the risk in week two and did not raise it." Then say how you re-scoped with the people involved, and what you do differently now. A dependency can be part of the story. It cannot be the whole of it. Blaming a dependency is the low anchor on most delivery rubrics.

"Two people on your team were in conflict. How did you handle it?" The weak answer is "I got them in a room and it resolved itself." Panels hear that a lot, and they score it low because it hides the hard part.

Tell the hard conversation with what was said. "I told her that her review comments were landing as personal, and gave her two examples from that week." Say what each person wanted, what you asked of each of them, and what changed after. If one of them was right, say so. The panel is checking whether you can have a direct conversation with a real person, not whether you can describe one.

Many loops have a question about a partner team or a product manager: "Tell me about a difficult relationship with a PM." The trap here is escalation. If the only tool in your story is going to your manager, the panel learns you cannot get things done across teams on your own.

The strong answer finds the other team's goal and ties your ask to it. "Their quarter was about fraud losses, so I showed how the change cut them." Then name the trade-off you both accepted. Agreement that comes from shared goals lasts. Agreement forced by a title does not, and panels know it.

Near the end, many panels ask a curveball: "What management mistake do you keep making?" Note the word keep. They do not want a one-off failure with a neat lesson. They want a pattern you know about yourself.

Name a real one. "When a report struggles, I take the work back instead of coaching them." Say when it last happened and what it cost. Then name the habit that now catches it: "I ask 'what would you try?' before I offer anything." Avoid the humble boast, such as caring too much or working too hard. It reads as a dodge, and the panel marks self-awareness down.

After the round, each interviewer writes a short note for the debrief. It usually has one line per area they covered, with a quote. "Performance: raised it in week two, agreed a plan with him. 'I asked what was going on before I asked about the tickets.'"

It also has a scope line, which candidates rarely think about: "Manages six, two levels, one partner team." Panels read scope as level. If you never say how many people you manage, at what levels, and which other teams you work with, they have to guess, and they guess low. Put the team size in the first two sentences of every story.

Finally, there is a consistency check. Do your stories agree with each other? Is the team six in one story and twelve in the next? Do you describe your reports with respect in all of them? Small contradictions add up in the debrief.

Reading this will not make the round easier. Telling the stories out loud will. Most people find their first try jumps straight from the problem to the fix, with no diagnosis and no plan.

Star Interview runs a 45-minute practice manager interview with an AI director. You get four people situations from your own experience, one scenario and the mistake you keep making, then time for your questions. You can name the situation you least want to be asked about, and it becomes one of the four. For an engineering role, technical judgment is in scope too. Afterwards you get a report per management area, with the notes a panel would write and a read of your scope. See what the practice round covers.