I’m not a developer, but coding interviews sound pretty grim.
You don’t have to go far to find stories of candidates fighting their way through to the interview process, only to be flummoxed by a technical question they’ve never encountered before – or are even likely to see in the real world.
In many ways, it seems like the interview process for programmers is inherently geared against them. Yes, recruiters need to make sure they’re finding the right candidates. But on the other hand, why does the process offer so many strange hoops for would-be staff to jump through?
Max Howell is acutely familiar with the problem. After failing an interview at Google in 2015, Howell shared his experience in a tongue-in-cheek Tweet that quickly went viral.
Like many self-taught developers, Howell – who is the creator of popular macOS package manager, Homebrew – doesn’t hold a computer science degree. Yet after a successful career history spanning London and the United States, he was contacted by a recruiter who wanted to put him forward for a position on Google’s software team.
“I spoke to the recruiter on the phone and I said, ‘Look, I don’t have computer science. You are aware of that. Right?’ So I went in for interview, thinking it’s going to be on the things I know, which is software engineering and software architecture,” he tells TechRepublic.
Yet upon entering the interview, it dawned on Howell that he was in for a tough ride. “I knew I was in for a whole day of not being able to do that well at anything,” he says.
“I guess I shouldn’t have believed the recruiter.”
Howell’s story is one that will be familiar to many developers who have entered a coding interview, only to find themselves faced with tasks or questions that seem unrelated to the role they’ll actually be performing.
SEE: How to build a successful developer career (free PDF) (TechRepublic)
A typical coding interview will involve presenting a candidate with a technical problem, which they’ll have to solve in real time and in front of the interviewing panel.
While these typically vary from one company to another, one common format is whiteboard coding, whereby a candidate might be asked to provide a solution to a problem involving a binary tree.
It was a binary tree task that drew the ire of Howell in his now-famous tweet. These are a fairly typical part of technical interviews, designed to assess a candidate’s ability to solve a programming problem and show their thinking ‘out loud’.
Still, most programmers say this isn’t representative of anything they’d have to do in their day-to-day job, and say it’s an outdated means of assessing candidates that doesn’t reflect their skill level.
“These little challenges don’t show the greater skill sets, which for me are the ability to construct large programs,” says Howell. “It’s not about small algorithms. It’s about the design of larger systems, and that’s way more important.”
Howell also sees traditional coding interviews as being reflective of an industry that focuses too much on building at speed. “It’s partly because the software industry moves so fast,” he says.
“There isn’t time to make things solid. But I think it’s ironic that in interviews as well, there’s a focus on, ‘can you make a store algorithm faster?’…What should be more important in my mind is, can you make code that is robust, that doesn’t crash, that doesn’t have bugs, that doesn’t fail? Nobody tests for those things.”
The bias problem
Another issue is that technical interviews aren’t standardized, meaning they can vary wildly from company to company – making it almost impossible for candidates to prepare fully. As a result, their fate rests largely in the hands of whoever is carrying out the interview on that day.
“The interviews typically are not well thought out and not structured,” says Tigran Sloyan, co-founder and CEO of assessment platform CodeSignal.
“What typically happens is, you have a developer whose job it is to evaluate this person. Most developers don’t have either practice or understanding of what it means to conduct a structured interview.”
When there’s so much variability, biases begin making their way into the process, says Sloyan. “Where there’s lack of structure, there is more bias, and what ends up happening is if whoever you’re interviewing looks like you and talks like you, you [the interviewer] start giving them more hints, you start leading them down the right paths.”
The reverse is also true, Sloyan says. “If they don’t look like you and talk like you, you might throw them a couple more curveballs, and then good luck making it through that process.”
Of course, there are completely legitimate reasons for passing on a candidate. For example, if a company uses a specific programming language, tool or development framework the candidate isn’t familiar with, they’re unlikely to be taken on, no matter how technically competent they might be in other aspects of programming.
- These are the programming languages most in-demand with companies hiring
- Hiring developers? Here’s how to keep them happy and productive
- Future developers and data scientists, check out these courses on Python, JavaScript, Apache Spark and more
- Hiring developers is going to be your next big problem
Though focusing too much on tooling also risks excluding promising candidates, Sloyan explains. “If you get too tool-specific, you’re eliminating folks who could have easily picked up whatever tool you’re working with.
“Let’s say you’re interviewing for a job as script engineer, and let’s say you’re using React in-house. If you interview me on React and I’m a very strong Angular engineer, I’ll probably fail that interview, just because I haven’t done much React.
“But if you interview me on JavaScript, I’ll probably do really well, and most strong JavaScript engineers that are good at one of those frameworks can pick up the other with no problem.”
Don’t focus on the code
It certainly seems that, too often in interviews, the emphasis is on what candidates know, as opposed to how they approach problems and their potential to learn.
Frank Moley, senior technical manager at DataStax, says he banned live coding from his team’s interview process because it didn’t deliver any value on either side.
Instead, DataStax now runs timed projects, in which a candidate is set a task and then presents what they’ve put together to the interviewer.
“We still want to see what someone knows right now, but ideally we want to see how you think about things and how you explain your decisions,” Moley tells TechRepublic.
“Alongside this, we concentrate on code review and how people respond to and give feedback. This kind of conversation is what you will spend more time on and where you can have the most potential to improve things, but it often gets ignored at the expense of just looking at code.”
By getting this peer-reviewed approach into the interview process, both sides can benefit, Moley explains: “As an interviewer, I can see how you think and how open you are to change and learning about things. As an interviewee, you can see how the company and the team approach this, as this will be something that you will potentially be part of.”
As to how companies might be able to re-think the interview process, there doesn’t seem to be a clear-cut answer. Sloyan thinks the process needs to start at the resume level, with candidates submitting data-based reports based on standardized coding assessments, which hiring managers can use to determine an individual’s skill level.
SEE: Hiring kit: Python developer (TechRepublic Premium)
“When you go to the interview, having this data-driven report about the candidate that you’re working with versus the resume [alone] prevents the sort of first two-minutes bias that’s there when you start off with a resume,” he says.
Howell isn’t sure there is a straightforward solution. “I honestly don’t know if it’s a problem that is solvable – to be able to accurately identify whether or not this person fits your job requirements or not,” he says.
Howell’s long since made his peace with Google. He received an influx of job offers following his now-famous tweet, which he says he sent in the heat of the moment and looks back on regretfully.
“I only had maybe 1,000 followers on Twitter, if that. Most of the time, no one cared what I said, so I just assumed it would be the same as usual,” he says.
He has sympathy for those on the recruiting end, too. “I know interviewing is hard; to figure out if someone is a good fit and knows what they need to do or not in a few hours…You need metrics. An easy way to do that is to give them these little puzzles, little programming challenges that you put up on the board. You need ones that are objective, not subjective.”
Though he does think this objectivity can be an impediment in some situations. “The problem with the skill that I think is more important, the skill that is vastly more important for modern software development – engineering and architecture – is it’s subjective. It’s very difficult to objectively score that,” he says.
“The way I generally interview people nowadays and make choices is, I look at their GitHub. I see what they’ve been doing over time. I think that speaks to your ability to create, which is important. That’s what you do as a software engineer. Even if you’ve just submitted some patches here and there, to be able to see how you work – that’s valuable.”
SEE: How to ace a technical interview: Advice for software developers looking for a new job (TechRepublic)
The problem is that, for the most part, coding interviews remain much the same. While platforms like CodinGame and HackerRank offer more accessible means of training and assessing candidates, technical interviews and real-time coding still play a central role in the hiring process. This means the emphasis is on coding itself, rather than problem-solving.
“Inertia is hard to change. Once the industry gets used to something as a way of going about selection, it just carries over from generation to generation,” says Sloyan, who suggests that many software companies still base their interviews on methods used by Silicon Valley firms in the mid-2000s, which were highly theoretical.
“The industry still thinks in this old-school mindset,” he adds.
For Google’s part, the company no longer asks ‘brainteasers’ as part of its coding interviews. The company’s hiring information suggests the company learned such questions were a poor indicator of how well someone would do on the job, and so scrapped them for good.
Moley suggests that companies spend more time thinking about both the interview process and the person they want to bring into the fold – specifically, whether they’re looking for someone simply to plug a skills gap on the team, or someone they want to develop and grow over time.
“Answering that question can help you see how your process works with new hires, and where you can make improvements. Ideally, you should be looking out for people that you can mentor and help over time,” says Moley.
“It’s all too easy for interviewers to concentrate on specific skills and whether people have them right now. Instead, the focus should be on how the interviewee learns and applies new approaches to solving problems. If you don’t look for that, you end up shackling developers to specific technologies that don’t keep pace with things.”
