DataTalks.Club Podcast Wiki

Wiki

Hiring

Archive-backed patterns for hiring data scientists, analysts, data engineers, ML engineers, managers, and applied AI teams.

Related Wiki Pages

Job Search Career Transition Career Growth Data Product Management MLOps and DataOps

Hiring is how data and AI teams define roles, evaluate candidate evidence, and grow teams. It also covers sourcing, offers, and onboarding. In the DataTalks.Club podcast archive, hiring isn’t only a recruiter funnel. Guests treat it as role design and market negotiation. They also treat it as interview design, team building, and post-offer management.

Guests repeatedly connect hiring quality to clarity before screening. Recruiters and managers first define the work and team context. They also name the level, success criteria, and tradeoffs. Candidate-side advice belongs in Job Search, but the two topics stay connected because a clear hiring flow tells candidates what evidence to show.

Related wiki pages:

Core hiring interviews:

Common Definition

Across the archive, hiring means matching a real team need with the evidence a candidate can show. Alicja Notowska describes data-role hiring as work that starts before interviews. The hiring manager and recruiter define the need, write the job description, and choose interviewers. They also source candidates and screen profiles. Then they run technical and final rounds, make an offer, and onboard the person (Hiring Data Scientists and Analysts).

Luke Whipps gives the recruiter version from the candidate market. Recruiters define roles, map the market, create shortlists, and prepare candidates for interviews. They also gather feedback and negotiate offers (Land Data Scientist Roles).

Guests give the same role-design advice across several episodes: write for the work, not for a title. Katie Bauer says “data scientist” can mean product analytics or ML production work. It can also mean analyst work, pipelines, or data engineering. The meaning depends on the company and team stage (Hiring and Managing Data Science Teams in B2B SaaS).

Tereza Iofciu makes the same point from the job-description side. Companies create bad matches when they copy broad tech stacks or hide the team context. They create the same problem when they use a data-science title for work that’s Data Engineering or analytics (Data Science Jobs).

Before screening, hiring teams should state the problem and team. They should also name stakeholders and autonomy level. Technical depth, business judgment, and interview evidence should follow from those choices.

Nicolas Rassam applies that logic to Data Engineering. Junior, mid-level, and senior data engineers go through similar stages, but the signals change from task execution to design decisions. At the senior level, Rassam also looks for tradeoff reasoning and technical influence (Hiring Data Engineers in Europe).

Disagreements and Boundaries

Guests agree that role clarity matters, but they draw different boundaries around titles and technical depth. Team stage also changes the boundary. Katie Bauer treats “data scientist” as a broad category. It often tells you what someone isn’t doing rather than the specific work they’ll do (Hiring and Managing Data Science Teams in B2B SaaS).

Tereza Iofciu is more skeptical of vague titles. Candidates can discover too late that the job is actually infrastructure, dashboarding, or undefined first-data-hire work (Data Science Jobs). Hiring teams should preserve the broad label only when the job description explains the actual team, objectives, responsibilities, and data maturity.

The manager-versus-expert boundary is sharper. Barbara Sobkowiak argues that a data science manager needs broad technical literacy and stakeholder communication. The manager also needs team development, strategy, and business translation. A data science expert needs deep technical and domain skill in a specific problem area (Data Science Manager vs Expert).

For large organizations, she favors a manager plus a strong expert when the team needs both coordination and technical depth. For startups, she accepts that one senior generalist may need to cover more of the work (Data Science Manager vs Expert).

Guests also differ on how much structure a hiring process should add. Tereza Iofciu warns that early take-home tasks can push too much unpaid work onto candidates. The risk is higher before anyone has clarified the role (Data Science Jobs).

Alicja Notowska still treats technical screening and final rounds as normal parts of data hiring. She places them after job-spec work, recruiter screens, and hiring-manager alignment (Hiring Data Scientists and Analysts). The boundary isn’t “test or don’t test.” The better question is whether the test resembles the job and comes at a fair stage of hiring.

Role Definition and Job Descriptions

Hiring managers and recruiters should write job descriptions around problems, not long tool lists. Alicja Notowska explains that data professionals want to know which problems they’ll solve, which team they’ll join, and why the company needs the role. Perks matter less than the work (Hiring Data Scientists and Analysts). She also describes job-spec work as a negotiation. Recruiters use market data to show how each extra must-have narrows the candidate pool.

Tereza Iofciu gives the candidate-facing version of the same rule. A useful description names the team, work area, objectives, and responsibilities. It also says whether data engineering, analytics, and platform support already exist. A weak description lists every fashionable tool and leaves candidates guessing about the work (Data Science Jobs). This connects hiring directly to Data Teams: a company that can’t describe the surrounding team may not know what support the hire will have.

Inclusive wording is part of role definition, not decoration. Alicja Notowska discusses reviewing job-description language for gendered or discouraging phrasing (Hiring Data Scientists and Analysts). Tereza Iofciu flags “rockstar” and overloaded bullet lists as culture signals that can narrow the pool or suggest weak hiring discipline (Data Science Jobs).

Sourcing, Screening, and Market Reality

Data hiring often needs active sourcing because qualified people may not apply to posted roles. Alicja Notowska describes sourcing through LinkedIn and GitHub. She also mentions conferences, university alumni, and papers. She treats long-term talent pipelines as part of data recruiting (Hiring Data Scientists and Analysts). She also emphasizes recruiter and hiring-manager collaboration because recruiters need technical calibration from the team before they can judge profiles well.

Screening should look for concrete work, not only title matches. Nicolas Rassam says data engineering candidates can come from software engineering or BI. Some come from data science. Others have already built pipelines without calling themselves data engineers (Hiring Data Engineers in Europe).

For data scientist hiring, Luke Whipps makes a similar point. He matches CVs to industry, use case, and projects. He also looks for business impact and the role a company is trying to fill (Land Data Scientist Roles).

Market reality should change requirements before it lowers standards. Alicja Notowska’s example of a manager asking for several principal data scientists shows the practical problem. Scarce profiles can take months to hire, so the team must decide which requirements are true must-haves (Hiring Data Scientists and Analysts).

This is where CV Screening and Job Search mirror hiring. The team needs evidence of relevant work. Candidates need to make that evidence easy to find.

Interviews and Level-Specific Evaluation

Interview design should match the job and the level. Alicja Notowska describes a common data-role funnel of recruiter screen, technical screen, and final rounds (Hiring Data Scientists and Analysts).

Nicolas Rassam adds that data engineering processes may keep the same broad structure across levels, but the bar changes. Junior candidates show task execution, baseline SQL and Python, and business curiosity. Mid-level candidates show design decisions and project ownership. Senior candidates explain tradeoffs in time, cost, and performance. They also explain bottlenecks and technical direction (Hiring Data Engineers in Europe).

Manager hiring needs a different evidence set. Katie Bauer says data science manager interviews should test team-building judgment, stakeholder management, career development, and data craft. They should also test strategy, measurement, and tradeoffs (Hiring and Managing Data Science Teams in B2B SaaS).

Barbara Sobkowiak warns that many “manager” descriptions over-index on Python and Docker. They also over-index on Kubernetes, TensorFlow, or PyTorch. They understate communication and stakeholder work. They also understate strategy and team development (Data Science Manager vs Expert). That mistake hires an expert for a Leadership problem.

Specialist hiring should test the specialty only when the team truly needs it. Ivan Bilan’s NLP-team discussion separates NLP engineers from ML engineers and linguists. Teams need NLP specialists when task complexity justifies that depth. Language coverage can justify it too.

Annotation and feature engineering may also justify specialist hiring. Testing and production pipelines can push the same decision (Lead NLP Teams). For simpler language-product experiments, the team may start with existing libraries or APIs before hiring deep specialists. That connects the hiring decision to NLP and MLOps and DataOps.

Junior Hiring, Career Changers, and Build-vs-Buy

Junior hiring is a build-vs-buy decision. Katie Bauer argues that hiring juniors can strengthen an organization over time. The team still needs managers who can provide mentorship and skills training. Managers also need to support project-based learning and regular check-ins (Hiring and Managing Data Science Teams in B2B SaaS). Without that support, a junior hire may look like a bad hire when the real problem is weak onboarding or no growth path.

Career changers need practical evidence, so Alicja Notowska cites practical experience, portfolios, and online courses. She also values clear project explanations for people moving into data scientist or analyst roles (Hiring Data Scientists and Analysts).

Nicolas Rassam looks for internships and focused training for new data engineering candidates. He also looks for SQL, Python, and projects that explain the data and the problem (Hiring Data Engineers in Europe). These episodes connect hiring to Career Transition because the hiring team must evaluate transferable work rather than demand a perfect title history.

Junior context matters as much as junior talent. Tereza Iofciu warns that a first data scientist in an undefined startup may face chaos and missing data infrastructure. They may also have no peer learning environment (Data Science Jobs). That may suit some people, but many juniors need a clearer team, stable processes, and mentorship. Hiring a junior without those conditions moves the risk from recruiting into retention and Career Growth.

Hiring Managers, Experts, and Team Composition

A hiring team should decide whether it needs a manager, expert, or generalist before writing the role. Barbara Sobkowiak distinguishes managers from experts by the problems they solve. Managers build teams and translate business needs. They also manage stakeholders, set strategy, and guide development.

Experts bring deep algorithmic and technical knowledge to hard problems. They also bring domain knowledge (Data Science Manager vs Expert).

Katie Bauer adds an operating model for data teams. In B2B SaaS, teams may hire product analysts and analytics engineers. They may also hire marketing scientists and data scientists. Those people may sit in a matrix organization.

A data leader owns craft quality and career growth. Product, marketing, or engineering partners guide day-to-day priorities (Hiring and Managing Data Science Teams in B2B SaaS).

That structure means hiring can’t stop at technical skill. The team must also hire for domain context and maintainability. Documentation, peer review, and cross-functional communication matter too.

Mariano Semelman’s leadership episode shows why manager hiring also includes learning and translation. When he moved into managing a new advertising domain, he used a 30-60-90 plan and asked many questions. He also relied on transferable data science practices.

Those practices included problem framing, feature thinking and evaluation. They also included monitoring and KPI connection (Data Science Leadership). That makes manager hiring part of Leadership and Team Building, not only a seniority filter.

Offers, Onboarding, and Retention

Hiring continues after the offer. Alicja Notowska includes salary conversations, offer communication, contracts, and onboarding in recruiter work (Hiring Data Scientists and Analysts). Luke Whipps also treats offer negotiation and salary signals as part of the same process that starts with role definition (Land Data Scientist Roles).

Managers determine whether the hire can use their skills during onboarding. Katie Bauer advises new hires to communicate proactively and ask for help. She also recommends support channels such as regular check-ins and async question spaces (Hiring and Managing Data Science Teams in B2B SaaS). Mariano Semelman describes onboarding into a leadership role with a 30-60-90 plan and active listening. He also uses feedback and structured learning (Data Science Leadership).

Hiring teams should use retention signals when they design roles. Tereza Iofciu recommends looking at team structure and career ladders when judging a role. She also looks at junior presence, remote support, and internal mobility (Data Science Jobs). For employers, those aren’t only candidate questions. They’re design constraints for roles that people can accept, grow in, and keep.

Continue with these adjacent wiki pages: