on Apr 27th, 2010Interviews Schminterviews
In the last three weeks, I have panel interviewed about 3 people and have reviewed about 4 others in their interview process. I must say, I am surprised at the level of technical skill most of these candidates exhibit during the interviews. People with lot more years of experience than me go dumb founded when asked trivial questions. I handled interviews for developer positions and have found it extremely difficult to spot talented people. There are some, who are really talented, but cannot express themselves. And then, there are people, who don’t know shit, but act all Chuck Norris on the interviewers. Are you really determined to find talented people? Then here is what you do. Here are some things that you might like to read as well.
- The Resume: Oh! this one is tricky. Instant brownie points if the resume is LaTex generated. Reason? Well any person who has worked with LaTex would have had to do it for authoring a paper. Any person who understands the effort and rigor involved in authoring papers surely deserves points. I like a resume to be simple, short and precise. A 7 page resume isn’t something that I am interested in seeing. Two or three pages at most. Here is what I look in a resume: The objective should not look copy pasted and should be something original. I also like to see hyperlinks on a resume; I would definitely like to explore a little more about the stuff that you mentioned in brief. It builds curiosity and that’s good. And no, I don’t care if you won the second place in your high school bharatnatyam competition or if you organized your college fest.
- My first question would be the fizz buzz question. The question loosely reads as follows: “ Your task is to print numbers from 1 to n. For every multiple of 3, instead of the number you print fizz and for every multiple of 5 buzz, and for every multiple of 3 and 5, you print fizz buzz“. Take any language that you comfortable with and solve this problem. This is like a tard filter which will let me not waste my time with posers. You will be surprised at the number of people who fumble doing this.
- I wont really care if you have worked with JMS, XML, J2ME, AJAX, SSRS, SSIS, JSB, WCS, JSTL, HTML, DHTML, XHTML, MOSS, SOAP, BO, WPF or any other such acronym. These are just technological deltas which you will eventually have to use. My question will always be as to why did you use such a thing. What were the benefits and such.
- I have always felt writing programs is always about algorithmic aptitude, intelligent manipulation and handling of data and optimization. So there will be one question in each one of these topics, at least. Make sure you know your data structures really well. I have heard answers about hashmaps being stored sequentially, binary search time complexity being O(n), hashtable complexity being O(n) and so on. According to me programming is all about data structures and making conscious and intelligent choices about them. Also, knowing how to solve a problem is not an end to a problem. See how you can optimize your solution. I am sure to ask an optimization question.
- Design : If the position is for a senior developer, I will surely ask an Object Oriented Design question and on conceptual modeling of data. If you don’t know normalization , ACID properties of data , then read up. Its used in the real world and if you cannot model a student-library database, you seriously have to consider an alternate career.
- Off beat: I am always pushing to see if a developer is passionate about his or her work. I am sure to ask the person, “What according to you is the best project you have done and why do you think its awesome?”. This you should answer for at least 5 minutes and should do so passionately.
- Contributions to Open Source is definitely a plus. Even if you released a project that no one other than you downloaded and used, its better to put that in your resume to earn brownie points.
- If I have the time and the resources, I would encourage another round of coding. In their favorite language and IDE, but without being connected to the internet. Or I would love to give them pre written buggy code that they should help me debug. That’s more of a hands on approach and it helps in a couple of ways.
- 1. Most dev’s like to write code and would not like to read pre-existing code. Most of the times though, its not possible to keep writing new code, you will have to look at old code and debug it.
- 2. A developer good at debugging is always an asset to a teaam.
Well, this mostly what I tend to do in an interview. If you have more interviewer/interviewee specific points, questions, share them with me.