Data Analyst
Frequently asked questions about hiring for the Data Analyst role, plus the mistakes that most often derail it.
Common hiring mistakes for this role
Confusing Data Scientist and Data Analyst
A Data Scientist builds predictive models, works with machine learning, often in Python, and invests in production models. A Data Analyst answers business questions, mainly in SQL and a BI tool, and supports decisions. At an SMB with under 50 people you almost always need an analyst, not a scientist: the most expensive problems are unanswered business questions, not missing ML models. Hiring a scientist in a reporting context leads to a resignation in 6 to 12 months (under-challenged, frustrated by the missing model infrastructure). Clarify the need explicitly before you write the ad.
Undervaluing business judgment
Many ads and interviews focus on tools (SQL, Python, Tableau) and methods (funnel, cohorts, statistics). These are necessary but not sufficient. At an SMB, business judgment decides the role's impact: can the analyst recognize which question is worth answering, or do they only deliver what is ordered? Assess business judgment explicitly (Describe a request you reframed), not only tool mastery. Profiles with a pure quant or statistics education are often weaker here than profiles with a mixed background (economics plus data, bootcamp plus operational experience).
Setting ML or modeling ambitions instead of the reporting reality
Many SMBs write predictive modeling, machine learning and similar terms in the ad, even though the real work is 80 % SQL analyses, dashboard maintenance and stakeholder communication. This filters in ambitious profiles who quickly become frustrated in practice, and deters pragmatic profiles who could deliver exactly what you need. Write honestly: 70 % business analyses and reporting, 20 % building and maintaining dashboards, 10 % exploratory analyses or modeling. Profiles who seek this mix are rarer and fit better.
Underestimating cross-functional communication
A Data Analyst at an SMB talks daily to sales, marketing, product, management and occasionally to customers. Whoever is technically strong but weak in cross-functional communication produces friction: misunderstood requests, dashboards no one uses, conflicts with business functions. Assess communication explicitly in the interview (the stakeholder simulation in stage 4 of the playbook, situational questions tied to business functions, explaining a technical finding in everyday language). Profiles with a pure tech socialization and no business experience fail here most often.
Treating data as a pure tech function
Some companies embed the Data Analyst role in the engineering team and treat it like a tech function: tickets, sprint planning, code reviews. That misses the core of the role, which works at the intersection of business and data. The analyst needs direct access to the business functions (1:1s with the sales lead, product lead, management), not just to engineering. At an SMB the role works best as a business function with technical depth, not as a tech function with business exposure. The organizational reporting line (to management, the CFO or the COO) often makes the difference between impact and friction.