"Data scientist" is one of the most misunderstood job titles, with its meaning varying wildly between organizations. One reason for this is that the term lumps together responsibilities which have more recently evolved into specialized roles: data analysts, data engineers, and machine learning engineers.

Some companies still need generalists who can deeply understand the business domain, set up cloud infrastructure, maintain data warehouses, process the data for analysis, and interpret model outputs.

Yet it is exceedingly rare to find (and retain) such generalists. The vast majority of companies would be better served hiring for more specialized roles, and finding candidates with slight overlaps (e.g. an expert at interpreting algorithms who can do basic infrastructure setup and maintenance if need be).

This guide primarily focuses on the competencies needed for the machine learning engineer role, the area where companies seem to struggle the most. Yet it also serves as a starting point for any related role, and highlights areas in the interview which can and should be customized for the different responsibilities.

Communication and Storytelling are vital to anyone working with data. The more senior the role, and the more collaboration expected of the role, the more true this becomes. At the end of the day, data only drives business value if the business acts on that data. That nearly always requires convincing stakeholders with a variety of backgrounds and levels of technical understanding. If the candidate is unable to bridge the gap between quantitative and qualitative minded-audiences, all their analytics will be worthless.

The ability to abstract and breakdown complex systems with Conceptual Thinking and Critical Thinking are key aspects for working with data in any capacity. Candidates must be able to think through complex chains of cause and effect relationships, design experiments to fill in gaps in knowledge, and draw probabilistic inferences and conclusions. This is true for any role, though it takes slightly different shapes for each. For example with data engineers, the specific ability to think through architecture tradeoffs and implications is vital.

Curiosity is arguably the single most important characteristic to hire for when it comes to data. If you don’t hire for curiosity, your data teams are likely to spend time on surface level tasks, such as simple data pull requests. They may never ask the questions necessary to get to root causes, and expose the non-obvious insights that drive real value. Curiosity is key to teams that ask the right questions: “how is this data valuable to you? And curious technical people are almost always working on some technical project in their own time, as a way to learn how something works (an industry, a tool, a technology, etc.)

Like Communication, Mental Agility and Empathy are also indispensable traits for data professionals. Anything can be viewed through a data lens… but not everyone naturally does so. But beyond just communicating with other points-of-view, data professionals must be able to simultaneously see and work with different points-of-view themselves. They must be able to not personally attach their egos to any one answer, and instead be empirical, skeptical, and follow the data. The best candidates hold beliefs as hypotheses and care more about ‘finding what is true’ than ‘being right’. Adapting to other people’s views or ways of working is a powerful example of mental agility.

Perfection is the enemy of progress, nowhere is that more true than in data science. In fact, as I like to tell our clients, if your machine learning model is ‘perfect’, it’s a sure sign you’ve done something seriously wrong! Practical Thinking is a must for every role, because there are always tradeoffs to make between performance and precision. This is a great question because you can let candidates answer to the area they are familiar with: a data engineer will speak more to architecture while a data scientist will speak more to model structure and organization. Plus you can follow up by asking what they would build first. In each case, look for practical tradeoffs that prioritize getting something workable into production.