Overview

Here's the hiring trap: You post a job for an "AI Engineer." You get resumes from people with PhDs in ML and 5 papers published at NeurIPS. You hire one. Three months later they're struggling to ship an actual product.

The inverse trap: you hire someone who's good at shipping product but has never done ML. They're swimming against the current for six months.

Good AI hiring is about balance. You need people who understand AI deeply and people who care about shipping. Those aren't always the same people.

This is about building a team that actually delivers.

The Three AI Hiring Profiles You Need

Profile 1: The ML Practitioner

Strong fundamentals in machine learning. Understands models, training, inference, evaluation. Has shipped real ML systems before.

What to look for:
- Clear example of a model they trained and shipped
- Can explain their approach to evaluation (not just accuracy, but business metrics)
- Understands trade-offs (accuracy vs. latency, cost vs. quality)
- Can write clean production code (bonus: some DevOps experience)
- References who can attest they shipped something real

Red flags:**
- Lots of academic papers but no shipped products
- Can't explain why they made specific architectural choices
- Focuses only on model accuracy, not business impact
- Can't debug production systems ("that's ops work")

Compensation:** $180-280k + equity for someone with 5+ years proven shipping experience

How many: Hire 1 for every 3-4 engineers. They set technical direction. They help others level up.

Profile 2: The Platform Engineer

Systems thinking. Infrastructure. Can build the platforms that let ML practitioners run experiments safely and ship models reliably. Often has ML infrastructure or platform engineering background.

What to look for:
- Experience building ML infrastructure (feature stores, model serving, evaluation frameworks)
- Strong DevOps background applied to ML (not just generic DevOps)
- Can articulate the problems with current tools
- Cares about operational stability, not just features
- Understands monitoring and observability for ML systems

Red flags:
- Treats ML like regular software (it's different)
- Can't explain why model serving is hard
- Proposes solutions before understanding the problem

Compensation: $170-250k + equity for 5+ years in ML infrastructure

How many: Hire 1 for every 6-8 engineers. They enable the whole team to move fast.

Profile 3: The Product-Focused Engineer

Great software engineer who cares about AI but isn't specialized in it. Can pick up ML concepts, can build integration layers, can ship features that use AI.

What to look for:
- Strong software engineering fundamentals
- Track record of shipping products (web, mobile, whatever)
- Curiosity about new domains (shows they can learn ML)
- Ability to work with ML practitioners without being intimidated
- Comfortable with ambiguity (ML projects are ambiguous)

Red flags:**
- Dismissive of ML ("it's just calling an API")
- Can't debug across systems (needs everything handed to them)
- Wants perfect specifications before building

Compensation: $140-220k + equity for 5+ years solid engineering

How many: Hire 2-4 of these for every ML practitioner. They build the actual product.

The Hiring Principle: You need all three profiles. A team of just ML practitioners will over-engineer. A team of just product engineers will struggle with AI. The mix matters.

Case Study: Seed-Stage Startup Hires AI Team

A fintech startup with 6 engineers wanted to add AI to their product. They hired one ML practitioner (cost: $200k all-in), two product engineers (cost: $320k combined), and contracted 20% time with a platform engineer for infrastructure (cost: $30k/quarter). Total year 1 spend: $320k on salary, $120k on contractor.

Outcome: Within 6 months, they shipped a credit decisioning model (98% accuracy, passed regulatory audit). Within 12 months, they added fraud detection (AUC 0.94, prevented $2M+ in fraud). The team shipping speed increased because the ML practitioner set direction, the platform engineer kept infrastructure simple and reliable, and the product engineers could focus on features instead of ML infrastructure.

The ML practitioner had shipped two previous models in production. The platform engineer had built ML infrastructure at a larger company. The product engineers were solid generalists who wanted to learn ML. This mix worked.

Deep Case Study: Series A Company Rebuilds AI Team After Initial Failure

Context: A Series A company ($5M ARR) started with 10 engineers. They were founded by two non-technical co-founders who hired a VP Engineering from a big tech company. The VP immediately wanted to "do AI right." They hired 3 ML researchers (PhDs, published papers, backgrounds in deep learning) and 1 "AI platform engineer" (actually a DevOps person with no ML experience).

Months 1-3: Honeymoon**

The ML researchers designed a beautiful architecture. State-of-the-art models. They talked about building a world-class ML platform. The co-founders were excited. The team felt like they were doing serious stuff.

Months 4-6: Warning Signs**

Zero features shipped. The researchers were focused on model accuracy (trying to get from 88% to 94% AUC). The "platform engineer" was lost. He knew Docker but not model serving. The original 10 engineers didn't understand the AI team's roadmap. AI team didn't understand the product constraints.

The CEO asked: "When do users get this feature?" Answer: "We're still optimizing the model." The CEO's frustration grew.

Months 7-9: Crisis**

One researcher left (burned out on unshipped work). Another two said they'd work on "foundational ML infrastructure" indefinitely, no timeline. The platform engineer quit after 6 months ("I don't know what I'm doing"). Total spend: $500k. Result: zero shipped features.

The VP Engineering realized the mistake: hiring for expertise (PhDs) instead of for shipping (practitioners with production experience). The mix was catastrophic.

Months 10-18: Rebuilding**

They fired the VP Engineering and hired a new technical leader with ML practitioner experience (had shipped 4 models at previous company). This person immediately:
- Cut the AI roadmap to ONE feature: customer churn prediction. Simple problem. Clear business value (high churn = lost revenue).
- Hired two product engineers who wanted to learn ML (junior, cheaper, but shipped-oriented)
- Kept one of the original researchers (the most pragmatic of the three) but reoriented her to shipping vs. research
- Hired an ML infrastructure contractor 10 hours/week instead of trying to make the DevOps engineer do ML

In month 12 of the project (month 4 of the rebuilding), they shipped churn prediction. AUC 0.82 (not state-of-the-art, but business-useful). It prevented $300k in churn. The team felt momentum.

Month 18: Shipped a second feature (customer lifetime value prediction). This time, 8 weeks from idea to production (vs. 6 months the first time).

The Numbers:**

Total spend (months 1-18): $500k wasted + $200k on rebuilding + infrastructure = $700k to ship two models.

If they'd hired right initially: $200k ML practitioner + $300k two product engineers + $80k contractor infrastructure = $580k. They'd have shipped 4-5 models by month 12.

The hiring mistake cost them $120k+ and 6 months of lost momentum.

What they learned:**

• Researchers optimize for accuracy. Practitioners optimize for shipped work.
  - Hiring for prestigious credentials (PhDs) led to over-engineering. Hiring for shipped work led to pragmatism.
  - A mix of specialist (ML practitioner) + generalists (product engineers) is faster than specialists-only.
  - The leadership hiring decision (choosing researchers vs. practitioners) cascaded through everything. One wrong hire at the top derailed 6 engineers.

The Interview Process That Actually Works

Round 1: Screen (30 min)
Goal: Filter for basic competency and communication.
- Have them explain a model they built. (Not the paper. The actual shipped thing.)
- Why did you choose that approach?
- What surprised you when it went to production?
- How would you build something similar today?

If they can't articulate a shipped project, don't proceed.

Round 2: Technical Deep Dive (90 min)**
Goal: Understand depth of knowledge and problem-solving.
- Whiteboard or take-home: "Build a system that does X." Real problem your team faces.
- They don't need to solve it perfectly. You're looking for: problem decomposition, identifying trade-offs, asking clarifying questions, considering monitoring and failure modes.
- Ask follow-ups: "Your solution uses Y. What if requirement changed to Z?"

Round 3: Team Fit (60 min)**
Goal: Understand how they work with others.
- Have them talk to 2-3 people doing adjacent work
- Ask them: How would you work with a junior engineer? With a product manager? With someone who disagrees with you?
- Ask them: Tell us about a time you shipped something that failed. What did you learn?

Round 4: The Talk-Through (45 min)**
Goal: Understand their judgment and communication.
- Have them present a problem they solved to a mixed audience (engineer, product, manager)
- Can they explain technical concepts without losing the business context?
- Do they listen to questions or do they lecture?

Pay attention to: Do they seem like someone you'd want in the room when decisions are made?

Additional Failure Scenarios

Scenario 1: Hiring Only Practitioners****

A startup hired 3 ML practitioners (all seniors, all expensive). They had no platform engineer. Each engineer built their own data pipelines, model serving setup, monitoring. Total: three different architectures, three sets of tech debt, massive friction when sharing models.

Year 1: $600k in practitioner salary, zero reusable platform, shipping took twice as long as it should have because engineers kept duplicating infrastructure work.

Prevention: One platform engineer per 3-4 practitioners. That person doesn't build models but builds the systems practitioners build on top of. Huge leverage.

Scenario 2: Hiring Generalists Without Specialists**

A company hired 6 solid product engineers with "interest in ML." No specialists. They tried to build a recommendation system. Months 1-3: they're reading papers. Months 4-6: they built something but it's suboptimal (over-engineered, under-performing). They eventually shipped something mediocre that didn't deliver customer value.

Prevention: For non-trivial AI, hire at least one specialist. They set direction. They prevent learning-on-the-job failures. Generalists can then execute better because the path is clearer.

Scenario 3: Hiring for Prestige Instead of Shipping**

See the deep case study above. The Series A company hired researchers instead of practitioners and wasted 6 months. This happens often.

Interview for Shipped Work, Not Credentials: A candidate with papers but no shipped products will struggle in your engineering org. Look for people who've shipped real systems to production, dealt with real constraints, and debugged real failures. That experience is worth more than any degree.

What Not to Do When Hiring AI Talent

Don't hire for degrees.** PhD is nice. Shipping product is better. Don't weight credentials too heavily.

Don't use coding interviews from LeetCode.** ML people don't need to reverse binary trees. They need to debug production systems. Use real problems from your domain.

Don't hire for model accuracy.** Great model design is one skill. Shipping product that works at 85% accuracy instead of 92% and delighting users is another. The latter matters more.

Don't hire generalists and hope they specialize.** Sure, a great engineer can learn ML. But they're learning on your dime while other companies are shipping. For critical roles, hire specialists.

Don't overlook engineers from non-ML backgrounds.** Some of the best platform engineers came from DevOps. Some of the best ML practitioners came from physics or finance, not CS. Look at what they've built, not what school they went to.

Don't hire only PhDs.** You need people at different levels. Junior people bring energy and fresh ideas. Seniors bring judgment. Mix them.

The Sourcing Challenge

Good AI talent is scarce. How do you find them?

• Engineering blogs and GitHub: Look for people writing about ML infrastructure problems. They're rare. When you find them, contact them directly.
  - ML research communities (but be selective): Look for practitioners, not just researchers. NeurIPS is good for finding active researchers. Cheaper than recruiting firms.
  - Your own customers and partners: Sometimes the best people are already integrated with you. Hire them away from vendors or customers if you can.
  - Bootcamp graduates (carefully): Some bootcamps produce solid engineers. But verify the quality. One bad hire costs a lot.
  - Your existing team's network:** Great people know great people. Referrals often work best. Offer bonuses for quality hires.

Don't rely only on recruiting firms. They're expensive and often don't understand AI well enough to screen properly.

What to Do Monday Morning

Step 1: Define your three hiring profiles.** ML practitioner, platform engineer, product engineer. Write detailed specs for each.

Step 2: Map your current team.** Who are you? Where are gaps?

Step 3: Prioritize hiring.** Which gap matters most? Start there.

Step 4: Build your interview process.** Screen, technical, team fit, talk-through. Make it consistent.

Step 5: Start sourcing.** Recruiting firms, direct outreach, referrals, bootcamps. Diversify.

FAQ: Hiring Questions

Q: Should we hire contractors instead of full-time?**

A: Contractors are good for specific projects. They're not good for building team culture or long-term systems thinking. You need some full-time people who care about the long term.

Q: How do we hire when we don't have existing AI expertise to evaluate candidates?**

A: Hire a consultant for the interview process. Or, hire a strong generalist engineer first who can then help you hire specialists. Or, work with a recruiting firm that specializes in ML (and vet their judgment carefully).

Q: Should we grow the team or hire specialists?**

A: Both. But specialize slowly. Get 3-4 generalists established. Then add specialists in areas where you're hitting hard constraints.

Q: What if we find someone amazing who doesn't fit one of the three profiles?

A: Hire them. The three profiles are guidelines, not dogma. Someone who combines strengths (great practitioner + platform mindset) is worth more than the sum of parts. Flexibility matters.

Q: How do we retain AI talent in a hyper-competitive market? (The real problem.)

A: Pay well (but you can't out-pay Google). Give autonomy and impact. Let them ship real things. Share equity meaningfully. Build a team of people they respect. Offer learning opportunities. Many AI people value the work itself more than the salary. Make the work matter.

Q: If good AI hiring is so important, why do most companies get it wrong?**

A: Because the VP hiring the ML team often doesn't have ML expertise themselves. They hire for credentials (PhDs, papers) because those are visible and prestigious. They don't have the judgment to hire for shipping because they don't know what shipped ML looks like. Solution: get an outside technical advisor for the hiring decision. Or hire the ML leader first, then let them build their team. The person doing the hiring needs to understand what they're hiring for.

Q: Isn't a fresh PhD better than an experienced engineer who's never done ML?**

A: Depends. A fresh PhD who's shipped a product is better. A fresh PhD who hasn't is probably not. A 10-year engineer with no ML background can often ramp up faster than a PhD with no shipping experience. Shipping is a skill. ML is a skill. You want both. When forced to choose, pick shipping. You can learn ML. You can't learn judgment about shipping.

Q: Should we build our own team or buy AI talent from a consulting firm?**

A: Both. Consulting firms can help you build the initial capabilities and hire the right people. But you need your own team long-term. External consultants are expensive ($200-500/hour) and they leave. Own talent is cheaper and builds institutional knowledge. Use consultants for onboarding and unblocking. Build internal for long-term.

Key Insight

Build balanced teams with three profiles: ML practitioners (deep domain knowledge, $180-280k), platform engineers (ML infrastructure, $170-250k), and product engineers (shipping, $140-220k). Hire 1 practitioner, 1 platform engineer per 6-8 generalists. Prioritize shipped work over credentials. Your interview should stress real problems, shipped systems, and team fit. This mix prevents over-engineering and shipping delays.

Building the Team

Great AI comes from great teams. And great teams are built by hiring thoughtfully. Spend time on this. Get it right and everything else gets easier. Get it wrong and you'll be hiring again in 18 months.

On This Page

Introduction
Three Profiles
Interview Process
What Not to Do
Sourcing Strategy
Monday Morning Action
FAQ
Key Takeaway

Chapter Details

Part ofCh 3: AI Talent and Team Strategy