Start with what breaks if the role stays empty
If the answer is 'we cannot answer questions about the business', you want analytics. If it is 'the model works but we cannot ship it', you want engineering. If it is 'we do not know whether this is possible', you want research.
Those three hires read completely different job adverts and are motivated by completely different things. One question at the start saves a month of interviewing the wrong people.
Research strength and production strength rarely coincide
Some of the strongest modellers have never had to keep a system running at three in the morning. Some of the best data engineers have no interest in an open-ended research question and will be bored within a quarter.
Teams that insist on both in one person usually end up hiring someone mediocre at each. Hiring two people who are excellent at one thing each is, more often than not, the cheaper answer.
Ask what they shipped, not what they used
Tool lists have stopped being informative. Everyone has touched everything, and a CV is the wrong place to judge depth.
The useful questions are about consequence: what did you build, who used it, what changed because of it, what would you do differently. Candidates who have only done coursework run out of answers quickly, and candidates who have done the work tend to enjoy being asked.
- What did you ship, and who used it?
- What did you own end to end versus contribute to?
- What broke, and what did you change afterwards?
- Where did the data come from, and how dirty was it?
Define the failure you are trying to prevent, and the title usually writes itself.
Hiring for a role like this, or weighing a move?
Talk to us
