Ian Klosowicz
The most useful thing an informational interview does is tell you things no job posting will. Which SQL dialect the team actually runs. Whether analysts own their dashboards or just maintain someone else's. How much of the job is cleaning data versus presenting insights. You only get that information if you ask the right questions, and most people don't.
Most career advice treats informational interviews as networking with extra steps. For data analyst job seekers, they're more useful than that.
Data analyst roles vary more than almost any other entry-level position. A "data analyst" at a 20-person startup might write raw SQL against a production database, build every dashboard from scratch, and present to executives weekly. A "data analyst" at a Fortune 500 might spend 80% of their time in Excel maintaining reports someone built 4 years ago.
Job postings don't tell you which one you're walking into. A 30-minute conversation with someone who works there does.
The other thing informational interviews do: they put your name in front of someone before your resume lands. I've watched this play out with people who've gone through Analyst Hive and LinkedIn. The candidates who had conversations with people inside companies before applying moved faster through hiring pipelines than people who applied cold with identical portfolios. The mechanism isn't complicated, someone who recognizes your name reads your resume differently than someone seeing it for the first time.
Keep the ask small.
The message that works: "Hi [Name], I'm targeting entry-level data analyst roles and I came across your profile while researching [Company/industry]. I had 2 or 3 questions I think you'd be well-positioned to answer, no call needed if you'd prefer to respond in writing, happy either way."
That's it. You're offering them an easy out (written responses), you're specific about who you are and why you're reaching out, and you're not asking for a job review or a referral.
If someone agrees to a call, 20 to 25 minutes is the right ask. Frame it as a learning conversation, not a job inquiry. Arrive with your questions written down. Don't wing it.
One thing that raises response rates: engage with their LinkedIn content first. If they post about their work in data, drop a genuine comment. Message them a few days later. Name recognition helps.
This is the most important category. The goal is to understand what the job actually looks like versus what it says on paper.
"What does a typical week look like for you, what are you actually spending your time on?"
This question cuts through job description language fast. If someone says "a lot of it is cleaning data and fixing broken reports," that's useful. If they say "I spend most of my time in SQL building pipelines and then presenting the output to the product team," that's a different job entirely.
"What's the ratio of ad hoc requests to structured project work?"
Ad hoc-heavy roles mean constant context switching and a lot of one-off queries. Project-heavy roles mean deeper analytical work but sometimes slower feedback loops. Neither is inherently better, but knowing which you're walking into matters.
"How much of your work ends up being used by decision makers?"
This one tells you how much your output actually matters in the org. Some analyst roles produce reports that get emailed to a list and never discussed. Others produce dashboards that executives reference in every weekly meeting. The answer shapes how satisfying the job is.
"What's the hardest part of the role that surprised you?"
People answer this honestly more often than you'd expect. "The stakeholders keep changing their mind about what they want" is a culture signal. "The data quality is really inconsistent" is a technical signal. Both are worth knowing before you take the job.
Job postings list tools. Informational interviews tell you which ones you'll actually use on day one.
"What does your data stack look like, what are you actually querying against?"
This is where you find out if it's Snowflake, Redshift, BigQuery, SQL Server, or a legacy Oracle setup. Knowing the dialect matters if you're trying to target your portfolio work. Building Snowflake-flavored SQL projects when the company runs everything in SQL Server is a small misalignment worth correcting.
"What BI tool does the team primarily use, and how deep does the analyst role go into it?"
Some teams use Power BI but only for pre-built dashboards. Others expect analysts to build and maintain the entire data model behind their reports. The difference is significant for both the skill set you need and how interesting the work is.
"Is there any Python or R in the workflow, or is it primarily SQL and a BI tool?"
A lot of data analyst roles advertise Python but never use it. Some use it daily for cleaning and automation. The answer tells you where to focus your prep and what your first 90 days will actually look like.
"How does data get from source systems into the tool you're working in? Does the analyst team own any of that pipeline?"
This gets at whether the team has a dedicated data engineering function or whether analysts are expected to handle their own data prep. Working in data engineering myself, Snowflake, Coalesce, dbt-style transformations, I can tell you these questions have very different answers depending on the maturity of the data team. Knowing the answer before you join saves surprises.
If the person you're talking to is relatively early in their career, this category is especially useful.
"How did you get your first data analyst role, and what do you think made the difference?"
This is one of the most direct questions you can ask, and people who broke in recently are usually willing to answer it honestly. The answers are rarely "I had the best resume." More often: "I knew someone," "I had a project that was relevant to what they were building," "I came in through a contract role."
"What would you look for in a resume or portfolio if you were hiring for your team today?"
This reframes the question as something they're evaluating rather than something about you personally. It usually gets more honest answers. If they say "I want to see actual SQL, not just 'proficient in SQL,'" that's actionable.
"Is a degree still a hard requirement at your company, or has that changed?"
The answers vary more than you'd think. Some teams still run every resume through an ATS filter that screens for a degree. Others have explicitly moved away from it. Knowing which category a company falls into before you spend energy targeting them is worth the ask.
I don't have a relevant degree. I got into data analytics by self-teaching, building projects, and being able to demonstrate the skills in a conversation and in a portfolio. The informational interview was one of the ways I learned which companies would actually evaluate my work versus which ones would screen me out before a human ever saw my resume.
The last category is about fit, both for your career and for your day-to-day sanity.
"How big is the analytics team, and how is it structured?"
A team of 2 analysts means you'll be doing everything and learning fast. A team of 30 with specialization means your scope might be narrow for a while. Neither is wrong, but they're different environments, and knowing which you're walking into matters.
"Is there a path for analysts to grow into senior or lead roles, or do people typically move on to do that?"
This is a more diplomatic way of asking "is there a ceiling here?" Some companies promote from within consistently. Others treat the analyst role as a stepping stone they expect people to outgrow. The answer shapes your decision differently depending on what you want.
"What does the relationship between analytics and engineering look like here?"
In mature data orgs, analysts and engineers work closely. In less mature ones, analysts often build their own pipelines or wait a long time for data that engineering controls. The answer tells you something about how much influence you'll have and how much ownership you'll have over your own work.
Write it down right after the call. Not tomorrow. Right after.
The most useful thing to capture isn't a transcript, it's your read on:
Send a thank you message the same day. 3 to 4 sentences. Mention 1 specific thing from the conversation. Say you'll keep them posted on where you land.
Then actually do it. When you get an offer, send them a note. Recruiters and practitioners remember candidates who close the loop. It's rare enough to stand out.
If you're working through this process and want a structured approach to the whole job search, outreach, portfolio, applications, and interviews, Analyst Hive covers all of it as a day-by-day program on Skool.
How do I find data analysts to have informational interviews with?
LinkedIn is the primary source. Search for "data analyst" filtered by your target industry or city, then look for people who post publicly or have detailed profiles. Second-degree connections are easier to reach than cold outreach. Alumni networks from your school, if you have one, also work well since the shared connection lowers friction significantly.
What if I freeze up and can't think of what to say?
Have 5 to 7 questions written down before the call. You won't use all of them, conversations drift, but having a list means you're never staring at silence. The questions in this post are a usable starting set. Pick the ones most relevant to what you're trying to learn and print them out or have them open on a second screen.
Should I record the call?
Only if you ask and they say yes. A better approach: take brief notes during the call, then spend 10 minutes writing a more complete summary immediately after. You'll retain more than you think, and you won't have to listen back to a 25-minute recording to find the 3 useful things they said.
Is it okay to ask about salary in an informational interview?
Keep it general. "What's the typical comp range for an entry-level analyst at a company like yours?" is fine. Asking for their specific salary is not. If the conversation is warm and they're being candid, they'll often volunteer a range unprompted when you ask the general version.
How many informational interviews should I try to do?
10 to 15 over the course of your job search is a solid target. More than that and the law of diminishing returns kicks in, you start hearing the same things. Fewer than 5 and you probably don't have a complete enough picture of the market to make good decisions about where to focus your applications.
What if the person I talk to is at a company I don't want to work for?
Still useful. The tools, the career path patterns, the day-to-day structure, most of that information travels across companies. And they know people at other companies. Ending the call with "is there anyone else you'd recommend I talk to?" is one of the most useful questions you can ask in any informational interview.
If you're in the middle of a data analyst job search and want a structured system for the whole process, Analyst Hive is a day-by-day program. It covers portfolio projects, LinkedIn, applications, recruiter outreach, and interview prep in sequence. Join Analyst Hive.
