What to Expect in Data Visualization Engineer Job Interviews
By: Krist Wongsuphasawat
Tags: Software Development, Data Visualization, Interview, Career Advice, Software Engineering

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.

Background

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 description 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 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.

Overall Process

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.

The next step was the phone interview, a.k.a., phone screen. From an interviewer’s perspective, the goal of the phone screen is to determine whether the candidate is worthy of an on-site interview, which means a full day of their colleagues’ time. Senior candidates could sometimes skip this step with strong referrals. Sometimes you could also get a second phone screen if the first one had mixed signals. Given that the majority of custom data visualization development now relies on web technologies, the phone screen questions were usually front-end (javascript) coding. Yes, you are very likely to have live coding sessions.

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:

Front-end coding

There are 99% chance that you will get this type of question during the phone screen, on-site, or both. These are the typical front-end engineer interview questions (javascript, css, HTML), e.g. DOM traversal, event delegation, array manipulation, callbacks. If you have no idea what these terms are, you have some homework to do. Most of the time you have to write the code, not just verbally answer. The goal is to check if you can code and probe how deep you actually know the language.

Instead of standard javascript questions, some companies were more creative and leaning towards more practical questions by asking the candidates to implement UI components or user interfaces based on given screenshots or GIFs, which I enjoyed more. If you have written some web applications, the experience can become handy here.

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.

Algorithm

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.

The 6th edition of Cracking the Coding Interview: 150 Programming Interview Questions and Solutions

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.

Usually the programming language is your choice, so you can use javascript.

SQL

This type of questions is a bit uncommon and I was asked only once, but I will include it 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 SELECT queries.

It may worth revisiting how to do all kind 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 question?”

System Design/Architecture

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.

Experience Interview

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!

Cultural/Behavioral Interview

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 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?

Afterthoughts

Tthese are all the type 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 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 enough. So do your homework, figure out what 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.

Acknowledgement

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.