DEV Community

loading...
Cover image for Tech Screenings: Why The Interview Process Fails Candidates

Tech Screenings: Why The Interview Process Fails Candidates

techevangelista profile image Lindsey Originally published at Medium on ・9 min read

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.

Discussion (10)

pic
Editor guide
Collapse
sergiopicciau profile image
Sergio Picciau • Edited

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

Collapse
dmerand profile image
Donald Merand

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.

Collapse
bousquetn profile image
Nicolas Bousquet

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.

Collapse
dmerand profile image
Donald Merand

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.

Collapse
holman_dw profile image
Dustin Holman

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.

Collapse
thecodegoddess profile image
TheCodeGoddess

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

Collapse
jsjlewis96 profile image
Jake Lewis

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

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
burdettelamar profile image
Collapse
davenicolette profile image
Dave Nicolette ن ✡ ☽ • Edited

It's true that programming is teachable, but not every organization is in a position to hire only junior programmers. The methods of screening may vary according to the needs of the organization.

Example 1: I was working with an XP team in a small company. The way they hired developers was that the team with the opening had the final word. They screened candidates by bringing them in, having the sign an NDA, paying them for their time, and having them pair in with two or three team members during a regular work day. If they meshed well with the team and had the requisite skills, the team would accept them. Managers and HR did not impose anyone on the teams.

Example 2: I'm working for a consultancy now that offers technical coaching as part of agile transformation assistance. When we're hiring, we have to have people who are simultaneously (a) multi-skilled, (b) high skilled in one or two areas such as programming, testing, or devops, and (c) experienced with coaching, which is an entirely different skillset from programming. We use challenge exercises that are agreed upon in advance by the candidates, and there's no time limit. We aren't so interested in their end result as in their thought process and approach. Whether they have the same approach as we do or not, it's important that they can explain and defend their rationale. Depending on that result, we'll have a live pairing/mobbing session with them. This company has no work for a junior person who is "teachable." It isn't because we wouldn't like to be in a position where we had lots of that sort of work, but at the moment we just don't.

Example 3: I applied for a contracting position with a large-ish company, and they asked me to do a coding exercise. (It was actually Dave Thomas' kata #14 about trigrams; a nice one!) The screener went into great depth with me and wanted to explore alternative solutions and extend the parameters of the exercise. He was very enthusiastic. When I got on the ground there, I learned that none of their development teams ever, ever, ever did anything remotely as interesting or challenging as the screening exercise. I think sometimes people get a bit carried away with these exercises, and they aren't aligned with the realities of the workplace.

I'd like to comment on the question of time and respect. In a normal work week, a normal person will put in a normal level of effort on their day job and devote a reasonable amount of time to family, friends, hobbies, and probably spend at least a couple of hours on professional development. When the same person is looking for a new job, I think it's fair to expect them to set priorities and manage their time accordingly. I see it not only as professionalism, but basic adulting as well.

I will disagree that a person who "has time" to do a coding exercise must be happy where they are and have plenty of time to spare. If they're so happy, why are they looking for a new job? And if they're serious about finding a new job, why can't they delay gratification long enough to invest some time and effort in the job search?

Something I've noticed for many years, unfortunately, is that many people in our industry significantly exaggerate their skills and experience on their resume and in verbal interviews. That's the main reason why so many companies that are looking for people have to ask candidates to show what they can do, and not just talk about it. You can learn more in five minutes of pairing with someone than you could learn by spending two hours trying to parse their well-rehearsed buzzword-laden speeches. Talk about respecting people's time...how about the team members who have to take time out from their work to meet with the candidate? Isn't their time worth something, too?

That said, some of the methods people use to screen candidates are pretty much a waste of time, IMO. One of them is the in-depth technical phone interview. If you try to design a complicated system verbally over the phone, what are the chances everyone will even keep track of what's been said? Another is the coding challenge that's the same for every candidate regardless of their skillsets and interests. In our company we tailor that to each candidate. There's no time limit. They can ask all the clarifying questions they want. We want to see their strengths, and we aren't interested in tripping them up. Of course we want to know where their strengths trail off, too, but that isn't for purposes of rejecting them; it's for purposes of understanding which client engagements they're likely to thrive in.