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.

Avoiding distractions as a programmer

Distractions are kryptonite for programmers. They should be avoided at all costs. Reducing your distractions is key to productive software development. As a programmer you should be aiming to spend as much time as possible in a state of uninterrupted flow.

Distractions lead to insecurity

As you become more senior in your career you may think that you have become less of a programmer, that you lack skills you had earlier in your career. What is more likely to be the case is that you simply have far more distractions.

We all remember how we were during the first few weeks of a new job, when our email inbox was empty, nobody walked over to ask us questions, there were no random IMs popping up, and no urgent escalations.

It’s simply a fact that more time you spend in a particular position at a single company, the more knowledge you will acquire and the more people within the company will consult you to share that knowledge.

It’s very easy to fall into the trap of responding to all requests for time as they come in, this is fine for the people requesting your time, but it is terrible for you, and ultimately your employer.

Permission to waste time

Distractions occur when you allow yourself to permission to waste time. This happens when you aren’t clear on the work that you should be focussing on at a given moment, the moment an interruption or distraction comes in.

The Pomodoro Technique can take away this permission to waste time. During a 25 minute pomodoro all interruptions and distractions should be deferred, and it is clear what work is being focussed on. Very few distractions are so important that they can’t wait until the pomodoro is complete.

Permission to relax

The Pomodoro Technique also gives us permission to stop working, because there has to be a short break between every pomodoro. This gives time to review the work that has been completed, so that planning changes can be made. Loss of focus is prevented with these regular breaks.

It’s recommended that you actually leave your desk for this kind of relaxation, and at least leave your keyboard, because your brain doesn’t really rest fully while left staring at your computer screen.

Logging time to identify time sinks

I’ve been using kanbanflow.com to start the day with a plan of what I will be working on (including all meetings and conference calls that I have scheduled) and then it is clear to me that I don’t have permission to waste any time if I want to achieve what I have committed to.

When you actually see in advance how many calls you are attending it becomes clear how much time is going to be lost to them, and you can make an informed decision about which ones you really should be ducking out of.

Kanbanflow also logs where my time was spent so that I can review how I’m spending my time and adjust to deal with any areas of work that I’m neglecting. In the past I’ve gone for long periods knowing that I’m wasting time, but not being specific about what I was wasting it on.

Making time for work that is important but not urgent

If we’re not constantly following distractions, then we can make time for work that will improve our productivity, but isn’t required urgently and therefore typically doesn’t get done. These are what productivity author Steven Covey referred to as Quadrant 2 Activities.

These tasks are key to really improving out productivity, and they are so easy to leave out if we aren’t in control of what we’re working on each day.

In summary

Giving yourself permission to ignore distractions is key to being productive. Use the Pomodoro Technique to defer distractions until you are finished with the task that you are currently working on.