(If you want to get real information how to really interview, don't look anywhere else but http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html)
I happened to cover my team lead for an interview, and apparently our interview process is quite harsh. Harsh is not enough to explain - It was like trying to dodge bullets during a hurricane. If I was the intern, I would probably have flipped over the meeting table and run for the window!
Let me first explain to you how our interviews are structured. Depending on the candidates' experience and position they usually go through a minimum of two 45-minute interviews. You would think two interviews is very short, right? Well, each interview happens to have three people on the opposite side of the table. These three people are preferably from different teams. So you're interviewing three people all at once. That's quite a pressure if you're used to having 1-on-1 interviews.
Interview started off with pretty straight forward questions that every CS student must be able to answer really easily:
- What is polymorphism?
- What is difference between method overloading and method overriding?
- What is a Reentrant Lock? How does it differ from a Semaphore?
- How do you select all columns from the Users table?
- What's the time complexity of Merge Sort? (This one really annoys me, I'd rather ask them to implement it first, and then tell me the answer based on their solution instead of directly answering it.)
- What's the difference between a regular inner class and a static inner class?
- Why should I choose StringBuffer over StringBuilder?
- What's the difference between Interface and Abstract Class?
- What is a Socket?
- How do web sites "remember" you? (Let me give you a hint, it's got nothing to do with IP or MAC addresses!)
- Which one performs better for parsing XML: DOM or SAX? (another hint, it's not DOM!)
- What is the difference between HTTP and TCP/IP?
Sure, these questions show us how much of a technical knowledge the candidate has, but tells us nothing about how smart or if he can get things done! After the first 10 minutes of total destruction, I was a little sad for the interviewee. To tell you the truth I even sympathised with the kid. I'd rather try to understand if he was a smart, capable and fast learner kid, so I stepped in; I have a couple of very simple questions that show us the candidate's knowledge of algorithms and problem solving skills. So I went with my favorite question:
"Write me a function that reverses a String."
Takes, maybe, 2 minutes to answer this question on the board. Another 3 minutes to have a step-by-step testing exercise. Once the candidate is confident with the answer, I then ask them if they saw their bug - let them roll around in the mud for 5 minutes. This is especially fun if there is no bug - the good ones just go nuts trying to find their non-mistake.What makes this my favorite question is if you have good candidates, then there is so little places where they'll mess up. If they can't even answer this question, you know they are a "No hire". Unfortunately even I can't make any exceptions if you can't answer a standard question.
Fun part is if the candidates go through this question like a breeze, you can easily extend the question to better measure them up:
- What's the space/time complexity of your solution? (Did they go to their algorithms class?)
- Now do it in constant space. (Problem solving skills)
- How would you solve this multi-threaded? (Translation: Are you a superstar student?)
0 comments:
Post a Comment