I’m currently preparing myself for a Google Phone interview. During my research I found this website, that listed common algorithms one can expect in a typical interview. I haven’t got my head around that yet, but jumped to the comments, which were very interesting:
These are horrible – if typical – interview questions. Asking horrible programming questions will get you horrible programmers.
I’ve been developing software professionally for 25 years. If someone asked me how I would implement a linked list, my answer would be “I wouldn’t. I’d a) develop in a language which supports lists natively or b) use a library.
If your interview tests people on their ability to reinvent wheels, you’re going to get programmers who are good at reinventing wheels. You want your interview questions to test a candidate’s ability to solve problems and make smart design decisions. Reinventing the wheel is almost never a smart design decision.
I basically agree, it doesn’t make sense in most companies, to reinvent the square wheel all the time. I had an interview with a startup that asked my how to implement a Hash-table …. in the end they didn’t know anything about my problem solving skills and ended up explaining a Hash-table to me. Still they were interested in me taking the job.
But for companies which are driven by algorithms, like Google or Facebook, it does make sense, to check whether the applicant know these things. Not to implement it by heart, but because the questions they asked are related to such algorithms. They don’t ask to implement a linked list, but they may asked how to detect a cycle in a linked list, or the start of the cycle. They want to see whether you can use the basic knowledge about algorithms to solve problems.
To know the algorithms by heart is one part, but to apply that knowledge to solve trick-questions, that’s what they want to see.
In the end, I know I’m not a good or bad programmer just by this knowledge, but I want that Job at Google
I also once applied with a company that asked me how to implement a Hash-table. At that time I did Java programming for more than a lot years, 2 of them as contractor in a top financial company in Switzerland.
I told them I don’t know how to implement a Hash-table and that if I’d need something like a Hash-table…. I’ll use a Hash-table. I though, well that interview is over, but instead, they insisted on me to guess how I’d implement a Hash-table. I told them, I’m not willing to do guessing and spend time to come up with a mediocre solution that has already been solved and I would just look ridiculous. They agreed and explained me how a Hash-table worked
For the next question the manager asked me a question about me J2EE background. He drew a big rectangle and said: “That’s the Java Application Server”. Then he drew a smaller rectangle in it and asked me: “What’s that?” I said: “It’s a rectangle” – “Yes, but what does it mean?” – “I don’t know. What does it mean?” – “It’s and integral part of every Java Application Server, can you tell me which one it is?” – “No, it could be any of the integral parts” – “Ok, just tell me an integral part of every Java Application Server” – “Well, is it an EJB?” – “No, its the J2EE Container” I just shrouded my shoulders. Whatever.
In the end they offered my a job