What do supply chain analyst interviews actually test?

Who actually runs the interview

For most supply chain analyst roles you will meet at least two different people, and they are not testing the same thing.

The first conversation is usually with a recruiter or the hiring manager's line report — often someone from HR or a supply chain manager doing a screen. This stage checks the basics: which planning systems you have used (SAP APO or IBP, Oracle SCM Cloud, Kinaxis RapidResponse, or a homegrown Excel/Power BI setup), what you were actually responsible for versus what your team did, and whether your notice period and salary expectation match the role.

The second stage is where the job gets tested, and it is usually run by the person who would be your manager or a senior analyst on the team — someone who reads a demand plan or a supplier scorecard every week and knows exactly what a vague answer sounds like. In manufacturing or FMCG companies you may also meet someone from procurement or operations if the role touches supplier performance. In retail or distribution, expect someone from inventory or logistics planning. If the company runs a formal S&OP (sales and operations planning) cycle, whoever chairs that meeting sometimes sits in, because they need to trust you with the numbers that feed it.

The technical screen: what gets tested and how

Most supply chain analyst interviews include some form of practical exercise, and it usually takes one of three shapes.

A spreadsheet exercise. You are given a dataset — historical demand, inventory levels, or purchase order lines — and asked to produce something from it: a forecast, a reorder point calculation, an ABC classification, or a root-cause breakdown of why service levels dropped in a given month. What they are watching is not whether you get a "correct" number, because these exercises are often deliberately open to more than one reasonable approach. They are watching whether you check your assumptions, whether you spot a data quality problem (duplicate SKUs, a unit-of-measure mismatch, a promotional spike you should exclude from a baseline), and whether you can explain your method in plain language afterwards. An analyst who produces a tidy chart but cannot say why they excluded three data points has not really done the analysis.

A live walkthrough of your own work. You bring a report or model you built in a previous role — a safety stock calculation, a supplier scorecard, an S&OP deck — and talk through it. This is harder to fake than it sounds, because a competent interviewer will ask you to change one input and predict what happens downstream. If you built the forecast bias tracker, you should be able to say, without opening the file, what happens to your safety stock recommendation if lead time variability doubles.

A case-style scenario. "A key supplier tells you tomorrow's shipment is delayed two weeks. Walk me through what you do." There is no spreadsheet here — they want your sequence of thinking: check current inventory position and days of cover, check which downstream customers or production lines are exposed, check whether there's an alternative source or expedite option, and only then talk about communicating the risk. Analysts who jump straight to "I'd expedite a shipment" without first establishing exposure usually haven't done this under real pressure.

Some employers, particularly larger manufacturers and 3PLs, also ask about certifications — APICS/ASCM's CPIM or CSCP, or a Lean Six Sigma belt — not usually as a hard requirement but as a proxy for whether you know the vocabulary (EOQ, MRP logic, bullwhip effect, DIFOT/OTIF) without having to be taught it on the job.

The questions that separate practice from theory

A few questions come up often enough, and in enough different forms, that it's worth knowing what a real answer sounds like.

"How do you measure forecast accuracy?" A shallow answer names a metric — MAPE, or forecast bias — and stops there. A real answer explains the trade-off: MAPE penalises low-volume SKUs disproportionately, which is why some analysts weight it by volume or use a weighted MAPE (WMAPE), and why bias (are you consistently over- or under-forecasting) often matters more operationally than accuracy alone, because bias is what drives you to either write off excess stock or run out. If you've only ever pulled a number a planning tool generated for you without knowing how it's calculated, this question will find that out.

"Tell me about a time your forecast or plan was wrong. What did you do?" This isn't a trick question about admitting failure — every forecast is wrong to some degree. What they're listening for is whether you have a process for finding out why it was wrong: did you go back and separate the error into volume, mix, and timing components? Did you trace it to a specific cause (a promotion that wasn't flagged, a new customer not yet in the baseline, a supplier substitution)? Or did you just re-run the model with a manual override and move on. The second is common. It is not what gets you the job.

"How do you decide safety stock levels?" A shallow answer recites the formula — safety stock as a function of service level, demand variability and lead time variability — without being able to say which of those inputs actually moves the number in your business. A stronger answer talks about where the real uncertainty sits: is it demand-side (a volatile customer base) or supply-side (unreliable lead times from an overseas supplier), because the intervention is completely different depending on which one dominates.

"Walk me through how you'd investigate a drop in OTIF (on-time-in-full) or a rise in stockouts." They're checking whether you know to separate the two failure modes — a stockout is an inventory problem, a late delivery might be a transport or supplier problem — and whether you'd segment by SKU, region, or supplier before drawing a conclusion, rather than reporting a single aggregate number and guessing at a cause.

"What ERP or planning systems have you worked in, and what did you actually do inside them?" This sounds like a checklist question but it isn't. Someone who has genuinely built MRP runs in SAP, set planning parameters in APO or IBP, or configured a reorder point logic in Kinaxis will describe the specific screens and fields involved. Someone who has only pulled reports from a system that someone else configured will describe it in much vaguer terms — "we used SAP for planning" — without being able to say which module or which parameters they actually touched.

What a shallow answer sounds like

The pattern across all of these is the same. A shallow answer names the right term and stops. A real answer explains the mechanism behind the term and where it breaks down in practice.

Someone asked about EOQ (economic order quantity) who says "it balances ordering cost against holding cost" has given you the textbook definition. Someone who adds "but we rarely used it as calculated, because our supplier had a minimum order quantity that overrode it half the time" has actually used it.

Someone asked about a service level target who quotes a single number for the whole business — rather than saying it varies by product tier or customer segment — is often describing a policy they were told about, not one they built or manage.

The other reliable tell is what happens when you ask a follow-up. "You said forecast accuracy improved after that change — improved by how much, and over what period?" A real analyst can usually give you a rough figure and the comparison basis, because they were the one pulling that number. Someone reciting a result they heard about secondhand tends to repeat the same vague phrase — "it improved significantly" — without being able to add anything underneath it.

Before you go in

Bring one piece of work you can talk through in detail, ideally something with a number attached that you can defend under a follow-up question — a forecast model, a safety stock review, a supplier scorecard. Know the difference in your own head between forecast accuracy and forecast bias, and between a stockout caused by demand and one caused by supply, because both distinctions come up in some form in nearly every technical interview for this role. If the job description names a specific system — SAP IBP, Kinaxis, o9, Blue Yonder — check what you actually did in it versus what you watched a planner do, because that gap is exactly what the interview is built to find.

jobmarket.pro reads the advert alongside your work history and prepares an application that states clearly where your experience matches and where it does not, without inventing either.