Tech screenings are cringeworthy. That’s not exaggeration: when you bring them up to people in tech in person, you’ll normally be gifted with some very interesting expressions of disgust. Even just mentioning I was writing this post meant I received some very heartfelt commentary, none of which was in favor of them.
If you’re not familiar with the perception of tech screenings, you should start off knowing that their reputation is awful, that no one agrees how they should happen, and that, no matter what format people choose, someone is normally inconvenienced (at best).
From the point of view of those setting up tech interviews, tech screenings are a standard activity. This is what interviewers use to assure themselves that the candidates are fit for the role, regardless of how often it’s pointed out how different day-to-day work is for most people. They rarely take place in person, normally featured as a second or third step in the interview process (after being screened by a recruiting professional at the business, for example, or the hiring manager).
There are four main ways that these tech screenings tend to take place: looking at a candidate’s personal project(s), giving the candidate a challenge project, administering timed challenges, and live internet whiteboarding.
Below are reviews of each type and why, despite what you may think, they do not actually make your hiring process any better. Further down, you’ll find suggestions for alternatives.
Four Major Types of Tech Screenings
The Personal Project
What it is:
People show personal projects on Github or send the code directly to the interviewers. They may then ask to be walked through parts of it during an interview.
Why it’s done:
Some places want to see code that a person has made without giving any sort of specific challenge. This is seen as a good indication of both a person’s interests and how they work through problems, as well as their level of dedication to coding.
What’s good about it:
If a person already has a project to show, this puts significantly less stress on them and can save them time. It’s also a better indicator of the sort of code someone might do in a real life situation.
What’s bad about it:
Not everyone can have side projects. Some people are already working very long hours at their current job. Some people have duties at home such as being the main caregiver for someone. Some people are stressed, or depressed, or exhausted. Some people physically can’t do more.
A lot of people are looking for new jobs because they need better work-life balance or their current job is making them miserable, which basically means their personal projects are either going to be not-great or old.
The Challenge Project
What it is:
This generally features a format along the lines of ‘here is a challenge (or a set of potential challenges to choose from) that you can do in [a few hours] and is due [in a few days]’.
Why it’s done:
In general, people believe that this both creates a somewhat natural setting (allowing people to think through the project before starting it and work on it piece by piece) while also showing the skills relevant for the job.
What’s good about it:
This avoids the downsides of the above personal project while also allowing people to juggle their time to be able to do it.
What’s bad about it:
It still favors people with more free-time and who are healthier/happier in their current situation. There’s also often not much control over when the challenge starts/ends (sometimes, out of the blue after an initial screening, the interviewer will just send an email saying here’s a project and it’s due in a week), which makes it difficult for people with busy schedules or who may have other commitments.
If a time limit for the actual work isn’t given (eg, ‘you should take no more than 4 hours’) then people with anxiety or other issues will be stressed about how much time to spend on it. Even with a time limit, it still favors those with more time as a suitably challenging project for the candidate/position would mean they would need more time to refactor at the very least. The time limit may also ignore that the candidate may not know the technology involved, because while many challenges say to use the language one is most familiar with, they may require APIs, libraries, or other technology that a candidate might not have used before, taking up even more of their time simply learning the basics simply so the interviewer can see something they’re familiar with.
Also, many of these challenges aren’t very specific, they’re not “here’s what we want you to do and here’s what we want you to do it with” but instead “here’s a vague example of multiple sorts of things you can do” which not only means they don’t give side-by-side comparisons between candidates, but also means that the candidate not just has the work of the project, but also has the extra work of coming up with the project in the first place. Furthermore, these rarely reflect how an employee would receive work or the sorts of work the candidate could be expected to do once they take the job, so that interviewers don’t know how they would actually perform at work.
The Timed Challenge
What it is:
The format generally consists of something along the lines of an email at a certain time that must be replied to with a github repo within a certain time limit (say, 2 hours) or a link to a website dedicated to timing coding challenges that starts once you enter the challenge.
Why it’s done:
It returns enough code to most likely evaluate the candidates skills, tests how they work under pressure, and is seen as not too time consuming.
What’s good about it:
Unlike the above types, everyone spends the same amount of time on it, which makes it better for people with less time on their hands and better for the evaluation process. It can take place at any time of day/day of the week, so it can be done outside of work hours for the candidate. It also shows how someone does under pressure, much like a regular test.
What’s bad about it:
Along with many of the issues with a challenge project, this penalizes people who can’t take that amount of time uninterrupted (parents, people with certain disabilities, etc.). It’s more stressful. It’s not a “real-world” environment and rarely is it a “real-world” problem that the candidate is asked to solve. It also requires regular, decent access to the internet outside of work, penalizing those of lower income, in rural areas, and others.
The sites that are used for these type of challenges are generally quirky and don’t have great UX. They can require a decent amount of prep time just learning their ins and outs before even starting the challenge, which again favors those who have more time. The sites also may not fully support the language of choice for the user or if libraries are needed may only support very limited libraries (for example, if someone is interviewing and using Javascript as a frontend developer, these sites may require them to have Node knowledge that the job would not require). Often they are setup more for the comfort of the interviewer than the candidate, which is at odds with how someone’s preferred development environments and workspaces would be run.
Live Online Whiteboarding
What it is:
The candidate and an interviewer both online, looking at the same site, as the candidate works through a challenge.
Why it’s done:
It’s basically just an alternative to the in-person whiteboarding exercise. Normally either as an early screening process that the company doesn’t want to invest a lot of time and money into or for candidates that would have to travel for an interview.
What’s good about it:
As mentioned above, candidates do not have to travel (or even leave their own homes). It allows for a real-time conversation between candidate and interviewer, which also may allow for pseudocoding instead of having to do working code, thus proving that the candidate knows what to do even if, like in real life, they may need to look up the exact way of doing it. It can also be used as a pair programming exercise instead of a straight up challenge, which shows the interviewer how the candidate works with others.
What’s bad about it:
Like a whiteboard exercise in real life, many people find these even more stressful than the rest of the interview. The challenges are often not real-world compatible and even if they are, the nature of them means the candidate is not supposed to Google for answers, let alone copy and paste from Stack Overflow. The interviewer is generally a person the candidate has never met or talked to before. Sometimes they’re not even on the team that the person would be working with and can’t answer questions, but instead are just there to grill the candidate. At times, even if it is the arguably less stressful pair programming variety of whiteboarding, the company‘s employees don’t actually do pair programming at work and it’s not a good indicator of how the person would be as an employee. It also requires uninterrupted time and good, reliable internet as some of the other types of tech screenings do.
And because it’s live for the interviewer, that can mean it takes place during normal work hours, favoring people who work from home or can take time off. It basically has almost all of the downsides of in-person whiteboarding, without the benefit of generally having hours of interviewing which will allow a candidate who is too nervous to perform well on the whiteboard to still make their case.
Why Should You Care If Your Tech Screenings Are Bad?
There are two very obvious outcomes to bad tech screenings:
Firstly, a candidate who passes may still decide to not continue with the interview process or may be put-off from accepting a job offer because of a bad tech screening. Tech screenings represent how much value you put on a candidate’s time and effort, which can easily translate to how much value you put on your employees’ time and effort. If you expect a lot of work from a candidate, can they truly believe you when you claim to have “good work-life balance” or similar? If you can’t come up with a realistic project, can they trust that the tasks they’d be given are realistic orthat the tickets they receive would be well-written?
Secondly, someone who experiences many bad tech screenings will be resistant to doing tech screenings in the future. This may directly affect you (someone who you would like to see apply once they get a bit more experience will not do so even when encouraged) or may indirectly affect you (because the industry is doing such a bad job, in general, candidates who would be great for technical jobs are instead applying to less technical ones to avoid tech screenings). As mentioned earlier, oftentimes people are trying to leave their jobs because of issues that tech screenings exasperate and therefore it would make sense for them to go for a path of less resistance.
The Alternatives
After going through these, it may be hard to imagine what could be a good tech screening — that’s because there aren’t actually good ones.
The best version of these would possibly be something like a flexible challenge project with detailed instructions that would have every candidate making basically the same project, but in their own style.
For example, candidates would be allowed to give dates and times when they could accomplish the challenge and given allowances for life getting in the way without them having to explain personal information to the interviewers to get it. They would then be given a project that is related to the actual work they’d be doing, not simply a random project but perhaps a tiny feature or bug in the real code. Because they’re doing work for the company, it should be treated as such and the candidate should be compensated for the work they do through a fixed fee (to remove the necessity of tracking hours).
However, truly the best alternative might be no project at all.
Coding is teachable and many people have the ability to do it. Being able to interact with potential co-workers throughout the interviews and showing knowledge of relevant programming concepts are arguably more important than what these tech challenges show. Despite what tech screenings emphasize, if the candidate can hold discussions about certain topics they can almost certainly do an internet search about them, and therefore be able to figure out how to accomplish them in their work.
Top comments (10)
I'm not a recruiter. I'm a tech guy. A developer, and I hope, a good mentor. When I have to select someone, I just spoke with the candidate, I'm more interested in the way he/she faces the problems, the way he/she find a suitable solution. All the other things can be taught. Clean coding, tdd, principles can be taught. Mindset, problem solving and lateral thinking and kindness are the most important values to look for
I second this! I've been hiring for tech roles based mainly on communication skills, trainability, and cultural fit for years. It's given me much better results than focusing only on tech skills ever did.
I was also quite a few time in the interviewer position. I can clearly state that what people says is much more related to their speaker skills (that may be important) but not that much to their ability to deliver and doing their day to day job.
Coding is teachable but it take time (2-3 years to be decent, 5-10 years to master) and it is not just pratice or looking on the internet. This work well for searching obvious things and solve small problems but doesn't provide the theory nor does it allows to solve reliably complex task typical of the craft. For example creating a new non trivial software from design to delivery and maintenance...
There no easy solution to me.
I've heard that some places will temp-hire folks for a tiny job as part of the interview process. Generally they give real problems to solve and the interviewee works with the existing team to solve it.
I'm curious what you think about this approach. It doesn't solve many of the accessibility/time-based issues with tech screening, but it does show that you value the time of folks you're trying to hire. It seems like it would provide a more valid assessment in the end, as well.
This exact thing contributed to my decision to quit my last job. After going through several interviews over the past few years while still employed full time, I decided to quit my job to be able to put more effort into finding a new position. It was too difficult and stressful for me to put in real effort to go through the entire process of the screenings and long on site interviews while working full time.
I know not everyone is in a position to do that, but it worked out better for me. I didn't have to duck out of work for screens and interviews. I was overall less stressed during the interview process and was able to put in all of my effort to the whole process.
There was one interview where it was told to access this online image editor (which I had never used) and start building out the mock-up. I spent so much time trying to figure out how to use the tool and set up a dev environment that I got nothing done in the hour they gave me. I was so frustrated trying to orientate myself that I didn’t even want the job.
It got even worse because I had to jump into a Redux project and pair program with the developer. “Ok so here is a bunch of code, now let’s add this feature.” So after just trying to get familiar with the code and get something working. I told the interviewer, “ I’m Just trying to get it working; then I can go back and clean it up.” In the end, I got marked down for “my coding style.”
Really interesting read! As a someone in the third year of an apprenticeship (graduating this year) it's interesting seeing what companies do for interviews when you're not operating under the assumption of no prior domain knowledge. I've got to say that a few of these could have definitely put me off :P
Discussions are insufficient to determine the level of ability a person has. I've met many people that could talk eloquently about the tech they've worked on yet fail to write the most basic code.
A big part of the intense screening programming faces is due to the large number of unqualified people seeking jobs.
Here's why whiteboarding is so unrevealing:
burdettelamar.wordpress.com/2014/0...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.