By Johnny Campbell
Introduction
People Operations is the only role in HR where the deliverable is a system rather than a conversation. A HR Business Partner is judged on the quality of their judgement in the room; a People Operations Manager is judged on what happens when nobody is in the room at all — whether the new starter’s laptop arrives, whether the payroll file reconciles, whether the leaver’s access is revoked on the right day, whether the headcount report matches the finance headcount report. The test isn’t whether they care about employee experience, because everybody says yes to that. It’s whether they have ever taken a fourteen-step onboarding process and made it four, and can tell you precisely what broke on the way — which handoff they removed too early, which manager stopped getting the notification they had quietly depended on, and what they put back.
Three mistakes cause most bad hires here. The first is interviewing a generalist HR profile for what is fundamentally a process design and systems job — warm, credible on employee relations, and never having designed anything. The second is asking which HRIS they have used rather than what they configured, migrated or automated inside one; every candidate has “used Workday”, and very few have owned a field structure, run a data migration, or made a decision about how absence should be recorded that they still stand over. The third is never testing data hygiene, which is where this role quietly fails — not in a dramatic incident, but in eighteen months of a report that has been wrong the whole time and nobody checked.
This page covers 24 behavioural and situational questions across six capability areas: process design and simplification, HRIS, systems and automation, data integrity and reporting, employee lifecycle operations, compliance and policy operations, and scaling under growth or change. Every question asks what the candidate did, not what they believe.
Core Competencies for a Great People Operations Manager Hire
Start with Attention to Detail, because this is a role where a mis-mapped field costs a payroll cycle and a wrong date costs someone their access on the wrong morning. Technical Skill matters far more than most HR hiring panels assume — not coding, but the ability to model data, reason about a workflow, and understand what an integration is actually doing. Pair those with Ownership, since People Ops sits between HR, finance and IT, and the gaps between those three are where things go missing unless somebody claims them. Decision Making shows up in what they choose not to automate, and Service Oriented in whether they design for the employee using the process or for the team administering it. Finally, Influence and Persuasion and Business Acumen decide whether they can get IT to prioritise a change and convince a CFO that the HRIS spend pays for itself.
Process design and simplification
What good looks like
A strong candidate can describe a process they redesigned from scratch, not one they inherited and tidied. They can walk through the before and after step by step, name the exact step they removed and what broke when they removed it, and explain which manual step they deliberately kept and why. They talk about who lost visibility when a step disappeared, not just how many days the process now takes.
Behavioural questions
- Walk me through a process you redesigned end to end. What did the old version look like on paper?
- How many steps did the original process have, exactly?
- Which single step took the longest to justify removing?
- What did you replace the removed steps with, if anything?
- How did you know the new version actually worked?
- Tell me about a process you deleted rather than improved. What convinced you it should not exist?
- What was the process meant to achieve when it was built?
- Who pushed back when you proposed deleting it?
- What did you check before deleting it, to be sure?
- What happened in the first month after it was gone?
- Describe a time you removed a step from a process and something downstream broke. What broke?
- What was the step, and why did it look safe to remove?
- Who first noticed something had broken?
- How long did it take to trace it back to the missing step?
- What did you put back, and how was it different?
- Give me an example of a manual step you deliberately chose to keep manual. Why that one?
- What would automating that step have actually saved?
- What could go wrong if it ran without a human checking it?
- Who else did you have to convince to leave it manual?
- Has that decision ever been challenged since?
- Tell me about a process change you made that people quietly went around. How did you find out?
- What were people doing instead of the new process?
- How long had the workaround been running before you noticed?
- What did you do once you found out?
- Did you fix the process or enforce the rule, and why?
Situational scenario
Your onboarding process has fourteen steps across four owners — IT, facilities, payroll and the hiring manager — and new starters routinely go without laptop access on day one. You’ve been asked to cut it to five steps within a month, with no extra budget and no new tooling.
Walk me through how you approach the redesign.
Then introduce a constraint: “Two weeks in, the facilities owner tells you the step you cut was the only thing catching starters who need building access clearance, and one has just been let into a restricted area without it. Does that change your redesign?”
What to listen for
whether they ask what each of the fourteen steps was actually protecting against before cutting it, whether they treat the facilities miss as a design flaw to fix rather than a reason to abandon the redesign, and whether they can describe a concrete replacement control rather than simply reinstating the step they removed.
HRIS, systems and automation
What good looks like
A strong candidate can name the specific system decisions they made, not just the platforms they have used. They can describe a field structure or data model they built, a migration they ran end to end, or an automation they configured and later had to fix. They talk about IT and engineering as people they had to persuade, with a specific ask and a specific outcome, not a vague description of collaboration.
Behavioural questions
- Take me through a system implementation or migration you worked on. What was your specific part of it?
- Which system was it, and how many records did the migration touch?
- What decision did you personally make, versus what came from a vendor?
- What went wrong during the migration, if anything?
- How did you validate the data after it landed?
- Tell me about a decision you made about how data should be structured in your HRIS. What were the alternatives?
- What field or object were you structuring, specifically?
- What were the other options, and who preferred them?
- What made you choose the option you chose?
- Would you make the same call again today?
- Describe an automation you built that later caused a problem. What did it do that you had not anticipated?
- What was the automation meant to save you from doing manually?
- Who first spotted that it had gone wrong?
- How long was it running before the problem surfaced?
- What did you change in the automation afterwards?
- Give me an example of a time you needed IT or engineering to change something for you. How did you get it prioritised?
- What did you actually ask them to build or change?
- Where did your request sit on their priority list to start with?
- What did you do to move it up?
- How long did it take from ask to delivery?
Situational scenario
You want to automate leaver access revocation so that IT accounts, building passes and payroll are all switched off on the employee’s exact last day, rather than the current process where it happens whenever someone remembers. Engineering has told you it’s a two-sprint piece of work and they have no capacity for it this quarter.
Walk me through how you get this built.
Then introduce a constraint: “Engineering offers you a fast version that revokes IT access automatically but leaves building passes and payroll on a manual checklist for now. Do you take it?”
What to listen for
whether they weigh the fast partial fix against the risk of the manual gaps it leaves, whether they have a concrete plan for closing those gaps rather than accepting them indefinitely, and whether they can explain the trade-off to a stakeholder without overselling what the partial automation actually covers.
Data integrity and reporting
What good looks like
A strong candidate has gone looking for errors rather than waiting for one to surface. They can describe a specific number that was wrong for months, how they found it, and what they did once they found it, including the conversation with whoever had already used the wrong figure. They treat two systems disagreeing as a signal to investigate immediately, not a discrepancy to note and revisit later.
Behavioural questions
- Tell me about a data error you found that had been wrong for months. How did you come across it?
- What was the number, and roughly how far out was it?
- What made you go looking, if nobody had flagged it?
- Who had been using the wrong figure, and for what?
- What did you put in place to catch it sooner next time?
- Describe a time two systems disagreed about the same number. What did you do first?
- Which two systems, and which number was in dispute?
- How big was the gap between them?
- Which system did you trust first, and why?
- How did you find out which one was actually right?
- Walk me through a report you built that a leadership team relied on. Who checked it?
- What decision did the report actually feed into?
- Who signed off the numbers before they went out?
- What happens if that report is wrong one month?
- Has anyone ever queried a figure in it, and what happened?
- Give me an example of a time you had to tell someone senior that a number they had already used was wrong.
- What had they already done with the wrong number?
- How did you decide to tell them rather than quietly fix it?
- What was their reaction when you told them?
- What did you change so the same number couldn’t go out wrong again?
Situational scenario
Two weeks before a board pack goes out, you notice the headcount figure finance has been quoting all quarter doesn’t match your HRIS by eleven people. Nobody else appears to have spotted the gap, the CFO has already presented the finance number twice in prior meetings, and the discrepancy sits right at the edge of a headline metric investors track quarter on quarter.
Walk me through what you do.
Then introduce a constraint: “When you dig into it, you find the gap exists because finance excludes contractors and you include them — both numbers are defensible, just different definitions. Does that change how you raise it?”
What to listen for
whether they raise it before the board pack goes out rather than after, whether they get to the root definitional cause instead of just reconciling the two numbers once, and whether they propose a single agreed definition going forward rather than leaving two versions of the truth in circulation.
Employee lifecycle operations
What good looks like
A strong candidate can describe onboarding and offboarding in terms of specific timing and handoffs, not general philosophy. They know what happens on day one of a new starter’s job in enough detail to say who owns each piece, and they can describe an unexpected leaver situation where they tightened the process afterwards rather than treating it as a one-off.
Behavioural questions
- Take me through the onboarding experience you were most recently responsible for. What happened on day one?
- Who was in the building or online to greet the starter?
- What was ready for them, and what wasn’t?
- Whose job was it to make sure equipment and access were set?
- What would you change about that specific day one?
- Tell me about a new starter whose first week went badly for operational reasons. What went wrong?
- What specifically failed — access, equipment, paperwork, something else?
- When did you find out it had gone wrong?
- What did you do to fix it for that starter?
- What did you change in the process afterwards?
- Describe how you handled offboarding the last time somebody left unexpectedly.
- How much notice did you actually have?
- What had to happen in the first 24 hours?
- Whose access or equipment nearly got missed?
- What did you learn about the process from that case?
- Give me an example of a change you made to the leaver process after something slipped through.
- What slipped through, specifically, and who noticed it first?
- Who noticed it, and how long after the person had left?
- What did you change in the checklist or handoff?
- Has it happened again since you made the change?
Situational scenario
A senior manager resigns with immediate effect after a difficult conversation on a Friday afternoon. They have access to sensitive compensation data, a company laptop, admin rights on two shared systems, and a set of client relationships nobody else in the business currently owns or has ever had to pick up cold.
Walk me through what you do between now and Monday morning.
Then introduce a constraint: “IT tells you the standard access-revocation ticket won’t be actioned until Monday because there is no weekend on-call cover for that system. What do you do?”
What to listen for
whether they have an escalation path for exactly this situation rather than accepting the standard turnaround, whether they sequence the highest-risk access first instead of working through the checklist in order, and whether they follow up afterwards to fix the gap in weekend cover rather than treating it as a one-off exception.
Compliance and policy operations
What good looks like
A strong candidate can describe turning a written policy into something that actually runs day to day — the forms, the approvals, the checks that make it real rather than aspirational. They can describe finding the organisation not following its own policy and what they did about it, and they treat an audit or inspection as a test of the operation, not a paperwork exercise.
Behavioural questions
- Tell me about a policy you had to turn into a working process. What was the hardest part to operationalise?
- What did the policy say on paper before you touched it?
- What was the first version of the process you tried?
- What didn’t work about that first version?
- How do you know the process people now follow matches the policy?
- Describe a time you discovered the organisation was not following its own policy. What did you do about it?
- Which policy, and how did you discover the gap?
- How widespread was the non-compliance once you looked?
- Who did you have to tell, and how did they react?
- What did you put in place to stop it recurring?
- Walk me through how you prepared for an audit, inspection or regulatory request. What did it expose?
- What triggered the audit or request?
- What did you find when you pulled the evidence together?
- What was the single biggest gap the process exposed?
- What did you fix once the audit was over?
Situational scenario
A regulator or auditor gives you two weeks’ notice that they want to see evidence your right-to-work checks have been completed and filed correctly for every employee hired in the last twelve months. You suspect, but don’t know for certain, that a handful of files from a period when the team was short-staffed may be incomplete.
Walk me through what you do in those two weeks.
Then introduce a constraint: “Three days before the deadline, you confirm four files really are incomplete and can’t be fully backfilled in time. What do you tell the auditor?”
What to listen for
whether they audit the full population rather than hoping the gap is smaller than suspected, whether they disclose the incomplete files proactively rather than waiting to be asked, and whether they can describe a credible remediation plan rather than just an apology.
Scaling under growth or change
What good looks like
A strong candidate can point to the specific volume or event that broke a process that had been fine before — a headcount threshold, a month of joiners, a restructure, an acquisition — and describe exactly what they changed to cope. They talk about what they inherited in poor shape and what they fixed first, with a clear sense of sequencing rather than doing everything at once.
Behavioural questions
- Tell me about a process that stopped working when the company grew. At what point did it break?
- What was the process, and what volume or size was it built for?
- What was the first sign it was breaking?
- How long did you let it strain before changing it?
- What did you change it into?
- Describe the largest volume of joiners you have handled in a single month. What did you change to cope?
- How many joiners, and how did that compare to a normal month?
- What was the first thing that nearly failed under the volume?
- What did you do differently for that batch specifically?
- What did you keep from that approach afterwards?
- Give me an example of an operational change you had to make during a restructure or acquisition.
- What was changing — systems, headcount, reporting lines, something else?
- What did you have to stand up or merge, specifically?
- What broke during the transition that you had to fix live?
- What would you do differently if you did it again?
- Tell me about a time you inherited an HR operation that was in poor shape. What did you fix first?
- What state was it in when you arrived, specifically?
- How did you decide what to fix first versus what could wait?
- What was the first thing you actually fixed?
- What was still broken six months in?
Situational scenario
Your company has just agreed to acquire a smaller competitor, doubling headcount inside a single quarter. The acquired company runs a different HRIS, a different payroll provider, has no formal onboarding process at all, and its people data has never been through a proper audit, so you don’t yet know how much of it you can trust.
Walk me through your first thirty days after the deal closes.
Then introduce a constraint: “Finance tells you the two payroll systems must run in parallel for at least two more quarters, because migrating early risks paying the acquired company’s staff incorrectly. What does that change about your plan?”
What to listen for
whether they sequence the work realistically instead of trying to unify everything on day one, whether they identify what genuinely can’t wait — like access and right-to-work checks — versus what can run in parallel, and whether they have a concrete plan for the acquired employees’ experience in the gap before systems are unified.
Red flags to watch for in People Operations Manager interviews
They list HRIS platforms on the CV but have only ever been a user. They have never configured a field, owned a data model, run a migration or signed off a test plan. Ask what they changed inside the system, and the answer becomes “raising tickets”.
Employee experience described as a philosophy with no metric attached. Warm language about belonging and engagement, and not one example of a single number they moved — time to productivity, ticket volume, onboarding completion, payroll error rate.
Every process they describe is one they inherited. Three roles, no redesign. They can explain how it worked, never why it was built that way or what they would change.
No error stories at all. Nobody who has run payroll interfaces and HRIS data for five years has a clean record. A candidate with no mistake to tell you about either hasn’t owned the work or won’t tell you when something goes wrong.
Automation treated as a virtue in itself. They automated things because automation is good, not because they measured what it cost to do manually, and can’t name anything they chose to leave alone.
They cannot describe a disagreement with IT or finance. This role lives in those seams. Complete harmony usually means complete deference.
How to structure a People Operations Manager interview loop
Most organisations run an HR competency interview, a culture conversation and a chat with the CHRO, and never once watch the candidate think about a system. Fix that by building the loop around one practical exercise. Start with a screen focused on scope — what sat in their remit and what belonged to somebody else: payroll, benefits, IT provisioning, HRIS ownership, reporting. Vague boundaries here rarely sharpen later. Follow with a competency interview using the process design, data integrity and lifecycle questions above, run by two interviewers asking identical questions and scoring separately.
Then comes the exercise, and it should be a genuinely broken process of yours, not a case study. Hand them your real onboarding flow or your real leaver process, with the actual number of steps, the actual owners and the actual handoffs, and ask them to redesign it out loud. You are watching whether they ask what the process is for before they cut it, whether they notice who loses visibility when a step disappears, and whether they can tell you what they would test before rolling it out. Close with a cross-functional conversation with finance or IT, since those relationships determine whether anything gets built, and a values and management conversation if they will have direct reports.
The difficulty is running this the same way for every candidate rather than comparing interviewer styles. See how Interview Intelligence standardises this across your team →
Frequently asked questions
What is the difference between People Operations and traditional HR?
Traditional HR is casework-led: employee relations, performance issues, manager coaching, judgement applied case by case. People Operations is systems-led — the output is a working process, a clean data set and an employee experience that holds up without intervention. The two overlap at the edges, and small companies often combine them, but if you interview for one and hire for the other you get a capable person doing a job they were not selected for.
Should a People Operations Manager have a technical background?
Not a coding background, but they need genuine systems literacy. They should be able to reason about how data flows between the HRIS, payroll and identity management, understand what an integration does when it fails, and hold a credible conversation with an engineer about a change request. Candidates who have configured a system, built reporting logic, or run a migration usually have this. Candidates who have only ever raised tickets usually do not.
How do I test process design skill in an interview?
Give them one of your genuinely broken processes and ask them to redesign it in front of you. Do not sanitise it. Watch whether they ask what the process is for and who depends on each step before they start removing things. Strong candidates will identify the step you are most attached to and ask why it exists. Weak candidates will produce a tidier version of the same shape.
What size company needs a dedicated People Operations Manager?
There is no fixed threshold, and it depends more on complexity than headcount. The usual trigger is when your HR generalists are spending most of their week on administration and data rather than on people, or when the HRIS has been implemented and nobody actually owns it. Multiple entities, multiple countries or rapid hiring all bring the need forward considerably.
Should this role own payroll?
Often it owns the interface to payroll rather than payroll itself — the data, the change file, the reconciliation and the accuracy of what goes across. Full ownership usually sits with finance. What matters is that the boundary is explicit before you hire, because the gap between HR data and the payroll run is the single most common place for errors to live undetected.