Tips to technical interviewing
Tips to technical interviewing
"So you don't know what a static inner class is?"
Editor's Note: Participate in or view the associated forum discussion . It will be live until May 12, 2004 and archived after that date.
It's 12:50 on the 17th floor of a high rise in downtown Brisbane. I wait nervously and anxiously in a small room with a Business Analyst, who had interviewed me a day earlier, for my technical interviewers to arrive. This interview that I am waiting for was supposed to start at 12:30 but the interviewers are nowhere to be seen. It helped that the Business Analyst was nice and friendly and I knew that he had a favorable impression of me so I was anxious to get started and make the same impression on the technical interviewers as well. Suddenly the door behind me opens and two guys walk in. I get up from my seat and go forward to greet them. However, neither one of them is smiling.
Technical Interview Tip 1: Interviews are tough. There is no question about it. At once, interviews can make or break the confidence of the interviewee in himself. Even though you may not give the interviewee the job, a good
interview can make him feel powerful. Keeping this in mind, as important as it is for the interviewee to arrive on time, it is even more important for the interviewers to be present and ready. The feelings of self doubt and anxiousness that the interviewee feels are heightened with each passing second that the interview does not start. Further, make sure that when you do eventually start the interview, a formal apology is made to the interviewee from all members of the team who are going to interview him.
Although my greeting is reciprocated, I get the feeling that there is something wrong. The long haired one is looking at me with curiosity and the other guy is simply looking angry. Infact, he is pursuing his lips and trying
hardest to show that he means business by looking grim. I try to break the ice by mentioning that I have met the long haired guy before. This makes the grim guy even grimer and my heart makes a flip turn wondering what I did wrong. Without further adieu, we proceed to the interview room.
Technical Interview Tip 2: The initial contact with the interviewers makes a big impact on the way the interviewee feels about the situation at hand. The interviewee needs to be made comfortable and relaxed. This might sound corny, but a smile goes a long way in making the interviewee feel comfortable about the interview and the people he had been dreading about meeting since it was scheduled. He should be able to see that these are guys (or gals) like him after all! Even the most confident and technically sound candidates feel nervous about the social situation that is created. Don't make it harder on them by being grim or aloof. Smile!
The interview room is like a Doctor's surgery. There is a big desk with a big chair in a corner and a small chair adjacent to it, where a Doctor would ask the patient to take a deep breath before he puts the needle in. I feel
like taking a deep breath myself as I am told to sit in the small chair. The grim guy takes the Doctor's chair and the long haired guy takes a chair in the far corner and immediately opens up a laptop, as if he is the cigarette smoking man from an episode of the X-Files. Here to purely observe!
Technical Interview Tip 3: Environment and surroundings are important if you don't want the interviewee to sweat. Literally! Although, in a sense, the interviewee is like the proverbial goldfish in fish bowl, don't make him feel as if he is about to be gobbled up by the cat. You can observe but don't make him watch his back. It is important to make sure that all interviewers are in the line of sight of the interviewee, so that he knows who to address while answering your questions. Make sure that the interviewee is in a comfortable seat, not too high or low than your seats.
The grim guy takes a badly scrawled piece of paper out of his pocket and studies it for a few seconds. He picks it up, brings it closer to his face, as if to decipher his own writing, and then puts it down and stares intently at me. I show a nervous smile. It is then that he speaks for the first time. "So what do you think is the effect of making an inner class static?"
Technical Interview Tips 4 and 5: Each technical interview must start with an introduction of the process. The interviewers must have a blueprint of what they want to ask the interviewee and in what order. Further, this process must be explained to the interviewee so that he understands and is comfortable with it. The due diligence and structure that you take in writing your code should be shown in the interview process as well (assuming that you are a developer yourself).
A technical interview must never start with the toughest question on your list. In fact, it should not start with a technical question at all. Start your interview by asking the interviewee about what he is currently doing, or the last job that he did. This is the easiest question for the interviewee to answer and it has two advantages. First, the interviewee gets comfortable with the whole interview process because talking about their current job/recent assignment comes easily. Second, it gives you material to query the interviewee about the technical side of this current job. An innocuous question like "So tell me about what you are doing, or have done in the past using what technologies" can uncover a smogorsboard of questions for you to query the interviewee with.
My mind stumbles, falters and jumps around trying to pierce together "static" and "inner classes". But it goes blank and I fail to come up with an answer. The interview hasn't started well and I literally start to sweat. Seeing my discomfort, the grim guy says "Would you like to know the answer to that?". I say yes, and am treated to a monologue. Before he is finished, the long haired guy questions me on the "architecture of the last application that I worked on". I relax and think that this is something I know, and start promisingly. Before I have finished my second sentence though, the long haired guy asks me "to be specific and not work on generalizations". I start again, fearing that I have not understood him correctly. An architecture is an architecture right? I try again, only to notice that neither of the interviewers are looking at me, one is playing with the laptop and the other is scanning my shoes. Anyways, I scrap through that, and am handed back to the grim guy, who pursues the dreaded list again and reels off a series of bland theoretical technical questions.
Technical Interview Tip 6 and 7: Although debatable, it is perhaps a bad idea to ask theoretical questions in a technical interview. What are you actually looking for in a candidate? His ability to answer questions which require him to remember every nuance and specifics of a language or his experience, ability and diligence in coming up with solutions to problems? Language fundamentals, are really just that, fundamentals, which can be crammed up or looked up when the need arises. You can have written tests to assess the ability of a developer or ask him to prove his credentials by taking a certification exam. But asking him to remember the signature of a particular method is liking putting you back in prep school to recite the 50 states. Not a good idea.
A fundamental aspect of the interview process is helping the interviewee to become confident enough in his own abilities to be able to showcase those abilities. Although this is not something that the interviewers are obliged to do, it is something that they can help with. Encouraging the interviewee with direct eye contact and a nod when you think that the interviewee answered something correctly will make the interviewee more confident and in control of the situation.
At this stage I know that the interview is not going very well. I am hoping that by the time we get to my code submission, which I had submitted a couple of days earlier, I may have a better chance, as I am confident in my solution. However, it only gets worse. The long haired guy brings the laptop on the desk and I see my code on the screen. He questions me on the style, the indentation, the choice of variable names and finally on the solution. He disagrees with me on all the aspects and tells me that my code does not adhere to their coding standards (CheckStyle) and that it would suffer "a heart attack" if evaluated against it. Further, he tells me that the solution can easily be modified to make it future proof.
Technical Interview Tip 8: Code reviews are an excellent way of evaluating potential candidates and their coding skills. However these reviews should be looked at in context of the problem that they solve and the approach of the interviewee to solving it, and not on their style and coding standards. Most organizations these days use automatic standardization tools that can inculcate newcomers to the organizations coding standards. Remember that whatever coding standards are followed within your organization may not necessarily be the norm outside it. Evaluating an interviewee on the style of their code is like judging people by what they wear. It has its place, but not in a technical interview. And with a good candidate, you can always give it the queer eye.
When evaluating the code review remember the parameters within which the interviewee had to solve the code review. Did the terms of reference ask the interviewee to make sure that the solution should be future proof? Did it ask him to solve the problem as a showcase to his coding skills or his analytical skills? Should the interviewee second guess your expectations? Remember, a solution should be made as simple as possible, but no simpler. Evaluate this code against this paradigm.
It is almost the end of the interview process and I am exhausted by it. I know that it hasn't gone well. In a final act of self preservation, I ask the interviewers to ask me more questions as I know I can do better. I also tell them that this was a very different interview process for me as I am normally not asked these types of theoretical questions in an interview. The grim one, now with a smile on his face, informs me that although they have no more questions, they have a reason for such questions. "We are called to solve some of the world's toughest problems and therefore have to make sure that we hire the best. There have been so many cases where we were called after other software firms had given up".
Technical Interview Tip 9: Pride is good. Self-Adultation is not. While you are proud of hiring the best candidates, do not make it the sole reason for attracting candidates and worse, of rejecting candidates. Many a company have lost good candidates because of indulgence of form over substance. Praise your achievements, but perhaps the candidate already knows that and therefore the reason why he is in front of you. It is not the time to shout it out, but to be humble and to seek deserving participants in the search for future glory.
Needless to say, two days after this, I got the call. Sorry, you are a good developer, but not really a XXXXWorker. I am still looking for a job.