Data analyst phone screen questions: SQL depth, BI tools and stakeholder work
On this page
- Which analyst role: answers, reporting or pipelines
- SQL depth: four questions and what the answers reveal
- BI tools and dashboards: built, maintained or viewed
- Stakeholder work: turning vague requests into answers
- The data quality story
- Experiments and statistics claims
- Tool-name dropping and other red flags
- Certificates, portfolios and technical tests
- Logistics, knockout checklist and scorecard
- Questions people ask
A data analyst phone screen should test whether the candidate has used data to answer real business questions, not whether they can list tools. Ask for the last query or analysis they did end to end: the question, the tables, how they checked the result, who used it and what decision changed. Analysts with real depth talk about joins that duplicated rows, numbers that did not match finance, and stakeholders who asked the wrong question. Tool-name droppers stay at "SQL, Python, Tableau, Power BI" and never reach a specific result.
Below are questions a non-technical recruiter can ask, with what strong and weak answers sound like, the red flags, certificate notes and a scorecard. For engineers who build data systems rather than analyze data, use software engineer phone screen questions.
Which analyst role: answers, reporting or pipelines
"Data analyst" titles vary widely. Before judging skill, find out what the candidate's week actually produced, and compare it with what the hiring manager needs.
| Type | What they mostly produce | Facts to ask for | Common mismatch |
|---|---|---|---|
| Business, product or marketing analyst | Answers to questions: why did sign-ups drop, which campaign worked, what should we price | Questions answered recently, who asked, what changed | Built reports only, applying for a role that expects recommendations |
| Reporting or BI analyst | Dashboards and scheduled reports others use | Dashboards built from scratch, users, refresh schedule, data sources | Maintained existing dashboards, described as building the reporting layer |
| Finance or operations analyst | Forecasts, variance analysis, operational metrics, often in Excel | Models owned, systems pulled from, who reviewed | Excel-heavy work presented as SQL analytics |
| Analytics engineer (sometimes titled analyst) | Cleaned, modeled tables that analysts query, often in dbt | Models built, testing, warehouse used | Strong pipeline skills but little stakeholder work, for an analyst role |
| Entry-level or career changer | Coursework, certificates, portfolio projects | Projects, datasets used, what they found | Course projects described as professional experience |
SQL depth: four questions and what the answers reveal
You do not need to write SQL to hear the difference between someone who reads queries, someone who writes them, and someone who designs the tables others query. Ask the four questions below in order and note where the answers stop getting more specific.
| Question | Beginner answer | Working answer | Strong answer |
|---|---|---|---|
| "Describe the last query you wrote. What question did it answer, and which tables did it use?" | "I pulled some sales data." | "Revenue by region last quarter, from orders joined to customers." | "Repeat purchase rate by acquisition channel: orders, customers and a marketing touch table, filtered to first orders in 2025." |
| "Tell me about a time a join gave you the wrong numbers. What happened?" | Cannot think of one. | "The totals were too high, so I added a DISTINCT." | "Revenue doubled because customers had several addresses. I found it by comparing row counts before and after the join and deduplicated the address table first." |
| "How do you check a result is right before you send it?" | "I look at it." | "I spot-check a few rows." | "I reconcile the total to a trusted number, like the finance dashboard, check row counts, and look for nulls in the fields I filtered on." |
| "What is something you do in SQL now that you did not know how to do two years ago?" | No answer, or a basic filter. | "Subqueries and CASE statements." | "Window functions, like ranking each customer's orders to find the first one, and CTEs so long queries stay readable." |
Also ask which database or warehouse they queried (Snowflake, BigQuery, Redshift, Databricks, SQL Server, Postgres) and roughly how big the main tables were. Someone who worked in it every week knows, at least to the nearest order of magnitude.
BI tools and dashboards: built, maintained or viewed
| Claim | Question | Strong answer | Red flag |
|---|---|---|---|
| Tableau | "Tell me about a dashboard you built from a blank workbook. Who used it and what did they decide with it?" | The audience, the key metric, a calculated field or level-of-detail expression they needed, and a decision it informed. | Edited filters on dashboards someone else built. |
| Power BI | "Did you build the data model and measures, or only the visuals?" | Describes relationships between tables, a DAX measure, or Power Query steps. | Visuals only, described as "Power BI developer." |
| Looker | "Did you write LookML, or explore data others had modeled?" | An honest answer with an example. | Cannot say who maintained the model. |
| Excel or Google Sheets | "What is the most complex model or report you maintained?" | Lookups, pivot tables, a clear purpose and who relied on it. | "Advanced Excel" meaning basic formulas and charts. |
| Python or R | "What did you use it for that you could not do in SQL or a spreadsheet?" | A task: cleaning messy files, a statistical test, automating a weekly report. | Only coursework, presented as daily work. |
| Any dashboard | "Which of your dashboards stopped being used, and why?" | An honest story about a metric nobody needed, and what they changed. | Every dashboard was a success. |
Stakeholder work: turning vague requests into answers
Most analyst requests arrive badly framed. The best analysts find the decision behind the request before writing a query. This is where non-technical screening is at its most useful, because you can judge it directly.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| Tell me about a request that turned out to be the wrong question. How did you find out? | "Sales asked for a list of inactive accounts. I asked what they would do with it; they wanted accounts likely to churn, which is a different analysis." | Always delivered exactly what was asked, with no clarifying questions. |
| Tell me about a finding that stakeholders did not want to hear. | The finding, how they checked it twice, how they presented it, and what happened. | Softened or dropped the finding without saying so. |
| Who were your main stakeholders, and how did you prioritize their requests? | Named teams and a method: a queue, a weekly review, business impact. | "Whoever asked first," with no view on priority. |
| How did you explain a result to someone non-technical? | One number or chart, what it means, what to do next, and the main caveat. | Describes the query in detail instead of the finding. |
| Tell me about an analysis that changed a decision. | The decision before and after, and roughly what it was worth. | Cannot name any decision their work influenced. |
The data quality story
Ask every analyst: "Tell me about a time the data itself was wrong. How did you notice, and what did you do?" Anyone who has worked with real company data has a story. The details show how careful they are and whether they fix causes or only symptoms. Listen for these, and probe the ones that are missing:
- How they noticed. A total that did not match another system, a sudden spike, duplicate IDs, a date field full of defaults. Probe: "What made you suspicious?"
- How big the problem was. Which reports or decisions had used the bad data. Probe: "Who had already seen the wrong numbers?"
- What they did first. Told the people relying on it, rather than quietly fixing it. Probe: "Who did you tell, and when?"
- The fix. A workaround in their query, and ideally a fix at the source with the team that owned it. Probe: "Is it still broken today?"
- What changed after. A test, an alert, a documented definition. Probe: "How would you catch it next time?"
Red flags: "the data was always clean," a fix applied silently to one report while others kept showing the wrong number, or blaming the data engineering team with no attempt to work with them.
Experiments and statistics claims
"A/B testing" and "statistical analysis" appear on many analyst resumes. For roles where experimentation matters, three questions separate those who ran tests from those who read the results.
- "Tell me about a test you designed. How did you decide how long it would run?" Strong: the metric, a sample size or run length decided before starting, and why. Red flag: stopped the test when the numbers looked good.
- "How did you decide the difference was real and not noise?" Strong: mentions significance or confidence intervals and a practical threshold for what mattered to the business. Red flag: "Version B's number was higher."
- "Tell me about a test that showed no difference, or the opposite of what people expected." Strong: reported it plainly and explains what the team learned. Red flag: every test they ran was a win.
Tool-name dropping and other red flags
| Pattern | What it looks like | How to check |
|---|---|---|
| Tool wall | SQL, Python, R, Tableau, Power BI, Looker, Snowflake, Spark, Airflow, dbt | "Which two did you use every week last year?" Ask about only those. |
| Course as job | Portfolio projects listed under experience | "Was that for an employer or for a course?" Course projects are fine; labeling matters. |
| Report runner as analyst | "Analyzed sales performance" meaning a weekly export | "What did you find that nobody asked for?" |
| Team dashboard as personal | "Built the company's KPI dashboard" | "What part did you build, and who else worked on it?" |
| Impact without a baseline | "Increased conversion 20%" | "From what to what, over what period, and how do you know it was your analysis?" |
| Machine learning inflation | "Predictive modeling" for a trend line in a spreadsheet | "What did the model predict, how did you test it, and did anyone use it?" |
| Rehearsed definitions | A textbook explanation of a join or a p-value, vague about own work | Ask for their own example: a table, a mistake, a number. |
Certificates, portfolios and technical tests
Certificates matter most for entry-level candidates. For experienced analysts, a described project beats any credential. Know what each common one involves so you can weigh it fairly.
| Credential | Issuer | What it involves | How to weigh it |
|---|---|---|---|
| Google Data Analytics Certificate | Google, delivered on Coursera | A self-paced online program covering spreadsheets, SQL, visualization and R; Google says no prior degree or experience is needed | Good evidence of foundations for entry-level roles; ask about the capstone project |
| Microsoft Certified: Power BI Data Analyst Associate (exam PL-300) | Microsoft | A proctored exam; the certification expires yearly and is renewed through a free online assessment | Confirms Power BI knowledge; still ask what they built at work |
| Salesforce Certified Tableau Data Analyst | Salesforce (Tableau) | An exam, with yearly maintenance to stay current, per the Trailhead credential page | Confirms Tableau knowledge; ask about a dashboard and its users |
Portfolios. Ask what question the project answered, where the data came from, what was hard about cleaning it, and what they would do with more time. A portfolio built on a common public dataset with a tutorial's exact charts is not a red flag for a beginner, but it is not evidence of independent analysis either.
Technical tests. Leave SQL exercises and take-home cases to the hiring team. Your job on the screen is to decide whether the candidate is worth their time, and to tell the candidate what the assessment involves so nobody drops out at that stage by surprise.
Logistics, knockout checklist and scorecard
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| The process includes a SQL exercise and a short case presentation. Are you comfortable with both? | Yes, or a clear concern you can raise early. | Declines any assessment for a client that requires one. |
| The role is hybrid, two days in the office. Does that work? | Yes or a clear limit. | Assumes remote. |
| What salary do you need to make a move? | A number or range. Ask expectations, not current pay; see salary expectation questions. | Only a figure from a salary site with no view on the role. |
| Are you legally authorized to work in the US, and will you now or in the future need visa sponsorship? | A direct answer to both. | None. Ask everyone the same two questions; do not ask about citizenship or country of origin. |
Avoid "When did you graduate?" for career changers and early-career analysts; it points at age. The EEOC notes that pre-employment inquiries pointing at protected characteristics can be used as evidence of discrimination. Ask about relevant work and dates of relevant roles instead.
Must-ask on every data analyst screen
- Which type of analyst work filled their week, compared with the role.
- The last query or analysis end to end, and a join or result that went wrong.
- How they check a number before sending it.
- A dashboard or report they built from scratch, and who used it.
- A request that turned out to be the wrong question.
- The data quality story.
- Assessment comfort, work setup, salary expectation, notice, other processes, work authorization.
Knock out, or flag to the hiring manager before submitting, if:
- SQL is a must-have and the candidate cannot describe a single query they wrote.
- Every answer stays at tool names, even after two requests for a specific example.
- The role expects recommendations to leaders and the candidate has never presented a finding.
- Course projects were presented as employment and the candidate does not correct it when asked.
| Area | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| SQL depth | Tool name only | Simple queries | Joins and checks, a real mistake fixed | Advanced patterns, validates against trusted numbers |
| BI and reporting | Viewed dashboards | Edited existing ones | Built from scratch with known users | Built the model and retired what nobody used |
| Stakeholder judgment | Delivers what is asked | Some clarifying questions | Reframed a request | Changed a decision and handled pushback |
| Data quality care | No story | Fixed in one report | Told users and fixed the cause | Added a check so it cannot recur |
| Logistics fit | Deal-breaker | Two open questions | One open question | All aligned |
Write the evidence in the candidate's words: "Revenue doubled after a join on addresses; 'I compared row counts before and after.'" A hiring manager reads that as SQL experience without needing a test to believe it. Interview Signal attaches quotes like that to each score from the call, and the candidate submittal template shows how to present them.
Questions people ask
How can a recruiter test SQL skills without knowing SQL?
Ask the candidate to describe the last query they wrote: what question it answered, which tables it joined, what went wrong with the result and how they checked it was right. People who write SQL every week answer with table names, row counts and a specific mistake. Leave any live coding test to the hiring team.
Is a Google Data Analytics certificate enough for a data analyst role?
It shows the candidate completed a structured beginner program covering spreadsheets, SQL and visualization, and Google states it needs no prior degree or experience. It is a reasonable signal for entry-level roles. For anything above that, ask about analysis they did on real business data.
What is the difference between a data analyst and a BI developer?
Titles overlap, but a data analyst usually answers business questions and presents findings, while a BI developer or reporting analyst builds and maintains the dashboards, data models and reports others use. Ask what the candidate spent most of their week producing: answers or reporting assets.
Should I ask a data analyst for a portfolio?
It helps for entry-level and career-change candidates who lack work examples they can share. For experienced analysts, most work is confidential, so ask them to describe a project instead of expecting files. Either way, ask what decision the analysis changed.