Hiring & Building an AI Engineering Team

Dr. Bryan Bischof, Hex29:07 · Dec 2024 · 8,005 views
Thumbnail for Hiring & Building an AI Engineering Team Watch on YouTube
TL;DR
  1. 1

    Early AI teams need product, data, design, and software skills before they need dedicated machine learning engineers.

  2. 2

    Hiring should follow the product development sequence: get an early product in front of users, build evaluations, collect feedback, and iterate.

  3. 3

    AI teams should work directly with domain experts, while a central AI platform team gives product teams shared infrastructure and standards.

Summary

Dr. Bryan Bischof explains how to hire and structure teams building AI products. He argues that the right team changes with the product's stage. Early teams need software engineers, people with strong data intuition, product judgment, and design support. Dedicated machine learning engineers become more useful later, when the team needs capabilities beyond commodity model intelligence. Hiring should match the development schedule rather than adding many engineers to an early product. Bischof recommends interviews that test data interpretation, product thinking, and practical scope instead of relying on LeetCode. He also urges teams to work with the people who understand the target users and tasks. At Hex, this means regular contact with data scientists who use the product. For companies adding AI to existing products, he recommends a central platform team for model providers, prompt infrastructure, and evaluations, with an AI contact on each product team. He is direct about one trait he has not learned to train: curiosity.

Key ideas
01:23

The first AI engineer should expand product-building capability, not pursue research by default

Bischof describes his first AI engineering job posting as a search for a senior engineer who could rapidly expand the team's ability to build greenfield applications. The role required experience getting machine learning or AI capabilities into production and serving real users, enthusiasm for business applications, and an understanding of architecture and MLOps. He explicitly said the team was not looking for someone whose main goal was publishing at ICLR. That distinction was about the company's stage, not a criticism of machine learning researchers. He wanted someone able to work across the details of an application and help turn AI capability into a product.

04:14

The team profile should change as the product moves from early experiments to scale

Bischof says early teams need software skills, data profiles, and product competency. At the middle stage, they need more infrastructure, continued data expertise, and some design. Later, infrastructure becomes more important and the team can add machine learning engineers for tasks such as fine-tuning models or embeddings, search, and retrieval. By data profiles, he means people who can inspect distributions, notice strange outputs, understand product analytics, and recognize poor retention. He asks teams to know how good retention should be for their AI product and what comparable products achieve. Data intuition takes time to develop, so experienced analysts and data scientists can raise the level of the whole team.

06:02

Hiring must follow the product schedule instead of multiplying engineers around an early demo

Bischof warns against applying the mythical man-month to AI products. If a demo takes a week and the product takes four weeks, adding 20 engineers will not make it ship in a single month. Early AI products require an order of work: put an initial product in front of users, build evaluations, collect user feedback, and iterate. He says this schedule came from experience building an LLM product and from conversations with other practitioners. Hiring should follow the same sequence. Data work needs to happen earlier than it often does in traditional product engineering because the team must inspect product behavior and use that information to improve the system.

08:47

Early teams need clear hiring theses for each role

Bischof proposes defining the reason for each hire and checking whether existing employees could satisfy it. A full-stack engineer should integrate the product with an LLM provider and build minimum infrastructure. A data scientist should own evaluation quality and user data so the AI product can improve continuously. A product-focused person, whether a product manager, program manager, or product developer, should speak with users and understand their jobs to be done. Design belongs early because nobody yet knows what the product should look like. A machine learning engineer becomes useful when the team needs to go beyond commodity intelligence.

12:03

Data intuition and product judgment are better hiring signals than LeetCode

Bischof says LeetCode interviews give little signal about the work required to build AI products. His hiring loop includes a take-home data-cleaning exercise. Candidates must extract meaning from data and make reasonable conclusions without overcomplicating the task. He also values product intuition and says Hex uses a product design interview. In a later explanation, he describes giving candidates a large dataset with no objectively correct clusters. They must find latent meaning, write a short report, and discuss it live. The exercise also reveals how candidates respond to feedback, scope a task, and judge what can be delivered in four hours over seven days.

14:17

Curiosity and attention to AI product behavior matter alongside technical competence

Bischof wants people who pay attention to AI products instead of simply following the current wave. Strong candidates try different products, form opinions about what works and what does not, and think about AI design patterns. He gives the example of a candidate who had written about AI design patterns and how AI products should feel. That writing showed awareness of design and product questions, although technical competence still mattered. He also names data intuition, product-mindedness, urgency, and a willingness to work across Python and TypeScript. He says a little ADHD can help when the environment changes every few months, based on his own experience.

16:46

Domain experts should shape the AI capability through repeated use

Bischof calls direct work with experts the most important idea beyond hiring. The people who understand the target task should use the product and help shape its behavior. A customer support bot should be used by customer support workers every day. At Hex, Bischof is a data scientist and speaks with the company's data scientists every week; they use every feature. He says even a smart engineering or machine learning leader cannot know the right product alone. The exception is an AI tool for generating machine learning and AI products, because the builder is already the domain expert. Otherwise, the team needs continuous contact with practitioners.

25:40

A central AI platform team can let product teams add AI without rebuilding the basics

For companies adding AI to existing products, Bischof recommends at least one team that builds shared infrastructure for AI capabilities. Individual product teams should not each create separate relationships with OpenAI, build their own prompt infrastructure, or invent their own evaluation systems. Those pieces should be coalesced across the company. Product teams can then work with the platform team through a designated person who owns the interface, similar to the relationship between Stitch Fix's data scientists and its data platform team. Bischof acknowledges that Netflix uses a more decentralized approach, but says that model makes sense for Netflix and may not fit most companies.

27:48

Some traits can be developed, but curiosity is the trait Bischof has not learned to train

In the final question, Bischof says candidates need some existing kernel of the attributes he discussed, including data literacy, urgency, and enthusiasm for AI products. Having none of one of those traits worries him. He then adds curiosity as a particularly powerful latent feature in his hiring model. It is the one trait he has never personally succeeded in training. This gives his advice a practical limit: teams can teach tools, workflows, and domain details, but they should be cautious about assuming that every missing behavior will appear after hiring. The interview process needs to look for the underlying disposition before the person joins.

"That's one latent feature that I didn't mention that I've never personally successfully trained, and is a really big powerful feature in my model, and that's curiosity."28:28
Who should watch
  • You are hiring the first engineers for an AI product and need to decide whether you need software, data, product, design, or machine learning experience.
  • Your interview loop still relies on algorithm puzzles and does not test whether candidates can interpret messy data or make sensible product decisions.
  • Several product teams are adding AI independently, and you need to decide what should belong in a shared platform team.