Hiring the best talent is key to a great business. Here’s why you should not rely solely on coding interviews when hiring; instead, consider speaking more to candidates.

Introduction

Over recent years, the hiring focus has changed from looking and chatting with candidates to a process designed to quickly deal with as many people as possible.

I feel that coding interviews are now done verbatim without knowing their purpose.

They are often run like the coding equivalent of an ambush. Candidates are suddenly given an unfamiliar topic and told to code it immediately without research or the ability to rely on their normal processes or tools.

If you were devising a way to get the best out of someone, would you choose that?
But somehow, this has become the norm for coding interviews.

In my opinion, a more upfront screening followed by a technical chat will give you a much better view of the person.

Please Know That

Me coding in front of you for the next hour will not

  • Show you whether I am a good coder or not.
    My public code, work history and recommendations are all better indicators.
  • Show how I do my day-to-day work.
    I always prepare before coding; I would never jump in.
    I would generally use Google or AI to help with the small details.
  • Give you an idea of how I solve problems.
    Why would you think that?
  • Show my true personality.
    It’s not likely when I am nervous and must focus entirely on coding.
  • Show That I am comfortable pairing
    Everyone is comfortable pairing with the right partner.
    Watching me work my way through an exercise is not pairing.

Wouldn’t It Be Better

For you to spend the next hour speaking to me and you will know

  • If I am the right person to drive your project into production.
  • If I will focus on the bigger picture and catch what other people might miss.
  • How I support and mentor my teams
  • If I can calmly overcome project issues and keep moving forward.
  • How comfortable I am talking to and building rapport with stakeholders.
  • Whether I am comfortable doing architecture and complex low-level design.
  • If I am more of a big-picture thinker or someone who lives in the weeds.
  • Whether I am comfortable presenting my team’s work.
  • How comfortable I am defining and refining tickets if needed to drive them.
  • How I feel about code quality and how I ensure it’s built in from the start
  • How I build tests at multiple levels to make sure the system is tested properly
  • What I think about full cycle development and supporting systems in prod.
  • The work you are looking for me to do is a good match.
  • How I would solve a problem you are trying to solve.
  • Whether I like to tackle the big problems first or last.
  • What I think about Microservices vs Monoliths.
  • What branching patterns I tend to use.
  • How I approach complex problems
  • What I think about frameworks vs. coding things myself?
  • What I think about clean code, SOLID et al.
  • Whether I like DevOps as well as coding?
  • Whether I prefer NoSQL or SQL?
  • ..

Or anything else you want to know.

You’ll learn much more about me, my skills, and my personality during this time.

The Choice is yours

So before you decide to let me loose on your project, ask yourself this.

Is it more important that I can

  • Code an unfamiliar problem in a pressured and unfamiliar setting.
    Remember low-level coding syntax
    or
  • Build your system in the best way possible after considering all the options.
    Fix your production outage under pressure.
    Have the right temperament to support the delivery of your project.
    See the bigger picture and catch what other people might miss.
    Dive into the low-level detail whenever needed.

If You Must

If you’re sure that a coding interview is the best way for you to go, you can do a few things to get the best out of your candidates.

  • Chat a bit first and put them at ease.
    Don’t just throw a problem at them – that doesn’t happen in the workplace.
    Be human about this – explain that the process is not to catch them out, and you want them to do well.
  • Consider Letting Them Know The Problem In Advance
    This takes the effort away from understanding the context.
    It lets them concentrate on showing you how they work.
  • Consider Letting Them Present Their Own Work
    A candidate can give you a walkthrough of something they’ve done.
    You can always ask them to make additional changes.
    Many places do this by giving a coding challenge that they present.

Wrap Up

Just to be clear, I love coding. I wouldn’t be doing this job at my age if I didn’t.
So I expect people to be able to code, including architects 🙂

But the more I think about coding interviews and how they are conducted, the more I see that they’re not fit for purpose when trying to gauge someone’s ability.

There will always be a place for coding interviews, but you must carefully consider how vital they are, how they are done and where they should be placed in your hiring process. Putting them at the front makes them a blunt tool that will lose good people.

I still think an hour of talking to someone less formally will yield the best results. Making them feel at ease and listening to what they have done in practice will likely tell you all you need to know.

What’s that old saying about two ears and one mouth …..