The Software Engineering Interview — The Tech Screen

This is part 2 in my series on the Software Engineering interview. You can find part one here and my thoughts on what makes a good interview here.

One of the first steps in the software engineering interview process is usually the Tech Screen. In this article, we’ll break down the purpose of these interviews, what they look like, and what I think makes one effective.

What does a Tech Screen look like?

The format of the tech screen is going to vary by company, but it’s pretty much always going to be a short evaluation of the candidate’s technical background. Usually the evaluation isn’t too deep; more intensive technical screens are reserved for later in the process. The key is they’re short and easy to conduct.

Most commonly the tech screen is conducted by the hiring manager for the position or a potential future peer. These are the people who will be working closest with the potential hire so it makes sense that they’d be able to most quickly and effectively the candidate.

Why do companies have Tech Screens?

The technical screen is pretty well named — it’s meant to filter (screen) candidates based on their technical experience! Any engineering role is going to have technical requirements and the company needs to be able to assess a candidate’s ability to fulfill them.

If there’s more intensive technical interviews, why do we need a tech screen?

Efficiency! Companies get a lot of applicants (hopefully). Unfortunately, they probably can’t hire all of them. Because of this, candidates need to be filtered out at each step, until there’s a decision on one to hire or a pool of potential hires. Since the tech screen is one of the first steps, it’s going to be conducted more often than other interviews. To keep the hiring process efficient, the most common interview needs to be short and effective.

What makes a Tech Screen effective?

Earlier, we talked about how tech screens need to filter out candidates. We clearly, don’t want to filter out all of our candidates, but we do want to reduce the number of more expensive and intensive interviews that we need to conduct. So how do we find a good middle ground?

If we think about what generally makes a good interview (cough here cough), we know that the interview should be relevant. Well, what’s more relevant to a job than the job description!

Let’s say we’re hiring for a position with the following requirements in the job description:

• Experience building production ready, customer facing web applications with React and Typescript
• Regularly gives code review feedback to teammates

Some good questions to ask could be:

• Can you explain what state is in React and how it’s used?
• What are the advantages and disadvantages of using TypeScript over JavaScript?
• What do you look for when reviewing code?

This approach requires a clear and relevant job description, which can be difficult to make by itself, but it can lead to great results.

I’ve unfortunately been on both sides of technical interviews where a specific language was required, but not screened for. This leads to a waste of both the interviewer’s and the candidate’s time and an awful experience for the candidate.

Keep it simple

This approach can be effective, but it’s easy to go overboard. We shouldn’t try to hit every single point on the job description in this round. Just-below-the-surface-level questions for a few of the most important points should be fine. Since this is the first step, we also want to avoid scaring the candidate off by grilling them about every single bit of the job in one interview.

Remember this is supposed to be a quick and effective interview. Questions should be to the point and relevant. Like any interview you’ll also want to save time for the candidate a chance to ask questions about their future job!