The Scientific method for interviews

I have been doing interviews for quite a while now and would like to share with you a method that I like to call the scientific method for technical interviewing. First of all the overall process goes as follows:

Observation > Hypotheses > Prediction > Experiment > Conclusion

I have to confess that during an interview I am not fast enough to do all the required steps so I do some work before. In any case let us go through the stages one by one.

Phase 1: Observation

Interviews are a short period of time to assess if the person in front of you could be an asset to the company. The candidate probably feels nervous, which will make the whole process harder for both of us. So the first few minutes I spend to introduce myself and to try to change the formal environment to a less formal one.

1. Hello, nice to meet you. I am Kurt and I'm a project leader.
2. You should be ... and you have applied for ... position.
3. Series of general questions.

I ask questions like: “How are you?” Or “Was it hard to find this place?”. I’m basically trying to achieve two things:

1. Relax the person

Get him in his comfort zone where he can be assessed much better. The trick in this is to act relaxed. People usually do what you do, if you are angry they will feel it and get angry, if you are relaxed then they will be relaxed.

2. Start making some observations

In reality, as an interviewer you started making observations and predictions from the moment you laid eyes on his CV. I use this time to have a look at what the person is wearing and how he is responding to the new environment. If he is confident he might have required skills to meet clients face to face. A lot could be said from the way a person looks and acts, and if you notice these a client and team mates will do to. I should stress that there is no right or wrong in this phase, I’m just making basic observations.

Phase 2: Formulate hypotheses

In this phase I need to confirm what role I think this person might fit in. Of course you already know what role he is interested in but companies might vary from the way they work, thus the role he applied for might not be the one for him. I basically try to understand what this person currently does, and what he aspires to become. Are they aware what is happening outside of his team? Are they involved in decision making processes within the company he works for?

4. What do you do on a daily basis?
5. What do you expect from your manager?

I like to use advise I got from a colleague of mine which might sound mean but it works 99% of the time: the years in experience of the person tells you a lot on their potential. If they have been working for 10 years and are still not senior developers they probably will never be.

I then use this information to formulate my hypotheses. Assuming the person is applying for a technical role, it is usually 1 of 4 categories:

  1. Candidate is a junior developer
  2. Candidate is currently a junior developer but is promising to become a senior developer
  3. Candidate is a senior developer
  4. Candidate is a senior developer and has the required soft skills to do some project management

One might argue that the position the candidate applied for already had a matching set of questions asociated with it. However should they fail to meet the required criteria you can at least still assess. The company might have other openings or there might be other openings in a few years time.

Phase 3: Predict and Experiment

Prior to starting the interview I already knew about the 4 possible hypotheses so I prepared questions for each one of these. Unfortunately I can’t share these questions with you, since I use them on a day-to-day basis. But I like to share the philosophy I use when coming up with these questions. Basically I try to cover as many technical areas as possible. I usually use Sijin Joseph’s competency matrix as a checklist to make sure I’m assessing all the important areas.

5. Series of technical questions

Before each question I like to guess if the person would answer the questions correctly or not. This will help me after the interview to make more accurate predictions in case I missed on any questions. Also if the candidate starts getting a lot of wrong answers I might change my original hypotheses and ask easier questions. Alternatively if all the questions are right I ask harder ones.

Phase 4: Conclusion

This is where you conclude the interview. I usually like to conclude by asking:

6. Do you have any questions you would like to ask me?

What ever he answers I make sure that I re-explain my position and what I do on a day-to-day basis. I do this for 2 reasons:

1. Avoid Candidates from making the wrong decision

Make sure they wont have any surprises should they be chosen. This is all about setting the right expectations and make sure that they are aware of the full picture so that should they be chosen they won’t leave the company after the first few weeks.

2. Sell the company

The candidate is still an external person and even if they are not chosen you might still work together in the future. I make sure I give the person the right impression of the company I work for.

Post Interview Work

Just after the interview I like to speak to someone, who was either present during the interview, or someone else who usually does interviews. We then come to a conclusion. This should take no longer then 5 mins. Something to keep in mind: if you are not sure then don’t hire the person.

To help me out I usually have a large excel file with different sections. It has the various questions and the scientific stages, which serve as a guide to help me out. I jot down loads of notes and mark the questions as good or bad during the interview. Should there be another opportunity within the company in a few years time, I can refer back to this sheet. This will help me remember my reasons and evaluation on the candidate.

To conclude, I am usually quite strict on who to say yes to and I like to think that this is for the candidate’s advantage. If you end up hiring a person which isn’t up to standard he will probably get fired. This will make him and the company lose money. Remember that people have loans to pay and children to feed, his salary might be essential for him. Don’t take any risks, if you are not sure its best to say no.

4 Values Of Scrum Masters

Recently I have attended a seminar which made me think of some important qualities that every scrum master should have. I would like to point out 4 important values that I think are essential characteristics of a scrum master. Why 4? Because 4 is an even number, less than 5 but greater than 3 (sorry JB is speaking). So here is the list:

Positive Attitude

Being a person who sees a glass half full does have its share of benefits. Even when things go wrong you should still find a way to motivate the team and lead them in the right direction. Having a positive attitude doesn’t mean that you are totally satisfied with the way things are going, you should always aim for better, and use positive constructive criticism along the way.

Transparency

Everyone should be aware what on earth is going on. As a scrum master you are not a manager who secretly decides with the rest of the management and then forces down the decisions. Even though the scrum master can lead, the decisions should be taken as a team.

Serving

As is highlighted in several agile books the team leader or scrum master is there to be a servant for the team and facilitate any issues. The modern project leaders, or scrum master should aim to control rather than enforce rules. A scrum master’s role is there to remove any impediments and come up with solutions for the problems the team face. If developers don’t have a good sense of what each other are doing, the Scrum Master sets up a physical taskboard and shows the team how to use it. In essence the scrum master is there to solve issues and help out the team.

Aim to become redundant

Your aim should always be to find people who can do your job better than you, so that you can move on to other things. The minute you get stuck, is the moment you stop improving which will lead you to boredom and eventually death – actually you are going to die anyway so it’s not a good example. But the point is that you should aim to not be a single point of failure, the team should operate without you.

The only value required

I really like this ad from apple produced back in 1997 when Steve Jobs rejoined the company. This video probably sums up what a scrum master should be all about, basically it is about being a good leader. To be honest a leader has all the values which I mentioned above. Which makes my previous 4 values of scrum masters pretty much useless and defeats the whole purpose of this blog post.

Basically what I’m trying to say is, that as a scrum master you should be a leader. What I would like to point out is that there is a great difference between leaders and managers. Managers enforce processes while leaders always try to improve and are never happy with the status quo. They are the square pegs in the round holes or rather the round pegs in the square holes.

High Speed Mono Tasking

This should come to no surprise: humans can’t multi task. Women can do it better but overall we still suck at this. Furthermore doing things in parallel is much slower than doing things in series. With this in mind we should be focusing on a single task at a time and try to achieve high-speed mono-tasking.

Lets take a simple example to proof this theory. Let us assume that you have 2 tasks each of which take 10 mins to complete. If you do one task after the other you will get the following performance:

Time Task 1 (time left) Task 2 (time left)
0 min 10 min 10 min
2 min 8 min 10 min
4 min 6 min 10 min
6 min 4 min 10 min
8 min 2 min 10 min
10 min 0 min 10 min
12 min 0 min 8 min
14 min 0 min 6 min
16 min 0 min 4 min
18 min 0 min 2 min
20 min 0 min 0 min

If you work on one task after the other, task 1 will be finished after 10 mins, while task 2 will be finished after 20 mins. Let us assume that you will alternate between the 2 tasks every 2 minutes:

Time Task 1 (time left) Task 2 (time left)
0 min 10 min 10 min
2 min 8 min 10 min
4 min 8 min 8 min
6 min 6 min 8 min
8 min 6 min 6 min
10 min 4 min 6 min
12 min 4 min 4 min
14 min 2 min 4 min
16 min 2 min 2 min
18 min 0 min 2 min
20 min 0 min 0 min

In this case task 1 will be finished after 18 minutes – 8 minutes later when compared with the sequential method. On the other hand task 2 will still be finished after 20 minutes. 

But wait… the above working is wrong. Humans, much like CPUs, need time for context switching so we should be adding a constant every time we switch tasks. Doing tasks in series also gives us another advantage. After doing the same task for a while you will become immersed in the task and get into “the zone”, which will increase the level of productivity even more. 

A method to keep you focused on a single task at a time is to use a task list, ordered in priority order. This is exactly what the backlog in agile methodologies is designed to do.

In this case our responsibility, as scrum masters, is to make sure that everyone is getting as few interruptions as possible to keep on focusing on his task. To conclude, your quality and productivity should increase much further if you and other team members use the technique of high-speed mono tasking.