Coding interviews have an interesting reputation – apparently nobody knows how to do them right.
Common complaints about coding interviews include: trick questions, whiteboard programming, excessive and unpaid programming “homework” and “bad” questions (“so what is your biggest flaw?”).
Nonetheless, if you’re after a position as a developer, you’re going to have to sit some interviews.
I’ve covered seeking freelance positions before, but the coding interview has a very different purpose.
This is where an employer makes a decision about you that they’ll have to live with for years.
Even if they’re “wrong”, coding interviews are the best thing we have for hiring developers.
So what’s the purpose of the coding interview, and what do employers hope to get out of them?
There are two main things an employer wants to know about you – what you can do, and who you are.
The what you can do part is all about finding out how you code – how well you do it, how you approach problem solving, how much technical knowledge you have.
This is the most obvious part of the code interview.
The less obvious part of the code interview – who you are – is all about finding out if you’re the kind of person your potential employer wants cluttering up the office for 2000 hours a year*.
Even though you’d expect the technical part of the interview to be straight-forward, there’s still plenty about it that doesn’t seem to make sense.
So let’s talk about this weird stuff.
That’s what my studies had prepared me for, anyway.
So why on earth do we get tested for it?
It’s because answering questions like this is the best way you can prove you’ve invested a significant amount of time learning about programming.
Degrees, personal projects and personal references can all be misleading or just faked. Implementing a complex algorithm in code, in person, shows you can do something, at least.
Where do you think you’ll be implementing your fancy algorithm – on a computer with an internet connection?
If you’re lucky.
A very common alternative is doing the coding on a whiteboard. No editor, no Google or StackOverflow.
On the face of it this seems insane – no one works like this right?
But I think the whiteboard can be great – if it’s done right.
It can be an opportunity for you and your interviewers to solve a problem together, with you leading the way.
Because collaborative problem solving is something that happens a lot in professional life.
This is where you can show how you solve problems, how well you can communicate your understanding of the problem and your solutions, and how comfortable you are with taking on other people’s ideas.
So that’s why whiteboard interviews aren’t necessarily as bad as everyone says.
In violent reaction to the whiteboard interview, companies have started giving candidates take-home tests instead.
This is where you, job seeker, get to work on a real-life problem in the comfort of your own home. These kind of problems may include adding new features to an existing application, building a new application from scratch, or dealing with a few issues posted to a github project.
Once you’ve done your homework, you and your interviewer will go over your work, discuss commits, tests, and your implementation.
The great thing about this is that you’ll get to perform in your ‘natural setting’ and show your interviewers what you can really do.
A common downside is that take-home work that’s described as ‘a few hours’ takes up to 20 hours to complete!
This is a big time investment for a busy job seeker. On the plus side, a few forward-thinking companies have started paying job-seekers for the time they work on these projects.
Here’s an interesting fact – you can be the best coder in the world, but still not get hired.
Because – since you’re an investment – you’ve got to provide value over time. And programmers who can’t improve, communicate, cooperate or get along with colleagues who disagree with them, aren’t an investment.
Instead, they become a liability and can drag down the performance of a whole team.
So there’s going to be a series of questions that aim to find out who you are and where you’re going.
That’s a lot to expect from a few hours of interviewing, but once again, this is the best the industry has available to it right now.
These are the kinds of questions you can expect (and what they really mean):
And of course you’ll be asked about how much you’d like to earn – a whole minefield on its own!
Of course, no interview should be a one-way street.
Employers will read a lot into the questions you ask during an interview. These should include questions about the role, the team you’d work with, where the company is going, and what would be expected of you within the first 60 – 120 days of starting the position.
Are you prepared?
Regardless of the interview style and techniques employed by the company you interview at, just remember they’re interested in finding out two things:
What you can do, and;
Who you are.
“What you can do” will be evaluated with a series of questions or exercises that’ll test your technical knowledge and problem solving skills. And they’ll try to get a handle on who you are by asking about your ambitions, how you manage difficult discussions and what you’ve done in the past to grow as a developer.