Tell me about yourself.
Give a 60–90 second professional summary: what you do now, the most relevant experience you bring, two or three strengths that match the role, and why this opportunity is the logical next step. Do not retell your entire CV.
Technical + behavioural preparation
Know the answer. Explain the reasoning. Show how you work.
Technical interviews rarely test syntax alone. Employers also want to see how you clarify a problem, validate data, communicate trade-offs and respond when something goes wrong. Use this guide alongside the practical interview sections in each Learning Library guide.
How to approach a practical technical test
A technically correct answer is stronger when the interviewer can see that you understand the data and can defend the approach.
Clarify the taskRepeat the business question in your own words. Ask about expected output, edge cases, grain and assumptions.
Inspect before codingCheck columns, data types, row counts, nulls, duplicates and keys before writing the final solution.
Think aloudExplain why you chose a join, function, formula or model. Reasoning is often assessed as much as syntax.
Build in small stepsProduce an initial correct result, inspect it, then add complexity.
Validate the answerCheck totals, unmatched keys, duplicates, edge cases or a small manual example.
Discuss trade-offsIf several approaches are valid, say why you chose one and when you would use another.
Handle errors calmlyRead the error, isolate the smallest failing step, inspect inputs and say what you will test next.
Finish with meaningExplain what the result tells the stakeholder and any limitations or follow-up checks.
A useful live-test sentence: “Before I write the final query, I’d like to confirm the grain of the table and whether this key is unique. I’ll build the result in steps and then reconcile the row count and totals.”
How to answer a technical definition question
Do not begin with a long textbook definition. A strong interview answer usually has four parts.
1. DefineSay what the term is in one clear sentence.
2. DistinguishCompare it with the nearest concept people confuse it with.
3. UseSay when or why you would use it.
4. ExampleGive a short practical example if useful.
Example — “What is a CTE?”
“A CTE is a named result set defined with WITH and available to the statement that follows. I mainly use it to make a complex query easier to read or for recursive logic. Unlike a temporary table, it is not normally created as a separate stored object that I can reuse across several statements.”
Tool-specific practical preparation
Each guide now contains common practical tests, worked answers and an explanation of what the interviewer is testing.
Pythonpandas, cleaning, joins, data structures and model judgement.
Rdplyr, joins, missing data, reshaping and statistical reasoning.
SQLjoins, windows, ranking, CTEs, procedures, QA and performance.
Excellookups, SUMIFS, references, PivotTables and Power Query.
Power BIstar schemas, measures, storage modes, RLS and performance.
DAXcontext, CALCULATE, SUMX, shares and measure design.
Behavioural questions: use STAR without sounding rehearsed
Behavioural questions use past evidence to understand how you are likely to work in future. STAR keeps your answer structured, but the Action should normally be the longest part because it shows what you personally did.
SituationGive only the context needed to understand the example.
TaskState your responsibility, target or problem.
ActionExplain your decisions and what you personally did.
ResultGive the outcome, evidence and what you learned.
Useful balance: Situation 10–15%, Task 10%, Action 55–65%, Result and learning 15–25%.
Avoid: spending two minutes describing the background and only one sentence on what you actually did.
Common behavioural questions and how to respond
Prepare several genuine examples that can be adapted across these themes rather than memorising fifteen separate speeches.
Why do you want this role?
Connect three things: the work in the job description, evidence that you can do it, and what you genuinely want to develop or contribute. Make the answer specific to the role.
Tell me about a difficult data project.
Use STAR. Explain what made it difficult—poor data quality, unclear requirements, time pressure or technical constraints—then focus on how you diagnosed the problem, prioritised risks, communicated and delivered a reliable result.
Tell me about a mistake you made.
Choose a real but recoverable mistake. Explain how you detected it, corrected the impact, informed the right people and changed the process so the same error was less likely to recur.
Tell me about a time you disagreed with a stakeholder.
Show respectful challenge. Explain how you clarified the real need, used evidence, offered options and reached a decision. The aim is not to prove that you won.
How do you explain technical findings to a non-technical audience?
Start with the decision or question, remove unnecessary technical detail, use plain language and an appropriate visual, state limitations, and check that the audience understands the implication.
Tell me about a time priorities changed suddenly.
Show how you reassessed urgency and impact, clarified the new priority, renegotiated deadlines where needed, protected critical quality checks and kept affected people informed.
Tell me about a missed deadline.
Take ownership. Explain the cause without blaming others, what you communicated, how you recovered the work, and what changed in your planning, estimation or escalation afterwards.
Tell me about a time you improved a process.
State the original problem and cost, describe the improvement you introduced, how you tested or gained buy-in, and quantify the result where possible: time saved, errors reduced or turnaround improved.
Describe a time you worked with poor-quality data.
Explain how you profiled the data, identified missing or invalid values and duplicates, traced likely causes, agreed treatment rules, documented assumptions and added QA checks.
How do you handle ambiguous requirements?
Clarify the decision the analysis needs to support, identify users and definitions, write down assumptions, show an early prototype, confirm acceptance criteria and keep a record of changes.
Tell me about a time you influenced without authority.
Explain how you built credibility with evidence, understood the other person's constraints, presented a practical recommendation and gained agreement without relying on hierarchy.
What is your greatest weakness?
Choose a genuine development area that is not a core requirement you cannot perform. Explain what you are doing to manage it and give evidence of progress.
Why are you leaving your current role?
Stay constructive. Focus on the type of responsibility, environment or development you are moving towards. Avoid criticising your current employer or colleagues.
Why should we hire you?
Summarise the strongest match between the role and your evidence: technical capability, domain understanding, delivery experience and communication. Finish with the value you expect to add.
Build a reusable interview story bank
One strong project can answer several questions when you change the emphasis.
QualityA time you found an error, prevented a bad output or improved validation.
DeliveryA difficult deadline, competing priorities or a dependency you had to manage.
StakeholdersA time you clarified requirements, challenged a request or explained findings.
ImprovementAutomation, simplification, documentation or a process you made more reliable.
LearningA tool or domain you had to learn quickly and how you became productive.
TeamworkCollaboration, disagreement, mentoring or influencing without formal authority.
Worked STAR example — “Tell me about a time you found a data-quality problem.”
Situation: “I was preparing a recurring performance report and noticed that one organisation’s response count had changed much more than expected.”
Task: “I needed to establish whether the change was genuine before the report went to stakeholders.”
Action: “I reconciled the total row count against the source, checked duplicate keys and unmatched joins, then traced the difference to a mapping issue introduced in the latest file. I corrected the mapping, reran the affected outputs and added an automated QA check comparing source and reported totals so the same problem would be flagged earlier in future.”
Result: “The corrected report was issued with accurate figures, and the additional check became part of the routine process. The important lesson for me was to reconcile key totals before relying on downstream visuals.”
Final preparation checklist
Job descriptionMatch every essential skill to one piece of evidence from your experience.
DefinitionsExplain important terms in plain language without reading a memorised paragraph.
Practical tasksPractise joins, summaries, cleaning, validation and interpretation in the relevant tools.
ProjectsBe ready to explain purpose, data, approach, QA, result, limitation and your personal contribution.
CompanyKnow what the organisation does and how the role contributes.
Your questionsPrepare thoughtful questions about the team, data, priorities, expectations and success measures.
Research basis
The question themes were expanded after reviewing recent interview-preparation material from Indeed UK and Robert Half, including data-analyst, SQL, Excel, Python/pandas and Power BI interview guidance. SQL and Power BI technical definitions were checked against Microsoft Learn documentation. The explanations and worked answers in this library are written specifically for this resource.
- Indeed UK — Data analyst interview questions
- Indeed UK — Common SQL interview questions
- Indeed UK — Excel interview questions for data analysts
- Indeed UK — Python pandas interview questions
- Indeed UK — Power BI interview questions
- Robert Half — behavioural interview guidance
- Microsoft Learn — SQL Server views
- Microsoft Learn — CREATE PROCEDURE
- Microsoft Learn — CTEs
- Microsoft Learn — temporal tables
No matching interview sections were found. Try a broader search term.