Data Analyst Assessment

Why Data Analysts are hard to hire well

The defining property of analytical work is that a wrong answer looks exactly like a right one. A dashboard built on a join that quietly duplicates rows renders just as cleanly as a correct one. The chart is the same colour. The number is plausible. Nobody in the room can tell, which means nobody catches it until a decision has already been made on the back of it, usually months later and usually by accident.

That single fact breaks the standard hiring process. In most roles you can watch the output and form a view. Here the output is a number, and evaluating a number requires redoing the work. So interviewers fall back on proxies: which tools the candidate has used, how big the data was, whether they can define a window function. All three are easy to fake and none of them predict whether this person’s figures will be right.

The title compounds it. Data Analyst covers someone who refreshes a weekly spreadsheet from a report somebody else built, and someone who owns metric definitions for a whole business unit. Both have three years of experience. Both list SQL, Python and Tableau. The gap between them is enormous and almost invisible on a CV.

What separates the best from the rest

Strong analysts are suspicious of their own results. They check row counts before and after a join. They sanity-check a total against a source they did not build. When a number moves fifteen per cent they assume a data problem first and a business change second, because the first is far more common. This instinct is the whole job and it is nearly impossible to interview for directly, because every candidate will say they validate their work.

They also refuse to accept a question at face value. A request for last quarter’s churn is not a specification, it is the opening of a negotiation. Which churn, measured against which denominator, over what window, counting accounts or subscriptions or seats. Weak analysts answer the question as asked and produce something technically correct and practically useless. Strong ones spend two minutes establishing what decision the number is for, then answer the question that was meant.

The clearest divide is what happens after delivery. Weaker analysts consider the ticket closed when the file is sent. Better ones know that an analysis nobody acts on has failed, whatever its technical quality, and they treat adoption as part of the work: naming the recommendation, stating what they would do, and following up on whether anything changed. Most organisations have a graveyard of unused dashboards, and every one of them was technically correct.

Why interviews alone fall short

The two standard formats both miss. A live SQL exercise tests syntax under artificial pressure against a clean schema, which is the easiest version of the job and the one least like it. A take-home case gives the candidate unlimited time, the internet, and, increasingly, a model that will write the query for them. Neither tells you what happens when the data is messy, the request is vague and the deadline is this afternoon.

Conversation fares no better, because analytics has a rich vocabulary that costs nothing to acquire. Data quality, reproducibility, single source of truth, stakeholder alignment. A candidate who has read two blog posts sounds identical to one who has spent three years fixing broken pipelines at two in the morning. Situational judgement scenarios put every candidate in front of the same untidy data, the same impatient stakeholder and the same incomplete brief, so you compare decisions rather than vocabularies.

Common hiring mistakes in analytics recruitment

• Testing SQL syntax rather than SQL judgement - the failure mode in real analytical work is a technically valid query that answers a subtly different question, and syntax tests cannot see that
• Treating tool experience as transferable evidence - a strong analyst moves from Tableau to Power BI in a fortnight, and a weak one who knows both will still produce dashboards nobody opens
• Hiring for modelling ability when the need is reporting - candidates who want to build models will be bored inside six months by a role that is mostly metric definitions and stakeholder requests
• Ignoring how the candidate handles being wrong - everyone ships a bad number eventually, and what matters is whether they find it themselves and say so quickly
• Skipping the requirements conversation entirely - most analytical waste is not bad queries, it is good queries answering questions nobody needed answered

The work this role is assessed against

• Write and optimise SQL to join large tables, create views, and validate results
• Build Tableau, Power BI or Looker dashboards with well-defined, documented metrics
• Perform cohort, funnel, and segmentation analyses; visualise and summarise findings
• Analyse experiments (A/B tests), compute lift and confidence, and recommend actions
• Partner with stakeholders to clarify requirements, prioritise requests, and track impact

Tools and outputs this role works with

SQL (PostgreSQL, MySQL, SQL Server), Excel or Google Sheets, Python (pandas, numpy), R (dplyr, ggplot2), Jupyter or VS Code, Tableau, Power BI, Looker and LookML, Mode or Metabase, Qlik Sense, dbt, Snowflake, BigQuery, Amazon Redshift, Databricks, Git and GitHub, Google Analytics 4, Mixpanel or Amplitude, and basic familiarity with Airflow.