So you want to hire a Data Analyst ...
Don't know where to start, or just need some ideas? I've got you covered!
Welcome back to Data Rampage, where this week's topic is one of perennial importance to data leaders: hiring data analysts. I've hired quite a few data analysts in recent years, so I think I have some useful advice to share on the topic, and, well, I’m going to share it!
First, let's start with some definitions; what do I mean when I say a 'data analyst'? I've already written about the subject in a previous edition of the newsletter (see 'In defense of the noble work of the Data Analyst'), but in the broadest terms, for me a data analyst is someone who is responsible for working with data to produce insights that are relevant to the wider business. Data analysts are the public face of the data team; the work they produce - dashboards, reports, data dumps, etc. - is most commonly the main way that the rest of the organization engages with 'data'. Even in situations where business users have so-called 'self-service' data access, the hand of the analyst is not usually far away, whether as an unofficial consultant or as someone who has modeled the data sets used in the self-service solution. Data analysts should work closely with their business stakeholders to help solve real business problems, while also working with data engineers to ensure that the data infrastructure is being developed in a way that helps to solve those same business problems.
Therefore, when I hire a data analyst, I'm always looking for people who can combine business, technical and inter-personal skills effectively.
My general approach to hiring
These are the principles I always follow when hiring; I try to follow this approach for all roles:
You’re hiring a person, not a profile
Skills can be learned, but attitude is priceless - be ready to give a chance to someone who wants it!
You do, however, need to have a baseline technical skill level (which will depend on the level you are hiring for)
You need someone who can work independently
They need to fit the team and company culture
This isn’t a marriage - you don’t need to agonize forever about finding the perfect match
Let's go through this in a little more detail.
You will notice that most of these points are about personality, and there's an important reason for that: you're hiring an actual person, not a sentient blob of technical skills!
I've noticed that tech recruiting often has a check-box mentality, where the most important thing about a person is if they can match up to a laundry list of technical skills and experiences, thus meaning that they can slot in smoothly on day one. Personally, I think this is not the right approach; someone who has already done the role (more or less) is likely to get bored.
Beyond that, I think that character is crucial to someone's success. Any analyst will be part of a team, whether as an embedded analyst or in a centralized team, so it is essential to understand their personality. Can they get along well with and collaborate with others? Can they work with your stakeholders? Are they curious and do they want to learn? Can they communicate insights well? If they can't explain why something is important, it doesn't matter what kind of SQL voodoo they are capable of.
As far as character goes, obviously you as a hiring manager should be aware of your own style and look for people who will be able to work with you. Personally, I'm not a micro-manager, so I'm always looking for people who like to work independently; I see myself mostly as a facilitator of their work. I can help them to prioritize and I can offer feedback, but ideally I don't want to be too involved in the details of their daily work. This approach isn’t good for everyone - some people prefer to work in very structured environments with very clear instructions, like "do this, then do that", thus it's important to make this clear from the beginning.
This is not to say that technical skills are unimportant ... they are! When looking for an analyst, I always set a benchmark level of technical ability, whether I am recruiting a junior, mid-level or senior analyst. Part of this involves distinguishing between skills that are have-to-haves and those that are nice-to-haves. For example, I would not hire someone as a senior analyst who didn't have strong skills with SQL and one of the major forms of visualization software, like Tableau or Looker or Power BI. In an ideal world they would already have experience with your chosen tool, but that's not always the case - but I think someone with a lot of experience with, say, Looker, will be able to pick up Tableau without much hand-holding. In recent years dbt has become increasingly important, but I don’t think lack of dbt experience is yet an immediate red card. If they are also good with Python and/or R, that's a great bonus, but depending on our workflow it might not be necessary. I do like to hire people with some knowledge of these programming languages, because it opens up other possibilities beyond standard SQL queries against the data warehouse.
Your mileage may vary, of course.
As for the last point in my list ... well, you should be pragmatic. This isn't a lifelong commitment you are making, you aren't marrying them, just be reasonable. I see some companies spending crazy amounts of time in a hiring search; for example I just double-checked and one of the most prominent Berlin start-ups has had a VP of Data role advertised since last June. Really, they couldn't find someone in six months?!? I don't believe it, that's just being insanely picky. Honestly, you are better off spending two months finding someone who fits 80% of what you want, rather than spending 6-9 months (or more!) looking for someone who fits 100% of your criteria. In all likelihood you will be working with them for a few years maximum, so just be sensible.
Writing an effective job description
The first task when hiring is to write an effective job description; depending on the company, you as the hiring manager may have more or less control over what goes into the job description. Often companies will use standardized templates, the contents of which you have little control over, but in any case you should have the ability to influence the details as it pertains to the job.
Here I should sound a note of caution: no matter how carefully you craft the job description, how much time you spend tweezing the words into place, most people who read will just skim right through. Also, realistically, unless you work for a big and well-established company, they probably don't know anything about the company, so you are selling them on the role first and foremost. It has to sound interesting!
With that in mind, these are the principles I follow when writing up a job description:
Make clear the types of projects that people will work on
Make clear the kinds of responsibilities that people can expect, and make it appropriate to the level (it's not fair to advertise a junior role with a crazy list of responsibilities)
When it comes to skills, I make a clear distinction:
Skills that are must-haves
Skills that are nice to haves
Make life easier for yourself! You probably only really need like 3-4 skills, if you write a list of 12-15 key skills that candidates must have, that's a great way to find no one.
Bulletpoints are better than big walls of text - if people are skimming (and they are), you want to make sure that they are getting all the key points you want them to understand
Be ready to tweak if you aren’t getting traction - if you aren't getting quality candidates, don't be afraid to re-work the job description and see if you can improve the application flow
Working with the recruitment team
If your company has a recruitment team, you should build a strong working partnership with them as the hiring manager. Trust me on this, you will need their help to place the job ad and to source and review candidates. Depending on resources, they might not be able to help you with directly sourcing candidates, so if you want to expand the pool you can also be proactive in advertising the role. Two things that have worked for me in the past are (1) reaching out directly to people from my network, and (2) advertising the role on data-related discussion forums, such as the Locally Optimistic and #measure Slack groups.
When working with recruiters, remember they likely won't have a deep knowledge of your work, so make sure your must-haves. For an analyst I would usually say the following:
An appropriate level of experience; probably 2+ years for a mid-level analyst, 4+ for a senior
SQL - this is essential (for a senior today I would probably want dbt as well)
Experience with one of the major visualization tools (a bonus if they have worked with your specific visualization solution, but it's not a necessity)
Python and/or R (doesn’t have to be expert)
Some evidence of project management / delivery
One thing that might be helpful would be to look at some real profiles on LinkedIn together and discuss why individuals might or might not be good fits; this exercise clarifies open questions and builds rapport.
Reviewing CV's
Once you've written your job description and put the role online, ideally you will have a flood of great applications to choose from. That doesn’t always happen! In general, you will get more applications for more junior roles than more senior ones, so junior roles are easier to fill.
Next up is the CV review process, which is both pretty dull as well as extremely important. Depending on your company's set-up, you as the data leader might have to go through all of the applications yourself, or you might have someone from the recruitment team do a first pass before handing over a selection. Personally I want to be involved from the beginning, since hiring the right people is one of the most important parts of my job (as I see it).
Let's say you don't have someone to filter through the applications for you; how do you proceed?
The first step, and the easiest, is to find all of the super obvious noes and remove them. Generally these would be people who don't have anywhere near the right amount of relevant experience or skills. I've also learned to be quite wary of people who claim to be experts at seemingly all aspects of data work with short work histories - I generally assume they are lying, as very few people are experts in data science, data analysis, and data engineering - and if they are, they aren't applying for mid-level jobs at Berlin fintechs!
Other red flags can include lots of job switches where the person was in a (permanent) role for less than one year (mainly because why would I want to replace the role again so quickly?), and strange work histories with many unexplained gaps, but these aren't necessarily deal-breakers. The odd typo is ok, but if the spelling and a grammar is a huge mess that's generally a no-no; I make allowances for the fact that most people I hire aren't native English speakers, but an analyst has to be able to communicate well in writing, and if they can't even get their CV right, that's a bad sign.
So if those are the negative factors, what am I looking for?
Work experience - what kind of roles they have had in what kind of companies
Skills that have been used in a work context
The projects that they have worked on
Evidence of analytical mindset
Communication skills
The most important thing I look for is evidence that they can work as an analyst; for seniors this is obviously easier, because they will have a track record of projects and accomplishments you can parse for clues. It's trickier for people applying for junior roles, as they will either be young, finishing their studies, or career switchers (lots of them in data!), so in that case I look for evidence from either their studies or previous work experience that they will be able to work effectively as an analyst. Self-reported skills are a little useful, but I usually take them with a pinch of salt, because, well, people tend to exaggerate this.
For mid and senior level roles, previous work experience is crucial; what did they do and where did they do it? And this is where I think about the candidate not just in isolation, but also in terms of what they would bring to the team; for example, if we lack expertise in marketing analytics, would they be able to bring that with them? I would certainly rate previous work experience over online certifications and boot camps, simply because actual data work is pretty messy, or at least a lot messier than the toy problems you will deal with in bootcamps and online classes.
If I am lucky enough to still have a lot of people to choose from after filtering for obvious red flags and the have-to-haves, I might also look for nice-to-haves, which would include exposure to other topics like analytics engineering or data science. Except for juniors, I basically never pay attention to educational background (how can I judge which universities in Turkey or Ukraine or India are particularly good?), and I also try not to lock myself into looking for someone with a 'perfect' background - interesting life experiences can be very helpful in this role!
Ideally at this point I will have filtered the candidate pool down to something more manageable, and it's time to start the interview process!
The interview process
Many companies will have HR-defined standard interview processes; if you're in such a company, obviously you will need to work within those paramaters.
Let's assume for the sake of the argument that you're running this process on your own; what's a good interview process?
Here's a system I've followed in the past:
30 minute phone screening (by either yourself or the recruiter)
Longer in-depth interview with yourself
Home test - a piece of work to complete at home
Team interview (including presentation of the test)
Stakeholder interview (optional but helpful)
So that's four interviews plus a piece of work to be done at home; I'm not a big believer in dragging people through super long interview processes. It's not fair on the candidate, and it's distracting from other work you could be doing.
If I'm the one doing the initial screener, I always follow this format:
5 minutes me: Company and Team intro
5 minutes them: Personal intro
10 minutes me: Basic questions about their background
10 minutes them: Any questions they might have
The goal of this call is to establish the basics for both parties; for me as a hiring manager, I want to establish a baseline level of technical competence, language skills, and to decide whether it's worth continuing to the next round. For them, of course, it's an opportunity to see if the job sounds interesting, and if the hiring manager (me!) is someone they can connect with. This is after all a two-way process.
I always try to make my interviews friendly; there's a big power differential in the interview process, so why make it worse? The candidate is likely already stressed, there's no need to be harsh or hostile. A super intense and stressful interview process is not, in my opinion, a good way to hire quality analysts (or anyone really), since I am trying to select for thoughtfulness and creativity, not the ability to put up with abuse. Plus, treating people with dignity and respect is just fundamentally the right thing to do. This doesn't mean you can't ask tough questions, but you should always treat people respectfully (if only all interviewers knew this!).
For those candidates who get through the first round into the more in-depth conversations, I try to always work from a standard list of questions, one that mixes up questions concerning their past experiences, projects they've worked on, technical questions, how they handle different situations, and more abstract and personal questions.
Here are some more of my favorite interview questions (I guess I will need to think of new ones now!):
How do you explain to your grandmother what you do? [This helps me to gauge how succintly they can express themselves]
Give me an example of when you had to change a no to a yes for a project you were working on? [Are they capable of negotiating?]
Have you ever dealt with an awkward stakeholder? What made it difficult and what strategy did you adapt? [Difficult stakeholders are part of life for analysts, so I'm interested in how people work around this problem]
What's the project you are most proud of, and why? [It's interesting to see what people value in their work, and how they describe it]
When is a dashboard not your best option for delivering work to a stakeholder? [Analysts often spend most of their time working on dashboards, so it's good to probe the extent to which they can think creatively about other options]
If you came to work for me, what would you most like to learn? [This is a good way to see what people value and where they want to improve]
The value of having a script of ready-made questions is that it makes it easier to directly compare candidates by looking at how they answered the same questions. One other thing I always try to do early in the process is to work out how introverted / extroverted someone is, and if they are more introverted, I look to make them comfortable and get them out of their shell. Interviewing is itself a distinct skill, one that isn't exactly the same as doing the job of an analyst, so I always try to be aware that natural extroverts have an advantage in this process and then correct for this to the best of my ability.
As they progress through the process, there is a point where the candidates will do an analyst test at home and then send us the results. I don't believe in doing pre-timed tests or ones where we do some kind of screen share while they work, as this is not a realistic work scenario. So what if they use Stack Overflow? The most important part is how they explain the work. These tests use publicly available data (for example from a BigQuery public dataset), and the candidate provides an analysis of the data as well as some kind of visualization, plus any code that was written.
My goals with the test would be for the candidate to do the following:
Show basic technical skills in SQL and, less importantly, Python and/or R
Show ability to visualise information
Show ability to provide insights into the data
The test itself should not be something that takes hours and hours to do, since this is unpaid work. You want to use this to see if they measure up to your standards, but you also need to realize that people have jobs, families, lives, and it's unfair to force them to devote tons of time to producing work for you. I am particularly not a fan of giving people work that relates to the company, since this can seem like you are asking people to work for free.
When I am reviewing the tests, I always check if the code runs, I check for bugs, and I carefully study the analysis. What did they discuss? How well did they explain their conclusions? Do the charts make sense? Have they indicated unanswered questions? Would a stakeholder be satisfied with this standard of work? If I am happy with the test, then it's on to the next interview, a part of which will involve a short presentation on the test, where the candidate explains what they did and why.
This team interview is crucial because it helps to gauge see how they interact with others. Do they get defensive when questioned? Do they ask good questions? Do they show genuine curiosity? Can they not just answer technical questions in terms of what you would do, but also why? It's so important to me that the team is involved in the process, that they have buy-in to whoever is hired, so that this isn't just the hiring manager dumping someone on them, but that they fell that they can influence the process.
Making a decision
Finally, of course, you have to make a decision about who to hire. Look, if you're the hiring manager, this is your decision, not mine, so all I can tell you is how I try to make such a decision.
The first thing I ask myself when considering the candidates who made it to the final round is: do I think that any of these people have the capacity to do the job in the way that I envision?
If the answer is no, well, then I have to keep looking.
If the answer is yes and it's only one person who really fits the bill, well, that's my choice.
If I have multiple people who I think can do the job, then this is a tough choice. In such a situation, I would check again with the team for their thoughts, and then I would ask myself these questions:
Who is stronger in what area?
Who is more of a cultural fit?
What are the most important business and/or technical skills for the role and who matches it more?
Who will bring something new to the team, whether it is a skillset or relevant experience?
Once the decision is made, then it's time to make the offer and to negotiate the terms.
That's it! I hope this has been a useful read - feel free to reach out with any questions that you might have, or leave a comment.
One last (music) thing
As I mentioned before, I’ve been a dj for 25 years, so I’ve decided to end each newsletter with one of my mixes from my (extremely extensive!) back catalogue.
Self-indulgent? Sure.
This week, I’ve picked out the most ambitious project I’ve ever done, an epic four hour (!) techno (and a little bit of electro) set I did as an imagined set at Berghain, the most famous Berlin techno temple of them all. This was a very complex and maybe even somewhat insane project, but I’m very proud of it.
You can read more about it here.
I would also like to say thank you to Anna Fillipova for featuring my post “Understanding the user knowledge flow in an e-commerce business” in the The Analytics Engineering Roundup:
If you missed it, my last post was about how I used code to fix a problem where Google Drive duplicated tens of thousands of files:
That’s it for this edition of the newsletter, I hope you find it interesting and useful. Thanks for reading!