Questions to Ask a Data Scientist
For students, career changers and analysts who have a coffee chat, a career panel or an informational interview with a working data scientist and want to know what the job is really like. The questions follow the conversation: the job itself, the data and tools, who uses the work, how people get in, what to learn first, and what comes next for the field and for you. The note under each says what the answer tends to show and what to do with it, and the guide covers how to choose the handful that fit in half an hour.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The job
What does a data scientist actually do at your company?
Why ask it
Two people with this title can have almost nothing in common: one answers questions for a marketing or product team with queries and charts, the other builds models that run inside the software. Ask this first and ask for an example, because the answer decides which of the later questions are worth your time.
What did last week look like for you, from Monday to Friday?
Why ask it
A named week brings out what a job description leaves off: the two days lost to a table that would not load, the meeting where the question changed. Compare the hours they spent alone with the data against the hours spent with other people, then ask whether last week was a normal one.
How much of your time goes to cleaning and preparing data, and how much to building models?
Why ask it
Many will say preparation takes the larger share, so pay attention to how they talk about it. Someone who calls the cleaning the place they find out what the data means is showing you the job can be liked as it is. If modeling is the only part that draws you, ask which teams or titles do more of it.
How is your job different from a data analyst's or a machine learning engineer's?
Why ask it
These titles are split differently at every employer, so take the answer as how it works where they are and not as a rule. What you are after is which title does the work you pictured, since that is the one to type into a job search.
What is the hardest part of your job, and is it the part you expected?
Why ask it
From outside, the usual guess is the math. See whether they name something else: getting access to the data, two teams counting the same thing differently, or a careful piece of work that nobody acted on. Then ask how often it comes up, since a hard day a month and a hard day a week are different jobs.
What are you working on right now, and who asked for it?
Why ask it
The second half shows where work comes from: a product manager, an executive, or the data scientist's own idea. If the description gets too technical to follow, ask what decision it feeds. That is a fair question for anyone in this job, and it usually gets a plainer answer.
Who do you work with most days: other data scientists, engineers, people on the business side?
Why ask it
A data scientist on a team of data scientists has someone to check the work and learn from. One placed alone with a product or marketing group sits closer to the decisions and further from review. Ask which setup they would choose for a first job, and why.
What is the biggest difference between data science in a course and data science at work?
Why ask it
Common answers are that nobody hands you a clean table, that the question itself arrives half-formed, and that a good share of the work is writing and presenting. Whatever they name is the piece that classes and tutorials leave out, so add it to what you practice.
Which project are you proudest of, and what changed because of it?
Why ask it
The pride often sits somewhere unglamorous: a forecast people stopped arguing with, or one report that retired three others. It shows what counts as a win in this work, which is seldom an accuracy score.
How do you know when an analysis is finished?
Why ask it
There is always one more cut of the data, so knowing when to stop is a real skill. The strongest answers tie it to the decision: more work would not change what the person does next. Borrow that rule for your own projects.
Data and tools
Which tools and languages do you use most weeks?
Why ask it
SQL and Python or R tend to come first, and the rest depends on the employer. Ask which one they open first in the morning, since that is the one to be fluent in. Most of the remaining list gets learned on the job.
How much of your day is SQL compared with Python or R?
Why ask it
Newcomers often drill modeling libraries and neglect queries. If they say half the day is SQL, move it up your list. If they say almost none, ask who prepares the tables for them, because that person's job exists too.
Where does your data come from, and what state is it in when it reaches you?
Why ask it
You will hear about duplicated records, fields that changed meaning partway through, and gaps nobody can explain. That is the ordinary condition of real data, and a good reason to practice on a raw, awkward dataset instead of a tidy one from a course.
How much math and statistics do you really use, and which parts?
Why ask it
The working list is usually shorter than a syllabus. Ask for the particular ideas, such as sampling, regression or reading an experiment, and note which they reach for weekly and which they have not touched since school. What you write down is a study plan.
Do most of your projects need machine learning, or do simpler methods usually do the job?
Why ask it
A frequent reply is that a plain regression, a careful comparison or one well-chosen chart settles the question. That is worth hearing from a practitioner if you have been putting off applying until you know deep learning.
How have AI coding assistants changed the way you work?
Why ask it
This moves fast, so the answer holds for now and for their employer, and some employers restrict these tools. The follow-up that lasts longer is what they still check by hand, because that is the judgment the tool has not replaced for them.
How do you check that a result is right before you show it to anyone?
Why ask it
These are habits you can copy the same evening: recounting rows after a join, trying a case where the answer is already known, asking a colleague to break it. Ask which single check has caught the most errors for them, and adopt that one first.
How much software engineering does your job ask for: version control, testing, code review?
Why ask it
It runs from none to nearly a developer's workload, so ask how it works on their team. If Git and code review are part of their day, learn the basics before you apply, because a take-home exercise or a first week may assume them. If they are not, your hours are better spent on queries and statistics.
Who uses it
Who uses what you build, and what do they do with it?
Why ask it
The user might be an executive reading one slide, a marketer pulling a list, or software calling a model all day with no person in the loop. Each makes a different job. If they are not sure anyone uses it, that is an honest picture of a common frustration.
How do you turn a vague request, such as 'look into why customers leave', into a question you can answer?
Why ask it
Framing is a skill of its own, and it rarely appears in coursework. Listen for what they ask back: what decision is waiting, what would change it, and by when. You can practice the same three on any project of your own before writing a line of code.
How much did you have to learn about the business before your work was useful?
Why ask it
Career changers should ask this one. If it took them a year to understand how claims are paid or how ads are priced, then what you already know about your own industry has a value you can name. Ask how they picked it up: sitting with the people who do the work, or reading the tables until they made sense.
What happens to a model after you finish building it?
Why ask it
Follow one model through: who wrote the code that runs it every night, who hears when it fails, and whether the person who built it still touches it. The more of that falls to the data scientist, the more engineering you would need to learn.
How do you present an uncertain result to someone who wants a yes or a no?
Why ask it
Listen for the actual sentences they use, such as a range in place of a single number or 'here is what would make me more sure'. Write one down. The same situation tends to come up in job interviews, and a course project rarely makes you practice it.
What do you do when the numbers say something people do not want to hear?
Why ask it
Good answers describe a method: checking the work twice, taking it to one person privately first, proposing a test in place of a verdict. Ask about the last time it happened and how the person on the other side took it.
Have you ever found a mistake in your work after people had already acted on it?
Why ask it
Ask kindly and let them choose how much to tell. Nearly anyone who has done this for a while has a story, and it teaches more about the job than a success does. The part to hold on to is how it was caught and what they check now because of it.
Have you ever been asked to do something with data that you were not comfortable with?
Why ask it
Privacy, fairness and pressure to reach a particular answer all come up in real work, and what is allowed differs by country, industry and employer. What you can take from their story is how they handled it and whether there was anyone to take it to. Skip this one on a public panel.
Getting in
How did you become a data scientist?
Why ask it
Routes differ: a statistics or computer science degree, a doctorate in another science, years as an analyst, a bootcamp after a first career. Ask whether they would get in the same way today, because the way in may not be what it was when they started.
Do I need a master's degree or a PhD to get hired?
Why ask it
It depends on the employer and the kind of role, so ask what the people on their own team hold and what the postings there require. Their answer covers the places they know and no others. Collect two or three such answers before committing to a degree for the sake of the job title.
Are bootcamps and online certificates taken seriously by the people who hire?
Why ask it
Best asked of someone who has sat on a hiring panel. Ask what the bootcamp graduates they have met could do and where they fell short. Employers differ on this, so get more than one opinion before you pay for anything.
Do analysts at your company get promoted into data scientist jobs, or do they have to leave to do it?
Why ask it
This tells you whether the analyst job you could get now leads anywhere at that kind of employer. If it happens there, ask what the last person to do it had built by the time they moved. If it does not, the analyst seat is a job of its own at that company, and the step up probably means changing employers.
What would you want to see in a portfolio project from someone with no experience?
Why ask it
The replies worth writing down are specific: data you gathered or cleaned yourself, a question somebody would care about, a short plain write-up. Then ask what makes them stop reading. The answer is often a tutorial dataset they have seen many times.
What were your own job interviews like: SQL questions, a take-home, a case study?
Why ask it
Ask when they last interviewed or sat on a panel, since a process from several years back may not be the one you would face. The detail to get is which round candidates most often stumble on, because that is where your practice hours should go.
How would my background in another field be seen on a data team?
Why ask it
Name your field when you ask. Knowledge of teaching, finance, biology or logistics can be the reason someone is hired, and a working data scientist can tell you which kinds of team would value yours. If they say it would be ignored, ask how they would describe it differently.
What to learn
If you were starting from scratch today, what would you learn first?
Why ask it
Let them answer without prompting, then ask for the order as well as the list, because a beginner's real problem is sequence. If machine learning comes third or fourth, that is worth knowing before you buy a course on it.
How much of being good at this job is writing and explaining, compared with the technical work?
Why ask it
Plenty of data scientists put it higher than a newcomer expects, because an analysis nobody understands changes nothing. Ask what they write most often: a one-page summary, a few slides, a message in a chat thread. Then practice that format on your next project, and not only the notebook.
Which skill do you use every day that no class taught you?
Why ask it
Version control, the quirks of a company's own tables, writing a query that finishes before lunch: replies tend to be practical. Whatever they name is the gap a new hire shows first, and most of these can be started in an afternoon.
What should a beginner stop spending time on?
Why ask it
People starting out are told what to add and almost never what to drop. It might be collecting certificates, chasing a last sliver of accuracy, or learning a fifth library. One clear 'do not bother' can hand you back weeks.
What mistake do you see beginners make with data again and again?
Why ask it
Expect something concrete: trusting a total without checking the row count, testing a model on data it has already seen, a chart with no point. Look through your last project for the same thing before you show it to anyone.
Which book, course or person taught you the most?
Why ask it
Ask for the one they finished and still go back to, not a list of ten. Recommendations age quickly here, so find out when they used it and what they would pick up now if it has dated.
How do you keep up without trying to read everything?
Why ask it
A good answer is small: one newsletter, a few colleagues, a conference every so often. Hearing that nobody follows it all is a relief in itself, and their routine is one you could copy this week.
Could I send you one of my projects afterward and hear what you noticed first?
Why ask it
Only ask if the conversation has gone well, and send a link later so they are not reading code across a table. Make it one project with a short write-up at the top. Whatever they mention first is likely where a stranger sorting applications would stop too.
Looking ahead
What do you do now that was not part of a data scientist's job when you started?
Why ask it
Ask this before you ask about the future. What moved during their own years in the work, whether a new task that appeared or an old one that got automated away, is better evidence than anyone's forecast.
Where do you think data science is heading, and what are you doing to be ready?
Why ask it
Treat the forecast as an opinion and the second half as evidence. What someone in the job is studying on their own time shows where they are placing a bet with something to lose.
Which parts of your job do you expect AI tools to take over, and which will stay with people?
Why ask it
A common split puts routine code with the tools, and deciding what to ask and whether to trust the result with the person. That is a guess and they will say so. It is still a reasonable guide to which skills are worth your next six months.
Which specialty would you point a newcomer toward: experimentation, forecasting, machine learning engineering, something else?
Why ask it
You get a map of the field along with an opinion on each corner of it. Ask which they would pick for the job market and which for interest alone. When the two differ, you have learned something about the trade-off you face.
How hard is it to land a first data science job right now, from what you have seen?
Why ask it
Keep them to what they have watched: how many people applied for the last junior opening on their team, and what the person who got it had done. The market differs by place, year and kind of employer, so one sober answer should change how you search, not whether you try.
What are the people you started out with doing now?
Why ask it
Their old classmates and first teammates are a truer sample than a career ladder on a slide. You may hear management, a senior technical role, product work, engineering, or a move out of data altogether. Ask which of those moves were chosen and which were forced.
Do you still enjoy it, and would you choose it again?
Why ask it
Keep it for near the end, when they have relaxed. A quick yes with a reason is encouraging. A pause followed by 'it depends what you want' deserves one follow-up: what would someone need to want?
Who else should I talk to, and what should I have asked that I did not?
Why ask it
Two requests, so pause between them. For the first, ask for someone whose job differs from theirs, such as an analyst or a machine learning engineer, so the next conversation is not a repeat of this one. The question they supply for the second is usually one an outsider could not have known to ask.
How to get the most from a conversation with a data scientist
Practical guidance for the conversation itself
Before the conversation
Find out which kind of data scientist they are
Read their profile or the event bio first and look at what they list: experiments and dashboards, models inside a product, or published research. The same title sits on all three, and the questions that suit each are different. For someone on an analytics team, lean on The job and Who uses it. For someone who builds models for a product, the questions about software engineering and what happens to a model afterward will get the fullest answers. If you cannot tell, open with the first question on the list and let the reply steer the rest.
Choose a handful and put them in order
A coffee chat of twenty to thirty minutes holds six to eight questions once follow-ups are counted, so most of this page will go unasked. Take one or two from each group, put first the one that could change your plan, and keep the rest as spares. The groups run in the order a conversation usually goes, so you can move down the page without jumping around.
Say where you are starting from
Open with two sentences about yourself: a second-year statistics student, an analyst who lives in spreadsheets and some SQL, a teacher thinking about a change. Advice gets specific once they know who is asking. Without it you will hear the general talk they give everyone.
At a career panel, ask what the whole room can use
With a microphone and one turn, pick a question the panelists will answer differently, such as how their time splits between cleaning data and modeling, or what they would learn first now. Keep the questions about your own background and your own projects for the few minutes afterward, one to one.
During the conversation
Ask for last week, not the job in general
General questions get general answers. 'What did you do on Tuesday?' or 'What was the last thing you presented?' brings out the real tasks, the tools that were open and the people in the room. Nearly every question under The job and Data and tools improves when you tie it to a recent, particular piece of work.
Ask for the plain version when you get lost
Practitioners slip into method names without noticing. You do not need to follow all of it. 'What decision was that for?' and 'How would you explain that to the person who asked?' bring the answer back to ground you can stand on, and they are questions a data scientist hears at work every day.
Stay away from confidential detail
Their employer's data, customers and unreleased work are not theirs to share, and what they can say differs from one company to the next. Ask about the shape of a project and not its figures. If they hesitate, move on without pressing.
Keep to the time you asked for
Check the clock a few minutes before the end and say so. That leaves room for the last two questions under Looking ahead: whether they would choose the work again, and who you should talk to next. The second is the one that turns a single conversation into another.
Using what you hear
One person is one employer
How the title is defined, which degrees the team holds, the tools and the share of modeling all vary by company, industry and country. Before you choose a degree or a bootcamp on the strength of one chat, talk to two or three people at different kinds of employer and see what stays the same across them.
Check how old the advice is
Someone who was hired several years ago is describing the entry route as it was then. Ask when they last looked for a job or interviewed a junior candidate, and give more weight to what they have seen recently than to how it went for them.
Turn the notes into three lines
The same day, write down one thing to start learning, one thing to stop spending time on, and one person or resource to follow up. A page of notes with no next step tends to stay a page of notes.
Write back when you have done something
Send a short thank-you that names one thing you will act on. A few weeks later, write again to say you did it, with a link if there is a project to show. People tend to answer that kind of note, and it is a natural moment for them to suggest someone else to meet.
Mistakes to avoid
Asking for a job or a referral
You asked for information, and switching to a request for a referral puts them in an awkward spot with someone they met half an hour ago. If they offer to pass your name along, accept. Otherwise ask who else you should talk to and leave it there.
Asking what a search would answer
'What is data science?' and 'Is Python important?' use up minutes on things you could read tonight. Spend the time on what only this person knows: their week, their employer's version of the job, what they have watched happen to junior hires.
Trying to sound advanced
Dropping model names to impress someone who uses them daily rarely works, and it pulls the talk toward technique and away from what the job is like. Plain beginner questions, asked with some preparation behind them, get the more useful answers.
Asking what they earn
Their own salary is not a fair question. If pay matters to your decision, ask what range a newcomer might expect in their area and how it tends to move, and hear it as one person's impression. Pay differs by country, city, industry and employer, so compare it with what current postings near you list.