Me.Tech()

In the last three weeks or so, 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 a lot more years of experience than me go dumb founded when asked trivial questions. I handled mostly interviews for developer positions and have found that its 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.  I like a resume to be simple, short and precise. A 7 page resume isn’t something that I am interested in seeing. 2 to 3 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 creates 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. 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.
• 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.
• If you are interviewing for the role of a developer who works on web technologies, get your basic HTML, JS and CSS right. Brush up on some HTML5, learn about the different security models of browsers, cross site scripting etc And please, for gods sake know what the boundaries of a web application are. I am sure to throw in the ” Can you connect to a android phone using Javascript” question and I don’t expect the answer to be YES.
• 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(1) 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 developer, I will surely ask a design question on OO 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, IDE but without being connected to the internet. Or I would love to give them pre existing 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. Also, a developer good at debugging is always an asset to a team.

Well, this mostly what I tend to do in an interview. If you have more interviewer/interviewee specific points, questions, share them in the comments below.