Questions to Ask in a Data Analyst Interview
For candidates working out which questions to ask the interviewer in a data analyst interview, whether you get one turn at the end or a few minutes in every round. They are grouped as six conversations: the role itself, the people who request analysis and what they do with it, the data and the tools, how much of the work is reporting and how much is real analysis, the team and where the job leads, then pay and next steps. Under each is a note on what a good answer sounds like, what should give you pause, and what to ask next.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The Role
What does a typical day or week look like for a data analyst here?
Why ask it
Listen for particulars: the dashboard that refreshes on Monday, the pulls marketing asks for, the longer piece of work that keeps getting pushed back. An answer along the lines of 'no two days are the same' is your cue to ask what the analyst on the team was working on yesterday afternoon.
Which tools would I use most in an ordinary week: SQL, a BI tool, Python or R, spreadsheets?
Why ask it
The order they come out in tends to be the order of use. If you hoped for Python and the honest answer is spreadsheets and a dashboard tool, better to hear it now. Ask as well which of those choices would be yours to make.
Is this role closer to reporting, product analytics, or analytics engineering?
Why ask it
One job keeps a BI tool fed, one studies how customers behave, and one builds the tables everyone else queries, and all three get advertised as 'data analyst'. If the interviewer says it is all three, ask which took most of the last analyst's time, then set that beside the job you are hoping for.
Which business questions would I be expected to answer first?
Why ask it
Real questions, such as why spring sign-ups stopped coming back or which channel earns its budget, show that someone is waiting for the analysis. A list of dashboards to maintain is a description of a reporting job. That is a fair job, but you should know it is the one on offer.
What should I have taken over or built by the end of my first three months?
Why ask it
A useful answer is a thing with a name: the weekly sales dashboard taken over, the churn metric rebuilt, a recurring question answered for good. 'Learning the data' on its own deserves a follow-up about how long the last hire needed before working alone, which says a good deal about how well the tables are documented.
Why is the role open, and who has been answering these questions until now?
Why ask it
A backfill means there are queries, dashboards and habits to inherit, so ask whether the previous analyst left notes. If an engineer or a product manager has been pulling numbers on the side, you take over their definitions along with their workload. A first analyst hire should expect to build before there is anything to analyze.
Which metrics or dashboards would I own outright?
Why ask it
Owning a metric means you define it, fix it when it breaks and get the message when it moves. Ask whether anyone else can change the logic underneath. A role that owns nothing and only works a queue is harder to build a reputation in.
What tends to slow an analyst down here: the data, the tools, or waiting on other people?
Why ask it
Each answer describes a different job. Slow because of the data means cleanup, slow because of the tools means a warehouse or BI layer short of investment, and slow because of people means approvals and unclear requests. Ask what the last analyst did about it and whether it helped.
Which skill matters most here day to day: SQL, statistics, or explaining a result to someone who is not technical?
Why ask it
If the answer is explaining, expect to be judged on the meeting as much as the query. If it is statistics, ask which problem last needed it, since on plenty of teams the honest answer is SQL and patience. Whichever they pick is the one to show in the technical round.
Stakeholders
Which teams ask for the most analysis, and how does a request reach the analyst?
Why ask it
Listen for a front door: a request form, a weekly triage, one manager everything passes through. Without one, analysts get asked directly in chat and every request is marked urgent. Find out who on the team is allowed to say no, or not yet.
Can you tell me about a recent analysis that changed a decision?
Why ask it
If you only get one question, make it this one. A good answer has a decision, a person and a rough date in it. If the example is years old, or nobody can think of one, the numbers here mostly confirm what was already decided.
When two teams want something in the same week, who decides which comes first?
Why ask it
A manager who ranks the queue is protecting the analyst's time. An analyst left to referee between marketing and product spends goodwill with both before earning any.
Can the people who use the numbers pull them from a dashboard themselves, or does every question come to an analyst?
Why ask it
Where self-service works, the requests that reach an analyst are the ones a dashboard cannot answer, which is the interesting end of the job. Where it does not, expect a steady run of quick pulls. A good follow-up is which request comes in most often and why it has never been turned into a report.
What happens when the data says something a senior person does not want to hear?
Why ask it
Ask about the most recent time and who delivered the news. An analyst whose manager backed the finding in that meeting works somewhere different from one who was asked to rerun it with another date range. You would be the one carrying the next unwelcome result into the room.
Would I present my own findings, or hand them to someone else to present?
Why ask it
The questions that come back in that meeting are the best briefing an analyst gets on what to look at next, and you only hear them if you are there. Where a manager carries the work up, ask what came back from the last presentation: a list of follow-ups, a forwarded email, or nothing.
How comfortable with numbers are the people who would be asking me for analysis?
Why ask it
An audience that reads a chart unaided will challenge your method and spot a figure that looks off. One that does not needs a shorter write-up, a plain recommendation and more of your time in conversation. Neither should put you off, but it decides how much teaching comes with the work.
Would I sit inside one business team or in a central analytics group?
Why ask it
Sitting with marketing or operations, you learn one part of the business well and may go weeks without another analyst reading your SQL. In a central group the queue and the standards are shared, but requests reach you secondhand. Either way, ask how often analysts on different teams look at each other's work.
Do you know which dashboards and reports people actually open?
Why ask it
Many BI tools keep a record of views, so a team that looks can tell you. If nobody has checked, some of what you would maintain may have no reader at all. See whether an analyst here has ever been allowed to switch a report off.
When a request is vague, such as 'can you look into churn', is there time to find out what the person is trying to decide?
Why ask it
A request like that could turn into ten different queries, and the way to pick the right one is to ask what decision is waiting on it. A team that makes room for that conversation gets answers it can use. One that wants a number before the day is out gets a fast answer to the wrong question, and the analyst tends to take the blame.
Data and Tools
What does the data stack look like, from where the data lands to where people see it?
Why ask it
You are after three names: the warehouse, whatever transforms the data, and the BI layer on top. Look them up before the next round so your SQL practice matches their dialect. When two tools turn out to do the same job, ask which one leadership's numbers come from.
What data would I spend most of my time in: product events, sales records, marketing, finance?
Why ask it
Each is a different craft. Event data tends to be large and needs shaping before it says anything, CRM records are smaller and full of hand-typed fields, and finance data has to tie back to the books. Knowing which it is tells you what to practice and what kind of mess to expect.
How clean and well documented is the data I would be working with?
Why ask it
Expect an honest interviewer to wince a little. What you want is detail: which tables people trust, which one everybody works around, and whether there is a data dictionary that someone updated this year. Then ask what share of the week goes to cleanup before any analysis starts.
Where are the metric definitions kept, and who is allowed to change one?
Why ask it
A definition kept in a shared model or a maintained document means 'active customer' is counted one way. If the answer is a slide from last year, expect to be asked why your figure differs from the one in another team's deck. A good follow-up is which metric was most recently redefined and how people were told.
Who builds and maintains the tables analysts query: data engineers, or the analysts themselves?
Why ask it
Analysts who build their own tables, in scheduled SQL or a tool such as dbt, are doing analytics engineering whatever the title says. Some people want exactly that. If you do not, ask how a request for a new column gets made and how long the last one took.
How big is the data, and how long does a typical query take to come back?
Why ask it
A query that returns in seconds lets you explore, and one that takes twenty minutes makes every wrong turn expensive. Ask whether analysts work on the full tables or on samples and summaries, and whether query cost is something they are expected to watch.
Does someone review an analysis before it goes out, and are queries kept in version control?
Why ask it
A reviewer is cheap protection against a join that quietly duplicates rows or a filter that drops a month. Queries saved in a shared repository let you see how last quarter's number was built. With neither, each analyst's logic lives on their own laptop and leaves when they do.
When a dashboard number looks wrong, who notices first and who fixes it?
Why ask it
On many teams the first alarm is a message from whoever opened the dashboard on Monday morning, and the analyst spends the day tracing it back. Ask how often that happened last quarter, and whether fixing the source is the analyst's job or a ticket to engineering.
Does the team run experiments such as A/B tests, and who designs and reads them?
Why ask it
One for product or marketing analytics roles, and worth skipping for a pure reporting job. Ask who wrote up the last test and what the write-up covered: the sample, how long it ran, what was decided. If the analyst only pulls the numbers and someone else calls the result, the statistics in the posting may not get much use.
What is planned for the data platform this year: a migration, a new tool, a cleanup?
Why ask it
A move to a new warehouse or BI tool can mean months of rebuilding old reports before any new analysis gets done. Ask how much of the rebuild this role would carry and which requests get paused while it happens.
How is the team using AI tools for querying or analysis, and is there a rule about what data can go into them?
Why ask it
Some teams have an assistant built into the warehouse and some forbid pasting any company data into an outside tool. The rule is the employer's to set, so ask what it is there and who wrote it. Better to learn it now than to find in week one that a habit you rely on is not allowed.
The Work
Roughly what share of the job is recurring reporting, ad hoc requests and longer analysis?
Why ask it
The intended split and last month's are often different, so ask for last month's. Mostly recurring and ad hoc work makes the job a help desk for numbers, which can be a sound first job and a wearing third one. A claim of longer analysis is easy to test: ask what the last finished piece was.
How much of the recurring reporting is automated, and would I be free to automate the rest?
Why ask it
A report rebuilt by hand every week is time you could win back for better work. The good answer is permission plus the hours to do it. If the manual steps are defended because a reader likes the file that way, expect them to stay.
What was the last project an analyst here started on their own initiative?
Why ask it
A recent example with an outcome means curiosity is welcome and there is slack in the week for it. No example means all the work arrives as a request, and you should not count on choosing your own questions.
How long does a typical request take, from the ask to the answer?
Why ask it
Hours means quick pulls, and weeks means there is room to go deep. Ask about the longest one last quarter, and whether the deadline moved when the data turned out worse than anyone expected.
Does the work stop at describing what happened, or does it go on to forecasting, modeling or recommendations?
Why ask it
Describing what happened is the core of most analyst jobs and nothing to look down on. If you want to grow toward modeling, ask who does it today. Where a separate data science team exists, the predictive work may be handed across to them.
What does a finished piece of work look like here: a dashboard, a written memo, slides, a notebook?
Why ask it
The format shows how the work is read. Memos mean your reasoning gets read closely, slides mean you will be speaking to a room, and a dashboard means people help themselves and you may never hear what they concluded. If they can share one with the figures removed, ask to see it.
When an analysis ends in a recommendation, does anyone check later whether it was acted on?
Why ask it
A team that goes back and looks learns which work mattered and can say so at review time. Where findings go into a deck and nobody follows up, ask how an analyst here would know they had done something useful.
Which question does the business keep asking that nobody has answered well?
Why ask it
This is the open problem, and often where a new analyst gets noticed. If it has been open a long while, ask what stood in the way: missing data, no time, or no agreement on the definition. The first two can be fixed by a hire, and the third usually cannot.
Which dates drive the analysts' calendar here: month end, board meetings, planning season?
Why ask it
An analyst's deadlines usually come from someone else's meeting, so the dates are known well ahead. Ask how long the days run in the week before one, and in a week with nothing due. 'It is always busy' calls for one more question: what was dropped the last time two deadlines collided.
Team and Growth
Who would I report to: an analytics lead, or the head of the business team I support?
Why ask it
With an analytics lead, expect your queries to be read and your methods questioned, which is how you get better. Under a head of marketing or operations you are judged on whether the answer was useful and on time, and nobody checks how you got there. Ask which of the two the role is, and who else would see your work.
How many other analysts are there, and is anyone more senior than this role?
Why ask it
The number matters less than whether someone would read your work. One senior analyst who reviews queries can teach you more than five colleagues who each keep to their own dashboards. Being the most experienced analyst there is a different job, so ask what it means for the title and the level.
Do analysts here specialize by area, such as marketing, product or finance, or take whatever comes in?
Why ask it
A specialist becomes the person who knows one part of the business and its tables, and is hard to replace for it. A shared pool gives you range and less depth. If you have a preference, say so now, while the role is still being shaped.
What is the analytics team trying to get done this year, and which part would this role carry?
Why ask it
Expect a short list: a rebuilt revenue dashboard, a first attribution model, fewer one-off requests. Ask which item would be yours, and when the analysis starts if everything on it is infrastructure. A team with no list at all is working the queue, and so would you.
How do you judge whether an analyst is doing well?
Why ask it
Analyst output is hard to count, and the easy counts, tickets closed and dashboards built, reward volume. Better signs are decisions the work fed into, stakeholders who come back, and errors caught before they went out. Ask what went into the last review they wrote.
What did the best analyst you have worked with do that the others did not?
Why ask it
The answer is usually a habit and not a tool: asking what the decision is before writing a query, checking a number against a second source, saying 'I do not know yet' out loud. Take it as a description of what this manager will praise in your first review.
Where does this role lead: senior analyst, analytics engineering, data science, a product role?
Why ask it
The useful answer is a name: someone who went from this job to one of those, and the time it took them. Some employers treat data science as a separate hire with its own requirements, so ask what the step would take at this one.
How do analysts here keep learning: set-aside time, a budget, or people to learn from?
Why ask it
Time is the scarce part. Ask what the last analyst did with it: a course finished, a method tried on real data, an hour a week with someone senior. If nobody can remember, the allowance exists on paper and the queue took the hours.
How would I learn the business itself in the first weeks, and not only the tables?
Why ask it
An analyst who knows how the company earns its money asks better questions of the data. Good onboarding includes time with sales, support or operations and a walk through the key metrics with whoever owns them. Logins and a wiki mean you book those conversations yourself.
Where do the analysts work from, and are the teams they support in the same place?
Why ask it
Analysts pick up a great deal from overhearing what the business is worried about. If the stakeholders are in the office and you would not be, ask how a remote analyst gets to hear what is being decided before the request arrives. Office-day rules are each employer's own, so ask what this team does in practice.
What do you like about working with the data here, and what would you change?
Why ask it
One for a peer analyst more than a manager. Their wish is usually the daily irritant: a slow warehouse, a table nobody trusts, a stakeholder who rewrites the request. A peer with nothing to change is either new or being careful.
Pay and Next Steps
What is the salary range for this role, and where in it would someone with my experience land?
Why ask it
A question for the recruiter, best asked in the first call so nobody spends four rounds on a mismatch. Whether an employer has to publish a range varies with the job's location, so if the posting shows none, simply ask. Bonus and equity are set employer by employer, so ask what else makes up the package.
What level is this role, and how are the analyst levels defined here?
Why ask it
The same work is 'analyst' at one company and 'senior analyst' at another, which makes the title a poor guide. Ask which pay band the level maps to, and for one thing an analyst a level up is trusted with that this role is not.
Is there a SQL test or a take-home still to come, and can you tell me the format?
Why ask it
Asking is ordinary preparation, and live SQL on a shared screen calls for different practice from a take-home on a sample dataset. For a take-home, ask how long it is meant to take and whether they want the code, a write-up or both.
Would it help if I sent a sample of my work, such as a query, a dashboard or a short write-up?
Why ask it
Offer only work you are free to share: a personal project, something built on a public dataset, or a piece with the employer's figures and names removed. It gives a doubtful interviewer something concrete to judge, which helps most when your SQL or your industry experience is the open question.
How many rounds are left, and when should I expect to hear after the last one?
Why ask it
Get the rounds, the people in them and a date, and write the date down. Once it has passed, a short note to whoever arranged the interview is a reasonable thing to send.
How to ask these in a data analyst interview
Practical guidance for the conversation itself
Before the interview
Spread them across the rounds
Many processes run a recruiter call, a conversation with the hiring manager, a SQL or case round with an analyst, and sometimes a meeting with someone from the business. Pay and Next Steps belongs in the first call. Keep Data and Tools for the technical round, where the person across from you queries those tables every day. If a stakeholder interviews you, skip the stack and ask what they last requested from the analysts and what came back.
Weight the groups for where you are
You will get through a handful, not the whole list. For a first analyst job, lean on Team and Growth: who reviews your queries will shape you more than the name of the warehouse. If you are leaving a job that was all dashboards, lead with The Work and with the Stakeholders question about an analysis that changed a decision.
Bring one of their own numbers
A company's product, pricing page or public reports usually give away a metric it has to watch: subscribers, orders, occupancy, renewals. Build a question on it, such as 'I assume repeat orders is a number you track. Who owns its definition?' It shows you looked, and it gets a fuller answer than the same question asked in general.
Ask about the SQL round before it happens
Before a technical round, ask the recruiter which SQL dialect it uses, whether you will be able to run your queries, and whether looking up syntax is allowed. It is ordinary preparation, and it tells you whether to practice window functions on paper or in an editor.
In the room
Follow one request from start to finish
Ask the interviewer to walk through one recent request: who asked, how it arrived, where the data came from, what was sent back and what happened next. One story covers most of Stakeholders and The Work in two minutes. The steps the interviewer is unsure of are worth noting too.
Use the technical round
The person running a SQL exercise usually does this job. Once the exercise is over, ask what they queried this week and what was awkward about it. It is the best moment for Data and Tools, and it shows interest in the work beyond passing the test.
Frame the pointed ones as how you work
Asking whether anyone opens the dashboards, or what happens to a finding a director dislikes, can land as a judgment on the team. Tie it to your own practice: 'I like to check which reports still have readers. Would that be welcome here?' The same question then reads as an offer.
Reading the answers
What a reporting job sounds like
The work is described as dashboards to maintain and requests to turn around, nobody can recall an analysis that changed a decision, and success is counted in tickets. That can be a good place to get fluent in SQL and learn a business. It is a poor fit if you were hoping to spend your time on open questions.
What an analysis job sounds like
The interviewer names business questions instead of reports, can tell you who acted on the last piece of work, and describes analysts in the meeting where the decision was made. Ask for one example and listen for how recent it is.
Judge the direction of the data
No interviewer will describe tidy data, and an admission of mess is not a warning. What matters is which way it is heading. Can they name a table that was unreliable a year ago and is trusted now, and say who did the work?
A rough stack suits some careers and not others
A lone analyst role with spreadsheets and an aging warehouse can be a fast education for someone who has done the job elsewhere, and a hard start for a first job. A large, tidy team teaches good habits and may offer less range. Decide which of the two you need before you compare offers.
Mistakes to avoid
Sounding as if reporting is beneath you
Most analyst jobs include dashboards and recurring reports, and the person interviewing you may have built them. Ask about the split with curiosity, and say what you like about that side of the work, such as building a report nobody has to ask about twice, before you ask how much room there is for longer projects.
Judging the stack out loud
If the team runs on spreadsheets and an aging BI tool, saying what you would replace them with sounds like a verdict on the people in the room. Ask what they would change first and why it has not happened yet. You learn the constraints, and they hear curiosity.
Treating one rough answer as the verdict
An interviewer who admits that half the reports are still manual may be describing exactly the problem they are hiring you to fix. Ask what support comes with it, such as time, engineering help or a manager who will back the change, before you decide.
Leaving pay and level to the offer
Level and range are easier to raise with the recruiter near the start than after several rounds. How pay is set and what an employer has to disclose vary by employer and by place, so put the question to the recruiter directly.