In one of my previous posts I was writing about a different kind of job interview. Today, I had the possibility to perform my first agile job interview, and although I only got twenty minutes, it was very well spent.
For this twenty minutes, I planned a pair programming session with the candidate. I planned the following exercises. TDD was optional in this case:
-
Implement a stack which stores the values in an array. This particular stack shall have the pop, push and size features
-
Implement a small application which consists of two classes; an emitter and a consumer. The emitter pushes elements into the stack, and when the consumer can access the stack, it pops the whole content, calculates an average and prints it out. The emitter shall push random numbers on the stack, and sleep for a random number of seconds. The consumer shall constantly poll the stack for items by popping all available elements, sleeping for a random number of seconds in between. When the emitter pushes a -1 onto the stack, it shall finish, and so shall the consumer. The average calculated by the consumer shall not contain the -1 value.
A possible implementation of the exercises is available on github. For more, on the examples above, refer to this post.
The first exercise is designed to check the team work and agile abilities, and the second one is designed to check how the candidate can solve a programming problem: in this case, race condition and Java threading.
During the twenty minutes we did the first exercise, and afterwards discussed the design of the second one. The goal was not to check how well the candidate knew the Java language, and how many details she could tell me. I just wanted to know easy or difficult it would be for me to work with her. As I said, the technical details can be learnt, but companies shall look for people who can work in teams and who can work with others. Pair programming is one of the most difficult XP techniques and if someone can do it with a stranger - that would be me -, then she can do it with others as well.
Here are the things I paid attention to during the session:
-
How are the design discussions going during the session?
-
Does she have the courage to be a partner in the discussion, or does she just follow my lead?
-
If I show something new for the candidate, can she use it later?
-
How long does it take for her to realize that a certain design decision is good or bad?
-
How does she test the code?
-
How often does she execute the test cases?
-
Does she care about clean code?
-
What kind of coding conventions does she follow?
-
Are the answers given by the candidate during the regular sessions still relevant?
My colleague and I learnt more from the discussions during the pair programming than from the discussion we had to perform based on a checklist. There is a huge advantage here. If people are focusing on the exercise, they are more likely to behave as they do during the working days. They will leave the stress and preparation for the regular interview behind. Due to confidential reasons I cannot quote the exact situation, but I can give you a similar example. During the regular discussion the candidate mentioned that she lacks a certain skill. During the pair programming session, I made a situation in order to see if indeed this was the case, or the candidate had just been modest. It turned out that there was no lack of it that skill at all, it was just stress that made her say that there was.
Being agile is not equivalent to be good at pair programming. There are other areas worth talking about:
-
Previous work/study experiences, focusing on the team work and the candidate’s situation in it
-
Ask about the recent events of the technologies or tools the candidate mentions in her CV. If she follows them, you can be sure that she takes the craftsmanship seriously
An interview scheme example:
-
Have a warm-up discussion with the candidate
-
Give a short introduction to the candidate about what will happen during the interview, because this is something new, and you can learn a lot from their reaction
-
Talk about previous team work and recent events
-
Have an at least one our long pair programming session. If possible, use a projector so that the other interviewer can also see it
-
Talk about administrative and HR-related matters, like working time, salary etc, at the end of the interview not before
The last step may require some explanation. During this particular part you may talk to the candidate about administrative details, which may consume some time unnecessarily. The salary is a different kind of animal, but I recommend to talk about it at the end with one exception, but let’s talk about it a bit later.
The salary is a sensitive question. If it is discussed at the beginning the candidate will tell a salary without knowing what is the position about. For example she tells a number, but afterwards she realizes that she would like to get more for that kind of job. In this case she has no possibility to change her mind, and she may continue look for other opportunities at other companies. If you - the questioner - provides the number in advance, the candidate may have that number in her head during the whole time, and her focus might be lost. Possibly every answer may be provided knowing that number. I found one exception. We had a heavy weight candidate, and my partner realized that she may have different kind of salary in her mind than us. He changed the steps, discussed the salary details, and the interview was finished in half an hour. My partner saved the candidate and us some time. This requires experience, but it will come with time.
If you have the possibility, try it out, and share your experiences using the comment section.
comments powered by Disqus