Tech Interviews – An Interviewer’s Perspective

Note this post is written from the perspective of a software developer hiring other software developers. I imagine a manager hiring a software developer will have a different perspective.

The more interviewing of developers that I do the more it opens my eyes to how an interview impacts the interviewer, and I wanted to share here.

The Interviewer Desperately Wants to Hire Someone

Something that interviewees often don’t realise is that in most cases your interviewer wants to be done with the current round of interviews as soon as possible. They want nothing more than for the person sat in front of them to be The One, because it will get them back to doing their actual job.

The person interviewing is probably super busy as there are only two logical reasons for hiring:

  1. The developers have too much work (and depending on the company the “too much work” threshold could be really high).
  2. One of the developers is leaving or has already left (and this could potentially be because of issues caused by being overworked).

If it is 1) then you’ve probably prepared for the interview more than they have. You only have to attend one interview, they have to attend many. Until I started interviewing I didn’t appreciate this enough. There is a decent chance that your interviewer hasn’t prepared at all and is just dusting off an old set of questions.

If it is 2) then they are probably demoralised and trying hard not to show it. They will certainly be trying hard not to show how busy they are, otherwise you are going to reject the job or demand a salary that puts you out of reach.

Interviewing Is More Time Consuming Than the Candidate May Realise

When you’re on the other side of the fence you can fail to realise that recruiting is a very time-consuming process.

  • Calls with recruiters (very talkative people who are hard to get off the phone, and are likely to call often).
  • Preparation for the interview. Even if an interview is only going to take an hour, paperwork must be printed off, laptops must be prepared for code tests, and interviewers will have to wait around for the candidate to arrive. This distracts from real work.
  • Debriefing. Good notes are necessary if you are going to be able to properly review an interview and make the best decision. These take time, unless you’ve written the bulk of them during the interview (even if you have they are likely to need summarising for management).

The Interviewer’s Manager

As well as the interviewer’s own wish to get back to productive work, there is also likely to be a manager wanting the interviewer to find a candidate as quickly as possible for the same reason. If someone is leaving they want to be able to tell their own boss ASAP that everything is back under control.

This can lead to varying levels of desperation on behalf of the interviewer depending on how long the round of interviews have been underway.

The Candidate

If you have an active Stack Overflow or GitHub account you will not only be ahead of the other candidates, but the interviewer will love you as you are making their life much easier. Seriously, even a shitty project you threw together on a Saturday afternoon is better than a gaping void.

This could backfire if the interviewer sees something atypical (or out of date) in your project that they don’t like, but I still think that any code is better than no code. A complete lack of an online presence for a developer is slightly suspicious and could stop you from even being invited to an interview.

If your online presence leaves you in a positive light there is a good chance it will cut the time required for the interview, and this is positive for all involved.

When Being Interviewed, Consider the Interviewers

So when attending technical interviews in future, enter the interview understanding that the interviewer really wants to hire you. Be respectful of their time, as they are likely to not have much of it.

Leave a comment

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