What to Expect in the Data Visualization Engineer Job Interviews
Preparing for data visualization job interviews in the industry can be quite challenging as it seems every company ask you different things. I wrote this article based on my own experience, hoping it can give the job hunters some ideas on what to expect, as well as survey ideas for interviewing someone with this skillset.
About a year ago, I had the opportunities to interviews 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 include “data visualization” in the position name. On the other hand, some job listings that have “data visualization” in the names or description may not include that much visualization work. There are data visualization work in engineering, data science, journalism, research, design, consulting, etc. Your day-to-day could look very different, with varying amount of data visualization work. For example, some roles expect you to create visualizations using Tableau most of the time. Some roles consider data visualization a nice-to-have skill, but 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 design and let other implement for you. Roles in news and media expect frequent new projects with very fast turnaround time.
After carefully screening the information, I chose to proceed with the engineer positions which suit my background and interest 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 data visualization is one of the main skills, but having only that is usually not enough to land the roles.
Companies are at different stages and of different sizes. Some were private, planning for IPOs. Some were already public. Some were small and located in a single office. Some had offices around the globe. Each company’s data visualization maturity was also at a different stage. Some wanted to start investing in this area. Some had a small team. Some had very established team(s) already. Each company’s also organized the data visualization folks differently. Some had a number of specialists scattered in multiple teams around the company. Some had a centralized team. These can affect how much they value different skills and how much they are willing to take you in if you do not really fit their mould.
Given all the factors above, each company ended up asking me totally different sets of questions.
All companies’ recruiting processes had similar steps. It usually started from initial calls from recruiter and/or hiring manager to discuss the expectations and make sure both side are align 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:
Common shared coding environments are CoderPad, CodePen or alike. Only one company insisted on using Google Docs. Oh! Also don’t forget whiteboard. My advise is definitely 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. 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 questions is a bit uncommon and I was asked only once, but I would put it in here nonetheless. 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 Database Admin level and questions should be limited to
It may worth revisiting how to do all kind of JOINs if you know there will be SQL questions.
For this type of questions, 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 experience, 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 question, 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 it. 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 candidate 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 sessions 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?
So these are all the type of questions I had experienced while interviewing for a data visualization positions in the engineering track in tech companies. I hope they would give you some ideas of what to expect.
For the candidates, there are some sessions that your data visualization skills will play the 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 good enough to land the roles. So do your homework, figure out what are 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 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 you all referrers, interviewers, recruiters, managers and everybody that were part of the processes.