Interview Loop and Assessment Criteria

What the role is assessed on

A data analyst collects, manages, explores and shares data to support organisational objectives and deliver business impact. That one sentence sets the scope of the whole loop: you are scored on the path from raw data to a decision somebody can act on, not on one tool in the middle of it.

The published role standard breaks the level down into three habits: prepare and manage data, apply appropriate techniques and tools, and communicate data to stakeholders with different needs. Expect each of the three to appear somewhere in the interview.

Neighbouring jobs own the stages either side.

Claiming one of the other stages describes a different role, not a smaller version of this one.

Prepare from the job description

The job description names the skills the panel will look for, so it decides which examples are worth rehearsing. Read it before you plan anything else, then pick the two or three pieces of your own work that show those exact skills.

Preparation is evidence, not coverage. Drilling your weakest tool, reusing your freshest project or reading the employer's product news can all help later, but none of them points to the skills this role needs most.

A stage may be a technical discussion, a coding exercise, a portfolio review or a presentation of work samples. Those four need different preparation, so ask the recruiter which one you will face. A question such as "which language should I practise?" quietly assumes a format you may not get.

The interview runs both ways: the hiring team gets to know you and you get to know the team, so bring questions about the role and the people in it.

Show how you think

Briefs in interviews are deliberately underspecified. When the brief is ambiguous, ask which data, which period and which audience count, and say out loud which assumptions you are making. Then agree a plan before you start to implement anything. The round is short, and the plan is what keeps it inside the time box.

Worked example. The interviewer asks why sales fell, and you have little time. First, ask which sales measure, which period and which audience matter. State any assumption you cannot confirm. Next, compare a quick summary by month with a fuller breakdown by product. Say what each one can answer and what it leaves uncertain, then pick the one that still leaves time to check the result. If the check fails, describe the failure and narrow the conclusion instead of widening it.

Talking through your approach, including the tools you chose and why, is what makes the problem solving observable. A correct final table shows where you arrived, not how you got there. A cross-check, a cleaner chart or a faster run all improve the delivery and still leave the reasoning hidden.

Structure your examples with STAR(R)

The STAR(R) structure covers Situation, Task, Action, Result and Reflection, and the final R is what you learned and would do differently. The first four elements are the story; the fifth is the one an interviewer cannot infer from it.

Keep the action in the first person. "The team migrated the report" tells the panel nothing about you; "I defined the measure and checked the duplicates" does.

Work inside the constraint

A technical round scores how you break the problem down and the methods you use, not only the final answer. Two candidates can hand in the same number and score differently: one showed the framing and the checks, the other showed only the output.

When you finish a solution, test it before you call it done, and if a case fails, say what failed and what your conclusion still covers. An unfinished check is information the panel wants. Spending the last two minutes on a rushed fix usually ends with neither the fix nor the explanation.

Communicating data to stakeholders with different needs means leading with the decision and its limit, then going deeper for whoever asks. With a manager and an analyst in the same room and two minutes left, the plain answer and the caveat come first; the mechanism goes to the person who wants it.

Review your own attempt

A practice round that felt bad is not something you can act on. A useful self-review separates problem framing, technical correctness, validation and communication, so one hour goes to the part that failed. Score the attempt on each of the four, then spend the time on the lowest one.

Reflection is also what you owe the next round. Repeating the whole exercise rehearses your strong parts as often as your weak ones, and polishing the opening assumes you already know where it broke.