The software developer interview conundrum - Part 3

G’day Internet

This one took its time to come out, but recently writing has been back on my mind. I have also been interviewing some developers (not so) recently (anymore) and remembered that I owed the internet (and myself) this third and I believe (haha) last article about the software developer interview conundrum.

In those two years the world of hiring has changed quite a bit. VS Code is dead (says the guy who is typing that in VS Code), AI is now the editor, in our take home tests, and sometimes in the interview itself. That needs to be its own article, so here is my new promise: Part 4, Hiring in the era of AI, will be released within the next two years (so Part 3 is, I believe, no longer the last article). People who worked and work with me can attest that this is probably the safest estimate I have ever given.

That said, I am pretty confident the following is helpful even in this brand new world.

Here are all the related articles:

Throughout the article I will sometimes leave notes for candidates being interviewed.

The Dos and Don’ts of software interviews

As a preamble, a gentle reminder that an interview is (or at least should be) both ways. You are interviewing the candidates as much as they are interviewing you.

Interviewee: you must use an interview as a means to figure out whether the company is a fit for you. An interview is never only about the company getting to know you.

I have organised the dos and don’ts the way a candidate lives them: before, during and after the interview.

Before the interview

Do: design your process before the job ad goes out

Respect the candidate throughout the interview process.

This starts before you even get a resume. Prepare the interview process before you even start putting job ads out.

  • Why do we interview in the first place?
  • How many interviews in the process?
  • What does each interview look like?
  • Who interviews when?
  • Define a maximum time for the process, the shorter the better, don’t let it drag over many weeks/months

In general, once an interview process is started, stick to that process until you have filled the position. Candidates need to be treated equally.

Do: review resumes in a timely manner

Now your job ad is out, you start receiving resumes. Don’t let them linger in your inbox, review them in a timely manner. While reviewing, make sure that the person matches what you are looking for. The goal here is to avoid wasting anyone’s time.

Don’t: falsely advertise your interview style

Don’t advertise an interview as a pairing session when it is just a disguised coding interview.

The same goes for every other type of interview. If the candidate prepared for a chat about their experience and gets a leetcode problem thrown at them, you have not assessed their skills. You have assessed how well they handle an ambush. And trust me, they will remember it.

Interviewee: ask what each interview looks like. More often than not the talent acquisition person wants you to succeed and will happily tell you.

Don’t: lie about take home test length

Don’t say your take home test takes two hours when it needs a weekend to complete. Candidates want to show their best side and will spend the time to do so. Even if you tell them to do it in two hours, they’ll spend more time.

Cater for this: if you say something takes two hours, it’s because everyone in your team took just one hour to complete it.

Do: come prepared to the interview

They have done a take home? Review it thoroughly before the interview. They’ve spent the time doing it, you owe them the time reviewing it. Respect, remember?

Before the interview, have another look at their resume, to avoid asking questions that are already answered.

During the interview

Don’t: be late to the interview

The candidate has most likely joined five minutes early, checked their microphone three times and has been staring at “Waiting for the host to start this meeting” ever since. Every minute you are late is a minute of extra stress for them, and a minute taken out of their interview.

Seriously, don’t.

Do: put the candidate at ease

This starts before the interview, by letting them know what is expected of them.

  • Explain the interview structure
  • Tell them what they are and what they are not allowed to do during the interview. Can they google? Can they use AI? (editor’s note, this was added recently). Let it be known to avoid misunderstandings

At the start of the interview, reiterate those points before moving on.

And when you say they can google, mean it. And show it. As I said in part 2, the first time they are stuck on something you don’t know either, google it yourself and tell them you just did.

If it is a pair programming session, actually pair. Help them when they struggle, build some momentum so that they forget they are in an interview.

Don’t: force a coding environment

Don’t make them code in a code sandbox or an environment they are not used to.

But Jon, they will have intellisense! Yeah, they will when they work also. (This one aged amazingly well. Keeping it regardless. Sue me)

One caveat here, I would still ask anyone to turn off their AI helpers during a live coding session. AI helpers write the code for you, sometimes a substantial amount of it, so it becomes difficult for me to assess if the person knows how to write proper code without an AI helper. Last time I interviewed I also allowed AI tools so…

Don’t: throw curve balls

I know that some companies do this. I understand that it helps figure out how people react when they are under pressure.

What it does not take into account is the pressure they are already under. For most people, the interview itself is the curve ball. As an interviewer, the current pressure is something that you need to gauge before throwing another one.

Don’t: ask non-relevant questions

Most of what we will discuss in this point revolves around keeping the interview relevant to your needs.

I’ll start with what I think is the absolute worst. Don’t ask brain teasers. Why not? They are simply not relevant to the job. You might miss out on a very good developer because they could not answer a puzzle. I would push it even further, you could exclude full groups of people with your brain teasers. People with ADHD, autism or dyslexia might excel as much as they might struggle with brain teasers. So please, if you are still using brain teasers in your interview process, stop doing it.

Also don’t ask questions about how a software or a framework works under the hood. While I personally find it interesting to know how the tools I use work, it is not necessary to make you good at using them. Woodworkers don’t need to know how their bandsaws are built. So why should a React developer know how React is built? Unless of course you hire someone to work on the React codebase!

No one in your company has ever inverted a binary tree in production code? Don’t ask the candidate to invert a binary tree. Keep the interview focused on what matters for the position.

Don’t: ask candidates to do actual work

Don’t ask candidates to work on an actual production issue, whatever the type of interview you are doing.

That is not an interview, that is free consulting. The candidate is giving you their time, not their labour. On top of that, they don’t have the context your team has, so you are not even assessing them fairly.

If your take home test looks suspiciously like the ticket at the top of your backlog, it probably is one. Pay a contractor.

Don’t: let the interview go over

You booked an hour? Finish in an hour.

The candidate might have another interview straight after, kids to pick up, or they might have told their current manager they had a dentist appointment. Running over also tells them a lot about how your meetings are run.

If you keep running out of time, the problem is your interview design, not the candidate. Cut something out of the interview, don’t extend it.

Do: leave room for questions

I’ve said this before. An interview goes both ways, you are interviewing as much as you are being interviewed. The candidate should walk away from the interview with a pretty clear idea of how the company and team operate, as well as knowing whether they are a good fit.

Keep the last ten minutes (at least, 15 even better) for their questions. And yes, this is another reason not to let the interview go over.

Interviewee: if they leave you no time for questions, that is an answer in itself.

Do: be honest in your answers

There is nothing worse than promoting a lie to get someone to sign. They will realise you were lying in the first few days and leave the company.

I once unwillingly lied and hired someone as a technical lead. At the time I was supposed to transition to an official engineering manager position, a role I was already doing, leading two teams. That transition was cancelled a week after hiring the tech lead. That tech lead was given four people to manage, when he had clearly told us that he did not want to manage people. He ended up leaving the company three weeks later.

After the interview

Do: give feedback, and give it early

Interviewees offer you their time to go through your interview process. They deserve feedback and deserve it early. You’ve been there and you’ve complained about it. Don’t be that person you complained about.

Oh, and “We’ve decided to go with another candidate at this time” is not feedback. Always give areas of improvement to the candidate.

Good feedback is prompt, specific and sincere. I know first hand how useful it can be: the feedback I received after failing a culture fit interview is the reason this post exists.

Don’t: ghost candidates

Don’t ghost candidates after they interviewed with you. Even a “no” is better than silence. Silence is not a no, it’s a candidate refreshing their inbox for three weeks.

If you realise that a mistake happened in the process and you ghosted them as a result, send an apology.

Do: have a swift process

In part 2 I said I aim for 10 days for the right candidate. Two years on I keep my stance. Maybe it could be a tad faster.

Every extra week is a week where the candidate keeps interviewing elsewhere, and good developers don’t stay on the market for long. Swift does not mean rushed though. It means no two-week gaps between interviews, and a decision within a day or two of the last one.

Do: make an offer for the right fit

Truth: I was not sure about the title for this one. I’ll keep it simple though.

You’ve interviewed someone. They are great, they tick all the right boxes:

Rule 1: MAKE THE OFFER Rule 2: Make sure to follow rule 1.

Alternatively, you could keep chasing unicorns.

The cheat sheet

For the skimmers (I see you):

  • Before: design your process first, review resumes quickly, advertise your interviews honestly, be honest about take home length, come prepared.
  • During: be on time, put the candidate at ease, let them use their own environment, no curve balls, no brain teasers, no free work, finish on time, leave room for questions, be honest.
  • After: give real feedback early, never ghost, keep it swift, and when it’s the right fit, make the offer.

See you in Part 4, in two years or less!

That’s all folks!

Jon