Business Analyst Assessment

Why Business Analysts are hard to hire well

Business Analyst is the most overloaded job title in the industry, and the ambiguity is not accidental: organisations create the role to absorb whatever falls between the business and the people building things. At one company it is a requirements and process discipline. At another it is reporting and SQL. At a third it is a junior product manager with no mandate. All three write the same two words on a CV, and all three can talk fluently about stakeholder engagement.

The output makes it worse. A Business Analyst produces documents, and documents are judged on how they read rather than on whether they work. A specification can be well structured, properly formatted, comprehensively cross-referenced and still contain a dozen sentences that two competent people would implement differently. That defect is invisible on the page. It surfaces in UAT, or in production, when the cost of fixing it has multiplied.

There is also a timing problem in the feedback loop. The consequence of weak analysis shows up as rework six months later, attributed to changing requirements or poor estimation, almost never traced back to a discovery session where nobody asked the awkward question. Hiring managers rarely get clean evidence about which of their previous analysts was actually good.

What separates the best from the rest

The strongest analysts treat an ambiguous sentence as a defect, not as a stylistic matter. They read their own drafts adversarially, hunting for anything that could be satisfied in two ways, and they specify the edge cases everyone else defers: what happens to in-flight items at cutover, what the system does when the third-party service times out, who can override and what gets logged when they do. That habit is where most delivery risk is actually removed.

They also distinguish between what people ask for and what they need, without being precious about it. A stakeholder requesting a new report is usually describing a solution to a problem they have not articulated. Weak analysts document the report. Good ones spend ten minutes finding out what decision it feeds, and often discover the real requirement is a change to an alert, or to a process, or to nothing at all.

The difference shows most clearly under disagreement. When two process owners want incompatible things, weak analysts either escalate immediately or write a specification that vaguely accommodates both, which is the same as choosing neither. Strong ones narrow the disagreement to a single decision, name what each option costs, put it in front of whoever can actually decide, and record the decision so it stays decided.

Why interviews alone fall short

The standard Business Analyst interview asks the candidate to describe a project they worked on. This measures narrative skill. Everybody’s project was complex, everybody’s stakeholders were difficult, and everybody’s outcome was successful. The retrospective account is smoothed by hindsight into a clean sequence of good judgements, and no interviewer can distinguish a story from the messy reality it was built from.

Asking for a writing sample sounds like the fix and mostly is not, because the sample was written for a different context, reviewed by other people, and often improved by the team that used it. What you need to see is the candidate deciding in real time: which question to ask first when the brief is contradictory, what to do when a requirement surfaces late, whether to hold the date or open the scope. Situational judgement scenarios put every candidate at exactly those forks, with the same information and the same constraints.

Common hiring mistakes in business analysis recruitment

• Hiring a coordinator and calling them an analyst - candidates who are strong at running meetings and tracking actions can look excellent in interview and never actually specify anything
• Treating certification as evidence of judgement - a formal qualification demonstrates knowledge of techniques, not the discrimination to know which technique a given mess needs
• Assuming SQL fluency implies requirements ability - they are unrelated skills, and a role that needs both should test both rather than assume one predicts the other
• Never testing for the awkward question - the value of the role concentrates in the moment somebody says something that does not fit, and shy analysts let those moments pass
• Judging documentation by its structure - a well-organised specification full of untestable statements is worse than a scrappy one whose acceptance criteria are exact

The work this role is assessed against

• Run discovery workshops and stakeholder interviews to clarify objectives
• Write SQL queries and build BI dashboards to explore and communicate insights
• Create process maps and data flow diagrams to identify gaps and opportunities
• Draft user stories with clear acceptance criteria and maintain backlog hygiene
• Develop UAT scripts, coordinate testing, and track defects to closure

Tools and outputs this role works with

Microsoft Excel or Google Sheets, SQL (SQL Server, PostgreSQL, MySQL), Power BI or Tableau, Looker and Looker Studio, Jira or Azure DevOps for user stories and backlog, Confluence for documentation, Lucidchart or Microsoft Visio for process maps, Snowflake, BigQuery or Redshift, Salesforce or HubSpot for CRM reporting, Python (pandas) or R for basic analysis, Microsoft PowerPoint or Google Slides, and Mode or Metabase for ad hoc analytics.