Introduction

Most companies run a multi-stage interview process. There are multiple ask’s in each stage, requiring significant time from a candidate. For example, take-home assignments that take “four hours”, four hours if the candidate knows every one of the moving parts in the take-home tests. If the candidate does not need a refresher on a language they have not touched in a few years. If the candidate understands the problem. If they have undivided attention and have the time, they could be in at least two or three other interview processes.

After discussing with friends, they have all run into similar problems. The lengthy interview process, sometimes never-ending, puts people off applying for a job.

The Goal

The goal of an interview is to hire someone. Increase the probability of success by communicating to the candidate what will help them succeed with your company before the interview process begins. A levelling document could help here. A levelling document tells applicants what precisely you are looking for in an engineer from different rubrics. Communication, Impact, Leadership and technical are standard. Don’t have one? Get one from Progression that speaks to you.

After communicating to them the signals the interviewer is looking for, The interviewer wants to see if the candidate are a good fit for the company, If they are qualified to do the work, and possibly something that interviewers have forgotten if the candidate wants to work in the company. So begins the interview process.

The Process

Here is a way to interview.

• The total duration should be about two hours
• There should be a demonstration of whether the candidate can code and build systems
• The candidate should be given as much time to ask questions about the company as they want. even if it goes above two hours
• Feedback on an interview should be less than forty-eight hours

Who should do the interview?

They should meet whoever is on the team they may be working on and the manager of that team.

The format of the interview

Split the interview into two parts, up to thirty minutes of getting to know the candidate and up to ninety minutes of talking about coding and day to day work. Each part of the interview should have a clear description of what signal the interviewer is looking for. Communicate what the candidate needs to demonstrate.

Examples of signals I like.

• Can the candidate communicate something to you? They will be disseminating information to people in the company daily, so they should be good at communicating
• Do they take feedback? can the interviewer provide a differing viewpoint in a conversation, and the candidate runs with it
• Do they listen to the question that was asked or the one they wanted to be asked?

The Getting to know you interview

This part of the interview is to see if you will fit in on the team. In reality, the entire process is to see if you fit in, but especially in this interview as interviewers focus on behavioural questions. IMO interviewers should spend this time getting to know them as much as possible as human beings. Interviewers should try and provide a safe space to let them be them. If everyone was honest about who they are and what motivates them, staff tenure could be longer in companies.

The Technical interview

So the need is that you want to know if someone can code. Most companies do a pair programming test, or as mentioned above, a take-home test. My version of this is slightly different as not everyone has the time for a take-home test or freeze in pair programming tests.

Provide a menu for the technical interview. First, ask the candidate the question, “How do you want to demonstrate to us if you can code and design systems?” as this is not often asked, you can provide the following options to kick start the conversation

• Pair programming using a tool like a Hackerrank or Leetcode in the language they are most comfortable with. It does not need to be in a language the company operates. If the interviewer does not know the language, it allows them to learn a new language
• Bring your project to the interview, The interviewer can ask for a change, and we make the change together. This allows the candidate to have something they are super comfortable with.
• Work on a change for an open-source project that the candidate may have worked on. it is something familiar to them

Post interview

The interviewers should meet immediately and decide on a course of action. That action is not to do more interviews. The candidate should be told within 48 hours what the decision is and given honest feedback other than “You are not a good fit”.

Epilogue

The goal is to hire someone. As employers, Provide as much information as is practical to potential candidates before applying for a job. Be transparent on what will make them successful. Publish this information and make it easily accessible. Be aware that we are not the only employer trying to hire them. Optimise the hiring process to get what information the company needs and provide a good experience for the candidates. The interview process should be less of the eight hours of interviews with take-home tests that do not take entire weekends of peoples time and more timeboxed with rapid feedback to the candidate.