Get Professional

Coding Interviews – What Employers Really Want to Know

25 Aug , 2017  

Coding Interview What Employers Really Want to KnowCoding 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?

What the interviewer wants to know about you

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.

Weird thing that happen in technical interviews

So let’s talk about this weird stuff.

Testing knowledge you’ll probably never use in your work

Do you know how disappointed I was to discover that I wouldn’t be performing Big-O analyses and implementing linked-list merge sorts when I got my first job?

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.

Whiteboard programming

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.

Doing your test at home

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.

You are more than your code

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):

  • Why are you interested in this position? – Are you genuinely interested in us, or are we just another job you randomly applied for?
  • Where do you want to be in five years? – Do your ambitions (if you have any!) fit with our plan for this position?
  • Why are you leaving your current position? – Because you want to grow, or did you somehow create an intolerable situation for yourself?
  • Tell us about a time you had to deal with conflict at work. How did you resolve it? – Can you see the other side of an argument? Are you capable of sensitive communication? Can you be persuaded?
  • How have you invested in your growth in the past? In what areas do you need to grow more? – Are you someone who’s interested in professional improvement? Are you sufficiently aware of yourself and the industry to know where you need improvement?
  • Tell us about a time when you had more work than you could handle. What did you do about it? Can you set priorities and manage expectations?

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.

The Final Question

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.

That’s it.

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


Leave a Reply

Your email address will not be published. Required fields are marked *