This guide gives {{Company name}} a structured loop for data roles — data analysts, data scientists, and analytics engineers. Data interviews drift easily into trivia; this loop instead tests the skills that predict success: writing correct SQL under realistic conditions, reasoning about ambiguous metrics, and turning analysis into decisions someone actually makes.

Stage plan

Competency map

• SQL and data fluency — writes correct, readable queries and manipulates messy data without hand-holding.
• Statistical rigor — knows when a difference is signal, when it is noise, and when the data cannot answer the question.
• Business framing — starts from the decision to be made, not from the data that happens to exist.
• Communication of insight — turns analysis into a clear recommendation a non-technical stakeholder can act on.
• Data quality judgment — spots broken pipelines, definition drift, and misleading aggregations before publishing.

Question banks by stage

Recruiter screen

• Which parts of data work energize you most — building pipelines, analysis, experimentation, or reporting?
• What is your daily stack — warehouse, transformation, BI, notebooks?
• Tell me about the team you worked with: who consumed your work?
• What are you looking for that your current role does not offer?
• What are your compensation expectations and availability?

Hiring manager interview

• Walk me through the analysis you are proudest of. What decision did it change?
• Tell me about an analysis that turned out to be wrong. How did you find out, and what did you do?
• How do you decide when an analysis is good enough to ship versus needing another week?
• Describe a metric you defined from scratch. What edge cases did you have to resolve?
• Tell me about a stakeholder who kept asking for dashboards nobody used. What did you do?
• What is the most misleading chart or metric you have seen in production, and why was it misleading?

Technical screen

Use a realistic multi-table dataset — orders, users, events — and let the candidate use their preferred SQL dialect and documentation. Evaluate process, not memorization.

• Write a query joining three tables to compute a monthly retention or repeat-purchase rate.
• Find and explain a data-quality problem planted in the dataset — duplicates, nulls, a timezone shift.
• Refactor a deliberately convoluted query into something a teammate could maintain.
• Compute a window-function metric: running totals, rank within group, or a moving average.
• Explain the difference between two join strategies for this schema and when each result would differ.
• Sanity-check a result: does the number pass a back-of-envelope estimate, and how would they verify it?

Analytics case

• A core metric dropped twelve percent week over week. Walk me through your first hour.
• How would you decompose the drop — by segment, platform, cohort, or data-pipeline cause?
• Design an experiment to test the leading hypothesis. What is the unit of randomization and the guardrail metric?
• The experiment shows a two percent lift with a wide confidence interval. What do you recommend?
• What would you monitor after launch, and when would you revisit the decision?

Stakeholder and values interview

• Explain a technically complex analysis you delivered to a non-technical audience. How did you structure it?
• Tell me about a time a stakeholder wanted data to confirm a decision already made. What did you do?
• When have you pushed back on a request because the data could not support the conclusion?
• How do you handle two teams defining the same metric differently?
• What does responsible use of data mean to you in practice?

Scoring anchors

Score each competency 1 to 4 with written evidence, immediately after each stage. Weight the technical screen and the analytics case most heavily for senior candidates.

• 1 — Below bar: SQL errors go unnoticed, jumps to conclusions without checking data quality, answers describe tools rather than decisions.
• 2 — Near bar: competent queries with prompting; frames analysis in terms of outputs, not decisions.
• 3 — At bar: correct, verifiable work; states assumptions; connects every analysis to the decision it informed.
• 4 — Above bar: anticipates data traps, quantifies uncertainty naturally, and reframes vague questions into answerable, decision-ready ones.