Are you an IT manager / chief developer / architect responsible for interviewing candidates for a software development position? If so, I bet 90% of you could as well flip a coin to decide for or against a certain candidate. I’ll tell you why in the following article.
Let me start with an analogy. Assume you want to build a house, so you are looking for an architect to do so. Further assume that you have one recommendation and two architects you searched for on the internet. You checked their websites and liked what they have build/designed so far. So you have an interview situation. You want to know which of the three to choose. I guess this will sound familiar to most of you so far. Now for the, I admit predictable, shocker. Next thing is that you invite each candidate to a personal meeting. You do some small talk, you ask a couple of questions about the candidates previous work, etc. Then, out of a sudden, you present the candidate a sheet of paper with a math test in it. Some geometry, some linear algebra and some calculus for the sake of completeness.
“Wait a minute” I hear you say. This guy has been working as an architect for the past 15 years and has built dozens of houses, you don’t need to have him do a math test for gods sake!
Ok, you know where this is going. So for the same reason, if you want to interview me, please do not
- ask me to write “working” code on a sheet of paper,
- have me find bugs on a printed piece of code,
- ask me silly, super-detailed questions about programming language XY you downloaded from the internet 5 mins before the interview,
- compare me to your other colleagues who all can code a full featured address book application in 2 hours,
Then again, please also do not
- choose me because I am the nicest candidate yet,
- blindly trust my resume,
- believe all I say when asked “can you do XY?”
Instead, please invite me with enough time. Get to know me. Then, let me pair program with one of your developers on a small problem. A problem that your dev has not solved 100 times before. Because it does not matter whether I solve the problem or not. What matters is my attitude and work style when working with you on something real. Experience how I approach problems and cooperate with a team member. If I am more experienced, do I take the lead and let your dev learn something? If I am less experienced, do I try to learn how your dev is doing things? Do I take care about the code I am producing? Do I write tests? Etc. This is what you will be paying for if you decide to hire me. You won’t pay me to solve sorting algorithm questions on sheets of paper.