Sure, just do whiteboard coding of a difficult algorithm because it replicates actual coding conditions quite nicely </snark> I'd much rather see what a candidate can come up with while working at their leisure, using their favorite IDE, googling syntax and other questions, testing, and having time to refactor than see what they will come up with on the fly, under pressure, without any tools available to them.
This. I've also had co-workers hell-bent on building out over-the-top unnecessary solutions (albeit sometimes neat in a technical sense) to problems that already had existing solutions that we could have easily leveraged and saved lots of time (money). Being able to leverage resources efficiently so that you are able to get more done is valuable. Go crazy and solve big problems when necessary but don't be afraid of using Google or any other resource to get through the rest.
Exactly. Love or hate Goog/Bing, they are powerful tools if you know how to use them.
Before the ubiquity of spell checkers I never hesitated to pick up a dictionary to double check spelling or a definition. I've never thought twice to grab a text book, manual or encyclopedia to reference a subject I was familiar with but did not know by rote or fully comprehend. Memorization is a very useful skill, as is understanding & comprehension. There is no guilt or shame in not being omniscient.
The goal of the problem solving interview is more to see the candidates reasoning process and less the ability to recall the problem and reproduce a solution. I like interviews where the problems are more open ended and the interviewer is active in the process and it's more of a discussion towards a solution and THEN coding or at least some pseudocode.
I've had interviews where I'll be asked some canned algo/data structures problem (some version of knearest, or longest substring) and then the interviewer will tune out- these are mostly lame.
That's what I meant. I personally hate interview questions revolving around "reverse a string" and alike, but really like open ended questions, which result in many options and discussions, AKA "design questions".
