Operations Analyst Assessment

Why Operations Analysts are hard to hire well

This role sits on a fault line between two professions and gets hired as though it belongs to one of them. Recruited as an analyst, you tend to get someone technically strong who produces immaculate work that never leaves the reporting layer. Recruited as an operations person who is good with numbers, you tend to get someone credible on the floor whose analysis quietly rests on a spreadsheet with a broken lookup in it. Both hires look correct for about three months. The role actually requires the combination, and the combination is much rarer than the job market’s supply of either half.

The output problem makes it worse. An operations analyst’s work product is a decision somebody else took, which means the successful outcome is attributed to the person who acted on it, and the analyst’s contribution is invisible in exactly the way a project manager’s is not. Candidates therefore arrive describing dashboards they built and models they wrote, because those are the things they can point at. Very few can tell you what changed as a result, and a surprising number have never been asked.

There is also a data quality trap that catches inexperienced candidates and is nearly impossible to see in an interview. Operational data is worse than analytical data: definitions differ by team, systems disagree, and the same word means two things in two departments. An analyst whose training assumed a clean warehouse will produce confident answers from data that does not support them, and will do it faster and more persuasively than the cautious candidate who asks first where the field comes from. Speed and confidence read well in an interview. They are the wrong signal here.

What separates the best from the rest

The best operations analysts finish the sentence. A weak analysis ends with the observation that cost per unit has risen 8% in the northern region. A strong one ends with the observation, the two candidate causes, the evidence that distinguishes them, and the specific thing to change on Monday along with what it will cost. This is a habit rather than a technique, and it is the clearest single differentiator in the role, because the analytical work is often equivalent and only one version of it results in anything happening.

They also interrogate the definition before they interrogate the data. Given a metric that looks wrong, the instinct that separates strong from average is to ask what exactly is being counted, when the clock starts, and what happens to the edge cases, rather than to start slicing. Most surprising operational findings are definition artefacts, and an analyst who has learned this the hard way will check it in ten minutes. One who has not will produce a compelling narrative explaining a phenomenon that does not exist, and the narrative will be believed because it was well constructed.

The third difference is credibility with the people whose work is being measured. Operational change happens when a supervisor accepts that the number describes their reality, and that acceptance is earned by having been on the floor, having asked how the process actually runs, and having been right about something small before asking to be trusted about something large. Analysts who work entirely from the warehouse produce recommendations that are technically sound and organisationally inert. It is the most common way for good analysis to be wasted.

Why interviews alone fall short

The technical screen tests the part of the job least likely to fail. SQL joins, window functions and lookup logic are learnable, testable, and genuinely necessary, and a candidate who passes has demonstrated the entry requirement rather than the differentiator. Almost nobody in this role fails because they could not write the query. They fail because they wrote the right query against the wrong definition, or wrote it correctly and could not persuade anyone to act.

Case questions get closer but tend to be framed too cleanly. A well-posed interview case with defined metrics and available data is a different exercise from the real one, which usually begins with a manager saying that something feels slower than it used to and no agreement on what slower means. The skill being hired is the conversion of that into a measurable question, and interview cases nearly always hand the candidate the converted version, which is the hard part already done.

Portfolio review has the reverse problem. Dashboards are easy to evaluate on appearance and almost impossible to evaluate on effect, and the ones that photograph best are frequently the ones that tried to show everything. Without knowing whether operators opened it, trusted it, or changed anything because of it, you are assessing visual design. Scenarios sidestep this by testing the judgement directly: the same ambiguous operational problem, the same imperfect data, and a decision that has to be defended.

Common hiring mistakes in operations analytics recruitment

• Hiring a pure data analyst and expecting operational change - the technical work is the same, the instinct to finish with a recommendation is not
• Screening on SQL and stopping there - it is the entry requirement, and the role almost never fails there
• Accepting dashboards as evidence of impact - a dashboard proves something was built, not that anyone used it
• Assuming clean-warehouse experience transfers to operational data - confident answers from unreliable fields are worse than slow ones
• Underrating floor credibility - a recommendation that supervisors do not believe changes nothing, however sound the analysis
• Never asking what they got wrong - an analyst who has never had a number challenged and lost has not worked close enough to the operation
• Testing tools rather than definitions - most surprising findings are artefacts of what was counted, and the check takes ten minutes if the habit exists

The work this role is assessed against

• Write SQL queries and transform data for BI dashboards and recurring reports
• Map current and future state processes, and document SOPs, SLAs, and controls
• Conduct root cause analyses and design experiments and pilots to validate solutions
• Build capacity and throughput models and scenario analyses to guide resourcing and planning
• Run monthly and quarterly business reviews and drive action tracking with stakeholders

Tools and outputs this role works with

Microsoft Excel and Google Sheets, SQL across PostgreSQL, MySQL or SQL Server, Tableau, Power BI or Looker, Salesforce or an equivalent CRM, ERP systems such as SAP, Oracle NetSuite or Microsoft Dynamics, warehouses including Snowflake, BigQuery and Redshift, Alteryx, Power Query or dbt, Jira, Asana or Trello, Lucidchart and Miro for process mapping, Python or R for analysis and automation, Mode, Metabase or Looker Studio, and Confluence or Notion for documentation.