The process of hiring people for technical roles is as broken as it is important, and the much-criticised coding interview is a key part of the problem.
Developer Sahat Yalkabov illustrated this in no uncertain terms in a Medium post last year. So bad was his experience he decided to stop looking for a job altogether. This from a man with some household name tech brands on his CV – hardly someone you’d expect to be struggling for work.
Entrepreneur Eric Elliot went one step further to suggest tech hiring has always been broken. hand not fixing it, he said, could have a detrimental impact on the industry’s future. “Poor hiring practices aren’t simply bad for the company doing the hiring,” he said, “but the whole community.”
Why it needs to be fixed
The coding interview is arguably one of the biggest problems in tech hiring. Engineers are forced to jump through any number of hoops, and those hoops generally aren’t mapped to what they’ll be doing day-to-day and so give little indication of their ability.
In my experience, most companies don’t think hard enough about how to measure technical skill, so they simply rely on what’s gone before. This perpetuates bad practices and gives an unfair advantage to those who are good at a particular type of interview.
As one commenter in a Hacker News post put it, “Being a good programmer has a surprisingly small role in passing programming interviews.” A bold statement, perhaps, but it’s easy to see why the process leaves a bad taste in many candidates’ mouths when you consider some of the practices accepted as normal.
The idea that programmers should have to write code on a whiteboard on demand, for example, is absurd. No human brain can properly parse, interpret, pile and run code as quickly or accurately as a machine can.
There’s a reason people code on computers, and that’s exactly what they should be using in an interview. That said, it’s not for a lack of trying that companies haven’t managed to get this right. Brands like Facebook have already thrown a huge amount of time and effort at the problem, which illustrates just how difficult it is to solve.
And you have to ask people something. Coming up with an interview process is tough. It could be a full-time job. Most companies – particularly start-ups – don’t have the time or resources to dedicate to it. So it’s easier to fall back on formulaic tests that focus on what people have memorised rather than what they’ve done.
Those exercises might work when you’re assessing someone fresh out of university with no work experience, but if you apply them to people who do have experience you’re unlikely to be testing for relevant skills. You also risk missing out on brilliant candidates who come from different backgrounds.
Some of Hired’s best programmers didn’t come through higher education, and there’s nothing wrong with that. In fact, according to Hired’s Mind the Gap report, more than a quarter (26%) of UK developers have no university degree. But what they have in their memory will be different to someone who’s done a four-year degree course.
Put those two people through the same whiteboard test and it’s likely the university graduate – with four years spent memorising information to pass exams – will outperform the other, but that doesn’t mean they’re likely to perform any better or worse in the role you’re hiring them for. It’s a fundamentally biased way of testing people, and could mean inadvertently turning away the better candidate.
A better way to interview coders
Think about what actually matters in terms of a person’s ability to do their job. I don’t mean whether they’re a great programmer generally, or how much coding knowledge they have, but rather their ability to do the specific job you’re trying to fill.
Mimicking the real job of a coder in an interview is enormously difficult, however, particularly when it comes to achieving context. Even in a relatively new codebase it can take months for a programmer to gain sufficient context to be able to contribute at a decent pace.
In the past employers have tried to cater for this in their own interview process by having candidates work with a much smaller sample codebase. But companies like Hired have learned even a few hundred lines of code across a handful of files can be overwhelming for a one-hour session. As a result, it is necessary to keep the tasks quite simple, meaning good candidates didn’t have the chance to properly shine.
One way to overcome this is taking that same concept of a smaller codebase but sending it to candidates ahead of time. This way they wouldn’t have to build context in the moment and you could make the interview much more complex, which should allow you to better differentiate strong candidates.
And as with anything in business, learning and improving is a hugely important part of the process. Hiring should be a two-way street, during which you gain as much feedback from candidates as you give them. This is not only hugely important for your employer brand (it shows you actually care about the candidate experience), but also helps you understand what you could do better and take action accordingly.
Nobody has a silver bullet to fix the coding interview, and this certainly won’t be the last article written about it. But if enough of the big players start moving in the right direction it’s fair to assume others will follow. Then, at least, we might see fewer people talking about this in future.
Sourced by Nidhi Gupta, SVP of Engineering, Hired
The UK’s largest conference for tech leadership, Tech Leaders Summit, returns on 14 September with 40+ top execs signed up to speak about the challenges and opportunities surrounding the most disruptive innovations facing the enterprise today. Secure your place at this prestigious summit by registering here