Dos and Don'ts for ML Hiring

- 2 minutes read - 405 words

This is primarily for my future self. These are observations based on my own experience of 2 years at Verloop.io and helping a few companies hire for similar roles.

Do

  • Seniormost hire first: Start by hiring the senior most person you’re going to hire. E.g. start by hiring the ML Lead (assuming you already have a CTO)
  • Have a means to tell that your investment in data science is working out or not
  • Closest to User first: Hire the person who will consume the data to build for the user first
  • Sourcing: Begin sourcing early and over-emphasise two channels: Referrals and Portfolios
    • Typically, in India - expect:
      • ~2 months to close a full time role at early career (0-3 years) and
      • ~3 months to close a mid career (3-7 years) and
      • 6+ months to close a senior hire
  • If a developer has open source code contributions in the last 2-3 years, consider waving off the coding or algorithmic challenge to speed up the interview process
  • Pay above market cash salaries
    • In 12-18 months from now, when your ML Engineer will have internalised all the requirements, company culture and built a bunch of important tooling - she would get an offer which is 2-3x of today. If you’re already paying above market salaries, a 20-30% jump is quite often enough to retain many folks
  • Have 3 at least versions of your shipping timeline
  • Do hire full stack Data Science people/teams. If you’re hiring for early members for your team, this is practical necessity. An example of T shaped skills could look like

Don’t

  • Rely on HR or your usual backend engineering hiring channels to work well for you, in general
  • Don’t hire the person who builds the means to move data (e.g. ML before data engineering) before hiring atleast 1-2 stakeholders in ML
    • Why? This is because it’s cheaper (and often faster) to change ML modeling approach than to make changes in data engineering pipelines
  • Don’t start by hiring an intern to implement papers or take things to production before you’ve done them
  • Don’t expect data science to deliver or ship at the same “user value” pace as Product Engineering
    • Why? Data Science suffers from the twin problems of being new and experiment-driven
  • Don’t assume that you’ve so much data, and since all of it is queryable, it’s all usable
  • Hire ultra-specialists e.g. post-docs and PhDs too early, barring products which requires invention and not application