Preparing for data visualization job interviews can be quite challenging, as it seems every company asks different things. I wrote this article based on my own experience, hoping it can give job hunters some ideas on what to expect, as well as surveying ideas for conducting an interview for someone with this skill set.
About a year ago, I had the opportunity to interview with several tech companies in the San Francisco Bay Area for roles related to data visualization.
The reason I use the term “roles related to data visualization” is because not every job listing includes “data visualization” in the name. (On the other hand, some job listings that have “data visualization” in the names or descriptions may not include that much visualization work.) There is data visualization work in engineering, data science, journalism, research, design, consulting, etc. Your day-to-day could look very different, with varying amounts of data visualization work. For example, some roles expect you to create visualizations using Tableau much of the time. Other roles consider data visualization a nice-to-have skill but is not mandatory for doing the work. Some roles expect you to implement their in-house systems with custom data visualizations as part of them. Some roles expect you to focus on the design and let others implement, i.e. code, interactive data visualization for you. Roles in news and media expect frequent new projects with very fast turnarounds.
After filtering through the many different roles, I chose to proceed with the engineer positions, which suit my background and interests the most. The job titles range from front-end engineer, data visualization engineer, UX engineer, and software engineer.
The first thing to keep in mind is that data visualization is one of the most important skills, but having only that is usually not enough to land these roles.
Companies are at different stages and are of different sizes. Some are private, planning for IPOs. Some are already public. Some are small and located in a single office. Some have offices around the globe. Similarly, each company’s data visualization maturity is at a different stage. Some want to start investing in this area. Some have a small team. Some have very established team(s) already. Each company also organizes the data visualization folks differently. Some have a number of specialists scattered in multiple teams around the company. Some have a centralized team. These can affect how they value different skills and understanding what they are looking for is an important part of the process.
Given all the factors above, each company ended up asking me totally different sets of questions.
All the companies I interviewed with had similar recruiting processes. It usually started from initial calls from a recruiter and/or hiring manager to discuss the expectations and make sure both sides were aligned on the roles and other details, as well as explaining their processes before proceeding.
After that was the on-site interview, which included a full-day panel of 4–7 sessions. Each session has one or more interviewers. This was where the interview questions differed greatly. Sometimes the company could also ask for additional session(s) after the on-site, which could be remote or in-person.
Type of Questions
Instead of describing each panel individually, I grouped the questions into the following themes:
Commonly shared coding environments are CoderPad, CodePen, or similar. Only one company insisted on using Google Docs. Oh! Also, don’t forget whiteboard. My advice is definitely to try coding on these environments beforehand to get yourself familiar.
This is the standard “Cracking the Coding Interview” type of questions. Given a problem, come up with an efficient algorithm to solve it. I had at least one session in almost every panel. Although this is also a coding session, the focus is different from the front-end one. The goal of these sessions are to test your logical thinking and algorithm/data structure knowledge to ensure you can write good code, as well as seeing how you approach complex problems and communicating your ideas.
General approach is trying to get the brute force solution out first and progress gradually from there. Knowing the type of data structures that can help you. It may worth fleshing out ideas and discuss them with the interviewers verbally before start writing code.
This type of question is a bit uncommon and I was asked only once, but I will include it here nonetheless. The reasoning for including SQL question is that data visualization works with data, so there are chances that you have to query data or work on the pipeline to feed your tools. However, the expectation for this skill should not be at the Database Admin level and questions should be limited to
It may worth revisiting how to do all kinds of JOINs if you know there will be SQL questions. You can ask the recruiters about what to prepare for the interviews, e.g. “Will there be SQL questions?”
For this type of question, you are asked to design something and discuss the ideas with the interviewer. Design decisions usually come with trade-offs. As you progress, you should be able to explain with good reasons why some decisions were made. If there are relevant personal experiences, mention them. The interviewer may point out the potential issues with your solution and ask you to improve your ideas.
For the traditional software engineer role, the expected output will be an architecture of a system, such as how would you implement a messaging app and make it able to handle heavy traffic and ensure timely delivery. What are the major components? What are they for? How will you connect them? What are the potential issues with this design?
With some front-end twists, the questions can become API design. How would you define behavior and/or APIs for a specific UI component, such as a date selector? What are the options you would let someone customize it? How would they specify such options?
For visualization-specific questions, the interviewer may pose as a client who comes with a visualization need and ask you to visualize something for him/her. This can be a totally artificial problem or something related to their real work domain. The scope of the questions can vary from visual/interaction design only to including implementation details.
The goal of the experience interview is to deep-dive on projects you have done in the past and learn how you work on them. You should pick projects that you have contributed a significant amount of work and know in and out of the projects, so you can have a lot of details to share. This is an opportunity to share your depth of knowledge and show off your work.
Prepare your story and practice!
These questions focus on how candidates handle situations in their past work experience and as well as evaluating whether they would fit in with the company culture and values. Sometimes this type of session is combined with the experience interview.
Example of behavioral questions:
- Tell me about a stressful situation at work and how you handled it.
- Describe a time when you disagreed with your supervisor on how to accomplish something.
- How do you prioritize your projects?
These are all the types of questions I’ve been asked while interviewing for data visualization positions in the engineering track in tech companies. I hope they give you some ideas of what to expect.
For the candidates, there are some sessions in which your data visualization skills will play key roles, but there will be tests for other skills as well. As I have mentioned earlier, data visualization is one of the main skills, but having only that is usually not enough. Do your homework, figure out the skills required for the target roles, and make sure you can tick all of the checkboxes. If you are choosing the engineering track, there will be lots of expectations for front-end engineering skills.
Also, I personally believe that having a portfolio or example projects that the interviewers can take a look at is a great help. Given the limited time to interview, it is hard to evaluate someone deeply within 45 minutes.
For the interviewers, a good panel should coordinate to evaluate multiple aspects and only test for the skills that will be required to do the job. Do not throw in irrelevant interview sessions. If there are chances to personalize the questions/sessions to make them more relevant to the candidates’ experience, the candidates usually appreciate such considerations.
Data visualization design questions should be something challenging but solvable, not something the interviewers still could not figure it out and ask the candidates to figure out in 45 minutes. It might also worth listing several knowledge areas (e.g. color, knowledge about common vis types) you want to test in the design question and guide towards them to provide semi-structures in the interview instead of leaving it to be entirely free-form. This will help with the evaluation as well as comparing different candidates.
I am grateful for all the opportunities given to me and would like to thank all the referrers, interviewers, recruiters, managers, and everybody that were part of the processes.