The hiring process

I have probably conducted several hundred job interviews, ended up hiring close to 100 people. The process starts with a need, this spawns an advert, then the interviews, negotiations and contract finalization. I wanted to record some 'lessons learned' here.

The reality in Iceland is that we get a manageable number of applications, meaning that it is possible to read through them all and before deciding on whom to invite to an interview. The number of invitations are normally between 3 and 20. The number of interviews rounds are 3, but I have also done 4. Usually I try to squeeze the whole process into 2 weeks when possible.

The first interview - why you?

Initially I did ~1h first interview where I spent ~30min going through introductions to the company, products and processes. Recently I have shortened this to 20-30min by sending out a (abbreviated) introduction, a copy of the advert text (required skills etc.) and the interview questions/topics I would like to cover. This allows me to shorten the interview and put the focus on the applicant. At this stage, as I see it, the applicant is 'proving' (s)he is a good fit for the position.

The latest batch of interview questions I use is:

1. Something unclear regarding the invitation text?
2. What makes you interested in the position?
3. Where do your strengths and weaknesses lie w.r.t. the skill requirements and job environment?
4. What are your professional ambitions?
5. How do you think your coworkers would describe you?
6. Other questions from me related to the CV/introductory letter.

It is not important to go through these questions in order and in many cases when the interview 'flows' they get answered without being specifically asked.

I usually get someone to sit with me through this interview. I have been assisted by tech-leads, project managers, product managers, developers, testers, and HR personnel. It can help with the flow, but also getting a second opinion after the interview. I keep notes during the interview. Use a simple grading mechanism, giving a score of 0-10 for: Drive, Collaboration, Technical strength. It is important that the applicant has some drive, it can be for technology, the domain or best practice; can collaborate within a team; has the necessary technical capability. But I also look for fit w.r.t. the existing team members and our projects' requirements.

The second interview - why us?

The second interview is focused on issues that the first interview left unclear. Could be the need to drill down into certain technical skills or people skills. It is also an opportunity for the applicant to ask questions. But here the tables have slightly turned, now we are interested in hiring the applicant and we need to 'prove' that we are a good fit for him/her.

Usually I will get the helper from the 1st interview to sit in with me again. Before the interview I will have either called myself or asked HR to call the references for a basic background-check that goes mostly to character reference.

This interview does not have known list of questions, it can take 30min to an hour.

I will ask after both interviews if the applicant is interested to take the next step in the process and explain what time-frame I working with.

The third interview - how much?

Previously I would take the contract negotiations, but now this is done by the director of the department, I might be present or not during this interview.

Closure

I think it is important to send an email to those who did not get the position. Those not invited will get a rather standard email, but I will try to have a personalized email for those I met. The intention is not to spur a further discussion on merits, more an attempt to give the applicant a proper closure.

Development manager: where should you place your attention?

Your attention is a limited, valuable, resource. With attention I make the distinction between placing continuous attention (being pro-active) vs. temporarily placing your attention where needed (being re-active). So the question I would like to investigate is more specifically: on what to keep continuous attention.

At a high-level it can be said that the development manager has two (related) objectives: i) maximizing throughput of new product functionality and ii) minimizing product quality problems. 

Mapping your attention to those objectives results in:

i) Be involved in solving problems the teams face during development. I find the best vantage point here is to be involved in DevOps because they are all day solving these (technical) pain points. But also be involved in the developers' discussion on architecture, processes and tools to spot the technical debt that is holding them back.

ii) Be involved in solving the quality (correctness, usability, efficiency, reliability, integrity, adaptability, accuracy, robustness¹) problems that surface in the final product. Here the best vantage point is to be involved in release testing and monitoring of the product in production.

---

Note 1 What is missing: continuously paying attention to people and team dynamics. Frequently the problem analysis will reveal problems related to people (e.g. training), teams (e.g. communications) and processes (e.g. unclear responsibilities) and then you move your attention to those (re-actively) to solve the problem. When the problem has been solved your attention moves back to the main objectives. 

Note 2 This is my current thinking, I acknowledge the view (HR-take) of cultivating people and teams will lead to great products. That approach requires a certain leap of faith and does not fit as well with my engineering problem-solving outlook.

---

1 Taken from McConnell's Code Complete^↩