Operations Manager Interview Questions

"I started as a team member in a distribution centre while I was finishing my degree, then became a shift lead after about eighteen months because I kept fixing small things nobody owned. For the last four years I've been an operations manager at a regional fulfilment site, with around sixty people across two shifts and three supervisors reporting to me. I own daily output, service levels, the labour plan and safety for the site. What keeps me in operations is that the results are visible every single day. If I change how we stage orders on Monday, I can see whether it worked by Wednesday. I'd like my next role to be a larger or more complex operation where I can build the planning side properly, not just run the day."

"I can only guess from the outside, so I'll say it as a hypothesis. You've grown quickly into new cities, and your reviews mention late deliveries around weekends and holidays. That suggests two things to me: demand is spiky, and the staffing plan probably hasn't caught up with the growth. The job ad also mentions standardising processes across sites, which usually means each site has built its own way of working. Both of those are problems I've dealt with. At my last company I built a weekly labour plan from order forecasts and wrote the common SOPs when we merged two sites. I'd want to check my guesses against your real data in the first few weeks before changing anything."

"In the first month I'd mostly listen. I'd work alongside the team on every shift, including nights, sit with each supervisor, and learn how the KPIs are calculated, because a number I don't understand is useless to me. By the end of that month I'd write down what I think the top problems are and check that list with my manager and the team. In the second month I'd pick two or three things that are clearly costing us, agree how we'll measure them, and start fixing them with the people who do the work. By the third month I'd want at least one visible win, and a steady rhythm: a short daily huddle, a weekly review of the numbers, and a clear picture of where each supervisor is heading."

"In my last role I ran a customer service centre, and I had an evening team lead who'd been promoted from agent and was well liked, but his shift's response times and attendance had been drifting down for two months. When I sat with him, it turned out he was still taking calls himself whenever the queue got long, so nobody was actually running the shift. I was direct: I showed him the numbers and said his job now was to plan, coach and unblock, not to answer calls. We agreed three things to do differently, and I sat through two of his evenings with him to show how I'd run the start of a shift. We checked in every week for six weeks. His numbers came back to the centre average within about a month, and he's since trained two new team leads himself."

"Handovers are where problems quietly disappear, so I want the same format every time. It covers the backlog and what's urgent, any orders or customers at risk, open problems and who's working on them, safety incidents or near misses, equipment that's down or acting up, and people issues like absence or someone who's been moved. It's written in a shared log so nothing depends on memory, and there's also a short conversation between the two supervisors, even five minutes, because the written log doesn't catch everything. The key rule is that every open issue leaves the handover with a named owner on the incoming shift. I read the logs myself every morning and follow up when the same issue appears two shifts running."

"I try to spend a good part of every day on the floor, usually the start of each shift and a couple of walks later on, and more on busy days or when something's changing. On the floor I see things no report shows me: people walking too far, a workaround someone invented, a safety risk that's become normal. It's also where the team gets to raise things with me without booking a meeting. But I protect some desk time too, often early in the morning, for planning, looking at trends and preparing for reviews, because if I only firefight on the floor, nobody's working on next month. If I'm at my desk all day, I know I've lost touch."

"When something goes wrong, my first question is how the system let it happen, not who did it. Most mistakes come from unclear steps, bad tools or pressure, and if I punish the person, the next one just gets hidden. But no-blame doesn't mean no accountability. I separate three cases. An honest mistake gets support and a process fix. Repeated carelessness after coaching becomes a performance conversation. And a deliberate choice to take a risk, like switching off a safety guard, has real consequences whatever the outcome. I also make a point of thanking people in front of the team when they report a near miss or own up early, because that's the behaviour I want to see more of."

"At my last site, orders were regularly missing the last truck of the day. The dispatch team blamed picking speed, but when I measured it, picking was fine. The delay was in packing, where two stations sat idle every afternoon waiting for supplies while the others queued up. I timed a week of orders from pick to dispatch to get a baseline, then we moved packing supplies to a replenishment run twice a shift and let any packer take any order. Over the next four weeks the average time from pick to truck dropped by about a third, and missed trucks went from several a week to roughly one a month. To make it stick, we added the replenishment run to the shift checklist and I kept the pick to truck time on the daily board."

"Before anything else I'd go and watch people doing the task, and ask a few of them why they're still doing it the old way. There are usually four reasons: the SOP is unclear, it doesn't work in practice, people weren't properly trained, or supervisors aren't checking it. If the new way is actually slower or misses a real situation, that's a flaw in my SOP, and I'd fix it with the people who do the work. If it's training, we'd do short hands-on sessions at the workstation, not an email. Then I'd ask supervisors to check it during their floor walks for the next few weeks, track compliance, and deal individually with anyone who still ignores it once the reasons are removed."

"Say a machine stopped mid-shift. Why? It overheated. Why? The cooling fan failed. Why? It was clogged with dust. Why? It wasn't cleaned on schedule. Why? The cleaning task wasn't on the maintenance plan for that machine when it was installed. That last answer is useful because it's a process gap I can fix, not just 'the fan broke'. Five is a rule of thumb, not a target; you stop when you reach something you can change. The weakness is that it follows one path, so if a problem has several causes working together, you can end up fixing just one. It also depends on who's in the room. So I check each answer against evidence, and for messier problems I use a fishbone diagram or the data first."

"To me, lean means looking at every step through the customer's eyes and asking whether they'd pay for it. Anything they wouldn't is waste, and the job is to remove it steadily. The classic forms are waiting, overproduction, unnecessary movement of people, moving materials around, excess inventory, defects and rework, over-processing, and not using people's ideas. I've seen most of them. At one site pickers walked back to a printer at the far end of the floor for every batch, which was pure motion. We also had approvals signed by three people when one would do, which is over-processing. The part people forget is respect for the people doing the work. The best waste ideas nearly always came from the floor, not from me."

"We had a next-day SLA for a retail client, and during a week of heavy promotions we missed it on a large share of their orders for three days running. I called their account lead myself on the first morning instead of waiting for them to notice, told them what had happened and gave a daily recovery update until we were clear. We added a Saturday shift to catch up. Afterwards I looked at why, and the real cause was that the client shared their promotion plan with sales, but it never reached my planning team, so we staffed for a normal week. The fix was simple: a standing monthly call with the client and sales where we see promotions six weeks out, and a rule that any forecast jump over a set level triggers a staffing review."

"First I'd check the number is real, because dashboards go wrong, so I'd look at the actual queue and talk to the supervisor on that area. Then I'd find where the work is stuck. If it's a staffing gap, I'd move people from less urgent work or bring in cross-trained staff from another area. If it's a system or supply problem, I'd get the right person on it straight away. Within that hour I'd also work out realistically how much we can still hit. Then I'd call the client's account owner, not email, and say exactly which orders will be late and when they'll arrive, before the client finds out on their own. Afterwards I'd find out why the dashboard warned us so late and fix that too."

"I wouldn't start with 'you shouldn't have promised that'. I'd first work out the gap in plain numbers: what turnaround we can hit today for this volume, and what it would take to hit theirs, whether that's more people, another shift or a process change. Then I'd sit down with the sales lead and bring options. For example, we meet their promise for part of the volume from day one and the rest after a month, or we add weekend cover at a cost that someone needs to approve. We'd agree one plan together and, if needed, sales and I would talk to the client jointly so the message is consistent. Afterwards I'd push for a simple rule that operations signs off on service promises before a contract goes out."

"At a manufacturing plant I worked at, leadership asked us to reduce running costs, and weekend overtime was the biggest line we could control. When I broke it down, most of it was rework: batches that failed final inspection and were fixed on Saturdays. So rather than cutting hours, we went after the defects. Most came from one assembly step, so we added an in-process check there and retrained the two crews with the highest defect rates. Overtime fell by roughly half over a quarter. Before we started, I agreed three guardrails with my manager: first-pass yield, on-time shipment and the near-miss count. I reviewed them weekly next to the cost, and if any had got worse two weeks running, we'd have paused and looked again. None did, and first-pass yield actually went up."

"My first job is my own customers, so I'd look at what's at risk this week and whether we can cover it from stock, from another site, or from a backup supplier, even at extra cost for a short while. Then I'd get the vendor's account manager on a call with the facts: the three dates, how late each was, and what it cost us. I'd ask for their root cause and a written recovery plan, not just an apology. We'd agree clear targets and a weekly check-in for the next month. If they meet it, fine. If they don't, I'd escalate to their senior management and look at the remedies in the contract, while I start qualifying an alternative with procurement so we're never this exposed again."

"I'd start by breaking the budget into its real parts, because a big cut has to come from a few big lines. Usually labour is the largest, so I'd look at overtime, rework and how well staffing matches demand hour by hour. Then vendor spend: contracts that auto-renewed, services we barely use, and terms we could renegotiate with procurement. After that I'd have a list of savings that don't touch service. If that list doesn't reach a fifth, I'd go back to leadership with the gap and the real options, for example a longer delivery window for some customers, with the saving and the risk of each. What I'd push back on is cutting safety, training or maintenance, because those savings come back later as injuries, breakdowns and staff turnover."

"The contract sets the rules, but performance comes from the routine around it. I agree a short scorecard with each key vendor, usually on-time delivery, quality or error rate, and how fast they respond to problems, and we agree exactly how each is measured so we're not arguing about the numbers. There's a short weekly call at working level to deal with issues while they're small, and a quarterly review with their manager where we look at trends and agree improvements on both sides, because sometimes our late forecasts are part of the problem. I also make sure there's one named contact on each side and a clear escalation path. Contract penalties are a last step, not how I start the relationship."

"Our main warehouse management system went down at the start of a peak evening shift, with no estimate for when it would come back. First I made sure nobody was driving equipment blind in the aisles, then I called IT and my manager and set a check-in every thirty minutes. We had a paper fallback that nobody had practised, so I put my two most experienced leads on it and switched to picking only the most urgent orders from printed lists. I told customer service exactly which orders were at risk so they could warn clients early instead of guessing. The system came back after about four hours, and we cleared the backlog by the next afternoon. In the review, the big lesson was the untested fallback, so we now run a short downtime drill every quarter."

"In a claims processing team I managed, we moved from shared email inboxes to a proper case system, and the experienced staff hated it. They said it was slower, and in the first week it was. Instead of pushing harder, I spent two days working cases alongside them. Some of their complaints were fair: the new screen forced them to fill in a dozen fields on even the simplest case. We got the system team to cut that to the four that mattered. I also asked two of the most respected people on the team to test the updated version and give everyone their honest view, which carried more weight than anything I could say. We tracked cases per day and how many were logged properly, and within about a month output was above the old level and nobody wanted to go back."

"In a back-office team I ran, everyone believed Mondays were our worst day for missing the response-time target, and we'd been adding extra staff every Monday for months. When I pulled six months of case data, Monday volume was high, but we mostly coped. The real problem was Thursday afternoons, when two large partners sent their weekly batches within the same couple of hours. Before acting, I checked the timestamps against the system logs to make sure it wasn't a reporting quirk. We moved some of the Monday cover to Thursday afternoons, and asked one partner if they could send their batch in the morning, which they were happy to do. Missed targets on Thursdays dropped sharply, and Mondays didn't get worse."

"I'd keep it to about six, balanced so one can't be gamed at the expense of another. On service, on-time completion against the SLA. On quality, first-time accuracy, because errors create rework and complaints. On productivity, units per labour hour, which ties output to cost. On safety, incidents and near misses, and I actually want near misses reported, so a rising count isn't automatically bad. On people, absence and overtime, which are early signs of burnout. And one early-warning measure, usually the backlog at the start of each shift, because it tells me today's service is at risk before the SLA is missed. Each has an owner and a target, and we look at it every morning in a short huddle, not a long meeting."

"First I'd check the signal. Complaints doubling isn't the same as late deliveries doubling. Maybe volume grew, or we made complaining easier. So I'd pull actual on-time rates for the same period and compare them with the months before. If lateness really is up, I'd slice it by site, route, carrier, customer, product and day of the week, because a real cause usually shows up in one slice. Then I'd follow the order step by step, from order received to picked, packed, handed to the carrier and delivered, and see which step has got longer. That usually points somewhere specific, like a new carrier on two routes or a cut-off time that changed. I'd confirm it with a small test before changing anything across the whole operation."

"The practice stops that same shift, even if output drops. 'Nobody's been hurt yet' just means we've been lucky. Then I'd talk to the supervisor privately. I'd be clear that skipping a safety step isn't acceptable, and I'd follow our policy on how that's recorded. But I'd also want to know why an experienced person felt they had to. Often it's because the target assumes a pace that's only possible without the step, and that's my problem as much as theirs. So I'd look at the target and the staffing, re-brief the whole team on the step and why it matters, and do some unannounced checks over the next few weeks. I'd also check whether other shifts had picked up the same shortcut."

"A good SOP is one a new starter can follow on their own at the workstation. That means short, numbered steps, photos where they help, and the safety points and quality checks marked so they can't be missed. I write them with the people who do the job, then test them by having someone new follow them while I watch. Every SOP has an owner, a version number and a review date. To stop them going stale, I review them on a fixed cycle, and also whenever something changes: new equipment, an incident, a customer requirement or an audit finding. And I keep only one current version, easy to find where the work happens, because old copies taped to a wall cause a lot of mistakes."

"If we have to scramble, it means we're only compliant on audit day, which is the real risk. So I keep a simple register of everything that applies to us, like safety checks, training certificates, equipment inspections and customer or regulatory requirements, and give each one an owner and a frequency. Then I build the checks into normal routines: equipment checks at the start of each shift, training records updated when someone qualifies, not months later. Rules differ by country and industry, so I work closely with our health and safety or compliance lead on what applies. Every month or two we run our own mini audit on one area, and every finding goes on a tracker with an owner and a date until it's closed."

"First, I'd work the cover options quickly: the voluntary overtime list, anyone from the day shift who's willing to stay a few hours, cross-trained people from another area, and agency staff if our budget allows it. While that's happening, I'd look at the forecast and decide what absolutely has to go out tonight, usually the orders with the tightest delivery promises, and what can safely move to the morning. I'd brief the supervisor on that priority list so the team isn't trying to do everything. What I wouldn't do is put someone untrained on a forklift to fill the gap. At the end of the shift, the handover would say exactly what was moved so the day shift can plan for it."

"I'd start from the forecast. Say a shift has to handle 1,200 orders, and a trained person handles 15 an hour. An eight-hour shift with breaks and a huddle gives roughly seven productive hours, so one person does about 105 orders. 1,200 divided by 105 is about 11.4, so twelve people actually working. But not everyone rostered turns up. If about one in seven planned hours is lost to leave, sickness and training, I divide that 11.4 by six-sevenths, which takes me to roughly 13.3, so I'd roster fourteen. Then I'd check the hourly profile, because if half the orders land in the last three hours, fourteen spread evenly won't work, and I'd need a later start or a short overlap shift."

"The easiest sign is where work piles up. If there's a queue in front of one step and the step after it keeps waiting, that's usually the bottleneck. I'd confirm it by comparing each step's real capacity per hour. The key idea is that the whole process can only go as fast as that one step, so speeding up a step before it just grows the queue, and speeding up a step after it just means more waiting. To improve it, first make sure it never stands idle: cover breaks, keep work ready for it, and move any work it doesn't need to do onto other steps. Only then add capacity there. Once you fix it, the bottleneck moves somewhere else, so it's an ongoing job."

"It sounds efficient to keep everyone busy all the time, but work never arrives evenly. Orders come in bursts and some tasks take much longer than others. When a team has some slack, a burst gets absorbed quickly. When it's already running near full, every burst adds to a queue that has no time to clear, and waiting times climb far faster than the workload does. The last bit of utilisation is where service falls apart. Near-full utilisation also leaves no time for training, fixing problems or covering absence, so things get worse over time. So I plan for some headroom on purpose and fill quiet periods with training and improvement work, which I can drop the moment volume spikes."