At Grio, we believe it takes great people to build great software. That’s why, when we add new members to our team, we work hard to ensure that we are hiring the best people for the job. In this blog post, I will cover tech interviews – why we do some of the things we do and how we use efficient tech interviews to screen for the best candidates for open positions.
The Interview Process
When you are interviewing a candidate, they typically have to go through several rounds of interviews before they are offered the position. Throughout this process, you might utilize several different types of interviews, such as:
- Phone Screen: A phone screen is typically an initial, shorter interview that gives you a feel for the candidate and allows you to determine, based on initial impressions, whether it’s worth moving forward with the candidate.
- Take-Home Projects: Take-home projects are assignments that the candidates complete that allow you to test their skill set. While this is a great way to analyze a candidate’s proficiency, it is also requiring someone to complete unpaid work, which can make your company a bit less competitive compared to other companies that don’t have take-home project requirements.
- Tech Screens: Tech screens are short proficiency tests that are completed as part of an interview. They are extremely common in the industry, and are used by nearly every company.
- On-Site Interview: The on-site interview is typically the final interview with the client. While these were historically conducted at the company offices, they are now more commonly virtual.
Within the Grio interview process, I often conduct tech screens with potential candidates. Based on the proficiency requirements of the job opening, there are several different tech screens that we can conduct, including:
- App or Component Construction
- Technical Questions
Build an App or Component
Given Grio’s typical workload, I like to have candidates build an app or component for their tech screening. I believe that there are several pros and cons to this method:
- It allows you to see how someone works through problems
- It is repeatable. If every candidate is given a similar problem, you can compare and contrast your candidates in a more controlled environment.
- It is collaborative. You are part of the process, so you get the chance to see how well they work with others.
- It is an unrealistic environment. It’s very rare that you are in a situation where you only have 30 minutes to solve a problem.
- It evaluates skills that aren’t necessarily relevant to the job. For example, how well you handle pressure isn’t necessarily indicative of how good of an engineer you are.
- It creates anxiety and pressure for candidates that are already nervous.
- It tends to force candidates to perform with unfamiliar coding environments. For example, we have candidates use Coderpad to create their apps. While Coderpad is a common choice, it is not the coding environment the candidates are most comfortable with, and can therefore lead to errors when they are expecting features of their preferred editors to be present.
Logic Behind the “Build an App” Tech Screen
Even before joining Grio, I put a lot of thought into how tech screens should be conducted. I have been interviewed a lot over the course of my career, and I have left a lot of interviews feeling like the interview itself was not well conducted.
When I began giving interviews myself, I too found myself falling into some of the pitfalls that I hated when I was the candidate. Most noticeably, I realized that I didn’t enjoy making the candidate feel bad about themselves. While many tech screens leave candidates feeling downtrodden, I realized that it didn’t have to be that way, and I adjusted my interview process accordingly.
I believe that, if you really enjoy the subject matter, the interview should be a pleasant experience, regardless of whether or not you get the job. I used this belief to create the tech screen that I currently conduct at Grio.
My Tech Interview Structure
When I conduct a tech interview, it is usually an hour-long video interview that is split into the following sections:
- 10-minute introductions (both the candidate and me)
- 40-minute coding exercise on Coderpad
- 10 minutes for questions about Grio
I feel that it’s important that we both have time to ask questions, as it’s just as important that the candidate feels that Grio is a good fit for them.
The Coding Challenge
As mentioned above, the coding exercise in my tech interview is usually completed on Coderpad. I generally approach the challenge using React, as it is the most common frontend view library utilized at Grio.
For the challenge, I typically start with a simple “Hello World” application, and then have the candidate build on it. Over the course of the 40-minute exercise, I will have the candidate:
- Build a component that renders something
- Make the new component do something (fetch data, etc.) and render something else
- Add some interactivity
- Add complexity
If time allows, I might then have the candidate build even further:
- Do the same thing in an entirely different way
- Make it look nicer
- Add a more complicated feature
These challenges allow me to access a number of skills and proficiencies, including:
- React hooks or life cycle methods
- Data fetching patterns
Conducting the Interview
When conducting the tech screen, I try to conduct the interview in a way that I find helps candidates relax and show their best work. My tech screens always include:
- An explanation of the coding environment. Before the exercise begins, I give candidates some basic details about Coderpad so that they don’t spend their time on unnecessary exploration or useless tasks.
- Simple problems with clear instructions. I start simply because I find that people are so nervous when they start the interviews that if the first question is too complicated, they will fail almost immediately. Starting with easy wins allows them to take a deep breath and calm down.
- Incremental building, so as not to expose all the steps at the beginning. Like the point above, I find that introducing instructions as we go helps candidates stay focused without getting overwhelmed.
- Helping with formatting. As the exercise progresses, I will help with code formatting and minor syntax issues so that the candidate can focus on the larger task at hand. I don’t believe that the success of an interview should be determined by your ability to find a missing semicolon; it should be about your overall skill level.
- Questions. I make sure to ask questions throughout the process to encourage them to vocalize their process and reasoning. Even if they are doing something correctly, I still like to ask them about their thought process, because it’s a confirmation that they fully understand what they are doing.
- Potentially going off-script. Sometimes, based on what the candidate is doing, I will go off script to allow them to pursue a unique idea or skill. It’s important to remember that every candidate is unique, and to allow them to express themselves through their work.
- Having an “infinite” amount of steps. While not really infinite, I have more potential steps ready than anyone will ever complete ensuring that I don’t run out of things to ask of the candidates.
- Following up on things that are done both “right” and “wrong.” As mentioned above, these follow-ups help me to better understand the candidate as well as their proficiency.
Once the tech screen is complete, I evaluate candidates based on a number of performance standards, including:
- How far did they get?
- Were they able to explain things?
- What types of mistakes did they make? Sometimes there are really obvious issues that imply they don’t really understand the language.
- How did they troubleshoot?
- Did they follow the directions?
- Did they get more comfortable as the interview went on?
- Did the proficiency they showed align with my expectations (from their resumé)?
When completing the evaluation, I also ensure that I am evaluating their skills based on the job for which they are specifically applying. For example, if I am evaluating a more junior candidate, I expect them to have a more junior level of proficiency. However, if they are applying for a senior position, a junior level of proficiency is a red flag.
Red Flags that Can’t be Overlooked
The main issues that I have a hard time overlooking during the tech screen include:
- Poor understanding of a language they say they know: obvious scope issues, closures, and callbacks
- Poor understanding of promises/async
- Making the same mistake multiple times, even after it’s been pointed out
- Blaming the boilerplate code for their own mistakes (repeatedly)
- Not attempting to debug simple issues
Problems with My Tech Screen Format
While I have updated and evolved my tech screen with every interview I conduct, I acknowledge that it still isn’t perfect. Some of the most noticeable problems with this interview format include:
- The simple questions approach may not be challenging enough for the best candidates, making it harder for them to stand out.
- I don’t have time to create tech screens for every frontend framework. Since all of my interviews are currently completed in React, candidates who prefer React as their code of choice have an advantage.
- Coderpad can be kind of miserable compared to IDEs.
- Unconscious bias. While I always try to evaluate candidates purely on skillset, we all have biases we are unaware of that can influence our feelings towards a candidate.
- The tech screen is predominantly about the skill exercise, so I have to rely on the other interviewers to ask the soft questions. For example, it is up to the other interviewers to catch personality red flags and to determine whether a candidate will work well with others.
At Grio, we are constantly evolving our interview process to create a process that is enjoyable for all parties while being efficient and fair. Tech screens are an important part of this process, as they help us ensure that we are selecting the best possible candidate both for ourselves and our clients.