An integral part of the hiring process for tech positions like a data analyst is the technical interview or technical screen. For many bootcamp graduates, this is an interview format they’ve never experienced before, and when all eyes are on you and your code, it’s easy to feel uncomfortable. As with all new skills, practice will make you better prepared and maybe ease some of those jitters when you encounter the real thing. Recently, Ben Hummel, a Senior Data Scientist at Zapier, spoke with our analytics and data science graduates on how to prepare for a live online coding technical screening interview in SQL, which is often at least one component of a technical interview and is an important skill for data analysts and data scientists.

What is a technical screen?

A technical screen or interview gives employers a chance to see your work and get a glimpse of how you think. It can be held in several different formats. A phone interview focuses more on conceptual technical questions like “what tools might you use to solve this problem?” A take-home exercise allows you to work on the problem on your own time. You can usually expect to have at least a couple of days for the exercise. There are also timed online tests that evaluate your skills, and whiteboarding interviews where you solve a problem by writing on a whiteboard during an in-person interview. Finally, there are live coding interviews that are conducted online as the manager watches you work. Live coding technical screens typically last 30-60 minutes. Ben shares his experience as a candidate and a manager with online technical screens and how best to prepare for one.

When conducting a live coding technical screen with a candidate, Ben shares, “I pretend I’m watching someone write code at work. [I look for things like whether you can] write the nuts and bolts of SQL? Can you spot bad data? Can you debug error messages? Do you write efficient queries?” Simply put, he wants to know you can do the work, not just list it on your resume.

Are technical screens hard? “Sometimes. [But] you’re learning what you’ll need to know at NSS,” he assures. “The pressure of the interview makes the tech screen problem seem harder than it is.”

It’s uncomfortable, new and different.

It’s not about writing perfect code, speed, or perfection

Preparing for the interview

The best way to prepare for a technical screen is to practice and simulate the interview environment. 

1. Find a problem. Websites like Hackerrank or Codewars are a great source for problems to practice. You may find it helpful to adapt the problems to the question format you’ll typically encounter in an interview: Given these tables, write a query that shows…
2. Set a timer and talk out loud as you work through the problem.
3. Ask a friend to watch you or record yourself. It’s important to create a similar, uncomfortable environment so that when you’re doing a real technical interview, you’re comfortable talking out loud and having a limited amount of time.

It’s also important to keep your technical skills sharp. Focus on the skills you’re most likely to use during the interview. Ben shared several concepts that often come up in a technical screen for SQL: 

• JOINs and how they differ (mostly LEFT vs INNER)
• GROUP BY / aggregations
• Subqueries
• The difference between COUNT and SUM (Ben cautions, “it’s easy to mix these up in an interview setting.”)
• Conditional statements: CASE WHEN / IF statements
• RANK() and ROW_NUMBER() (Ben’s Tip: everytime you see “per”)
• WHERE vs HAVING

During the interview

You’ve been preparing for weeks and the big day is finally here! Your first live coding technical screen. Ben highly recommends that you approach the problem methodically and explained his process as follows:

1. Understand the prompt; ask clarifying questions if needed.
2. Identify the columns you need. What tables do they live in? Are any of them calculated or aggregated fields?
3. Sketch out your SELECT statement, adding placeholders for calculated fields (e.g. SELECT ‘something’ AS col_a)
4. Stitch your tables together; write out FROM and JOIN(s). Double-check how the tables connect if it’s not obvious!
5. Add any filters you need.
6. Fill in any calculated/aggregated fields.
7. Sanity check! It shows you're not a robot, but a human.

You should run your code frequently as you're solving the problem. “Write in small chunks of code and run it,” he explains. “It’s a lot easier to catch and fix mistakes.” Finally, sanity-check the results at each step. Are the results what you expected? If not, talk through it.

While every interviewer will be different, many will allow you to use Google or Stack Overflow to check your syntax or research an error. But Ben explains it’s important to talk through it. Tell your interviewer what you’re Googling and why. It will help them understand how you think, even if you just need to check the syntax. We all have to check our syntax or research errors.

Sharing your thought process with the interviewer is a critical component of a live coding interview. Ben shared a couple of examples of things you might say during the technical screen such as, “It looks like I need fields from table X and table Y, so I’ll need to join them,” or, “I’m using a <left/inner/outer/full> join here because…” Talking out loud to yourself while someone is listening can feel incredibly awkward, which is why it’s important to incorporate this into your practice sessions.

Oh no! I have an error message!

Error messages are an opportunity to show the interviewer that you know how to debug. Carefully read through the error message as you don’t want to overlook key details provided in the message. Take a breath and then talk through your thoughts out loud. Just as you wrote your code in pieces, troubleshoot in pieces.

I didn’t get the expected output!

Again, no need to panic. Even if it’s your interviewer who pointed it out. Talking through your code out loud may help you spot the problem and sometimes your interviewer will nudge you in the right direction.

Help! I’m stuck!

Don’t give up. Sometimes the problems are difficult. Use the tools available to you, like Google and Stack Overflow. Ask for help. “Be honest. Don’t pretend,” Ben shares. “Show the interviewer where you’re stuck and explain what you think you need to do to get unstuck.”

After the interview

After your technical interview, it’s important to keep practicing. Brush up on areas where you felt like you struggled. Carve out a little time each day to work on a problem, even if it’s only 10 minutes.

I got rejected. I must not be good at this.

Rejections are super common and you should expect them. Ben shared with our seekers that rejections are often very subjective and depend on the role, company, and industry and can happen for a lot of reasons unrelated to your skills. For example, if they’re a health care company, they may have opted to go with a candidate with experience in health care, even though your technical screen and other interviews went well. Sometimes a rejection can be a good thing. Learn from the rejections and keep practicing.

If it's not a good fit, you don’t want the job.

A great way to practice and hold yourself accountable to practicing is to team up with your classmates. Take turns watching each other solve a problem. If you’re acting as the interviewer, encourage them to talk out loud when they’ve been quiet for a while, by stating, “tell me what you're thinking.” As you’re watching them solve the problem, think about how you might have approached the same problem differently -- there’s often more than one way to solve a problem.

Ben Hummel’s interest in data was sparked in a college statistics class. As a customer support representative with Dropbox, he started to learn SQL to create his own reports and has been building his analytics skills ever since. In 2018, he officially transitioned to a customer analyst at Dropbox. Since then, Ben was an HR analyst at Facebook and is currently a Senior Data Scientist at Zapier. In his spare time, he enjoys giving back to the tech community.