Questions I like to ask at interviews

There are a few questions that I always like to ask in interviews, some are old favourites others are newer but all are trying to work out what type of person I'm dealing with. There are technical detail ones as well but these are the general ones to work out if I'm going to have to kill or simply re-educate.

General Knowledge
This isn't general knowledge in the terms of "who won the FA Cup final in 1960" but General Knowledge about IT. Simple questions

1. Have you read the Mythical Man Month?
1. Is it still relevant
   
2. What is Brooks' Law
3. What are the important lessons you learnt from the book
2. Have you read Death March?
1. Is it still relevant
2. What experiences have you had where a project became a Death March
3. Have you read Peopleware?
1. Is it still relevant
2. What do you think is important when building and managing teams

There are a few other books that I throw in sometimes and of course asking what is the book that they think is the most relevant (hint of the day: slashdot.org is not the right answer)

Systems Theory
The next bit is always around what they know about the architecture and design of overall systems. The only way to do this is via a practical. So I tend to set a theoretical RFP (Request for Proposal) and give them 15 minutes to read it and then 15 minutes to respond. The test is designed so in that time period they will almost certainly fail to find a perfect answer but its the approach that is important. What I'm looking for is

1. What questions do they ask
2. Where do they start
3. How clear is the architecture
4. What principles are they applying
5. Why aren't they doing certain things
6. How do they react when a better way is suggested
7. How do they react when a worse way is suggested

The latter is just as important as the rest as it shows how firm people are. If you are in an interview it takes a certain class of communicator and engineer to correctly explain why a bad suggestion is rubbish. The previous question is to find out how stuck in their ways they are, if there is a suggestion that is clearly better and they defend their previous idea explaining why they chose it then that is okay, if they get defensive that is not okay, if they explain the previous thinking and then switch to the new thinking that is ideal.

SOA
Asking them to define SOA is always entertaining. People who rush down the technical rat hole of T-SOA (WS-*) then have to draw the "stack" before being asked from a business perspective what would be the difference between two identical services, one implemented in "code" the other in BPEL. People who deal at the abstraction and architecture level tend to do better here. Normal questions that I like at this stage are

• What is a service
• What is the right granularity for a service
• What is the relationship between business process and service
• How would you find the right services for a business

On the later point this brings me to the last section

Passion
This is all about understanding the passion someone has for an area and how up to date they are. Personally I just don't understand why anyone gets into IT who doesn't get excited by change and who doesn't track change. Sitting on your arse saying "well it worked in the 90s" is just ridiculous, the only way you can say "X is crap" is to read about it and try it out.

The first test is do they understand the power of the internet? The way to find this out is did they Google their interviewer? The number of times it becomes clear that the interviewee hasn't done their research on the company they are interviewing for and hasn't bothered checking to see if any of their interviewers come up is just mental. Every client meeting I go into I Google the client to see what they have said publicly and I certainly do the same to people I'm interviewing. If you haven't done this then I'm always concerned.

Next up is just the social stuff. What do you read? How do you keep up to date? Then we move onto the next stage

1. If ten years ago you'd said that the internet would be the default form of B2B and B2C commerce, that Mobile Phones would revolutionise the developing world and that RF-ID would fail to make it to large scale adoption in the next ten years then right now you'd be looking like a genius. What technologies that are currently hyped will you predict now for the next ten years and why.
   
2. Ruby, Scala, Python and other dynamic languages are on the rise, why do you think they will take over from Java
3. Who do you think are the most influential technology companies

There are a few others but number 1 is a cracker (for Java interviews I also like "we broadly know what will be in Java SE 7, what would you like to see in Java SE 8" and similar for Java EE, the same can be done with even more entertainment on .NET) most people just blurt out technologies that either already major or pick things that are so low level (like saying something like REST or Web Services) that shows they don't understand the context.

Selling yourself
After the questions comes the bit to ask the person to describe themselves in three words and the positive attributes that they will bring to the job. The final question I like to ask is for someone to come up with a marketing slogan, one line, which is the reason why they will stick in my head and they should get the job.


Now if I am about to interview you and you've read this.... well done, its going to help you. If you are reading this on the way to the interview and haven't read the Mythical Man Month.... find a way to crib.

Otherwise hopefully these might help other people who are looking to interview and are looking at the more general elements of a persons technical ability rather than the technologies themselves. I've worked with far too many people where I've thought "how the hell did they get through an interview" and then found out how they were interviewed and not been surprised at the quality that resulted. Its not fool proof, I've hired a few duffers in my time, but I'd say my quality ratio is higher than the average.

Employing people in IT is about much more than the technology its about how rounded they are and how they will cope with change. Time and time again I've found those that can cope with and communicate change are much better at their jobs than those who can simply code. The technical skills are the basics that everyone must have to even have a chance at being good, but its the overall view that makes them good.

Technorati Tags: technology, jobs