I've been thinking about interview questions recently. One interview technique no one's used with me: "identify the problem." For example, let's say I asked the following question:<p><i>What I need is a high-traffic scalable document store. The churn of documents is going to be very high and the documents can be very large. I'm going to need to regularly retrieve documents, but mostly only the documents with the closest expire time. How would you go about solving this problem?</i><p>Now, there are so many variables in this question that asking for a specific solution is practically useless. Instead, it would focus on an interviewee's ability to parse the computer science problem from the stated problem. I would be looking for answers that include possibly building an index of the documents stored in a distributed priority queue architecture. I'd ask them where they expect pain points to be. Good answers would include things like providing document synchronicity across a distributed architecture, providing good failover in case of machine failure, and working out a sane and minimalist communication API between machines.<p>Basically, I'm asking candidates <i>what</i> they should Google if they were trying to solve this problem. The answer given when many coding questions are asked is "I'd Google it," but I've learned that recognizing what to Google is an incredibly hard question. When you start dealing with problems harder than "what was that function in the standard library called again?" it becomes even more useful, because the question now isn't "what do I Google?", it's "What papers do I need to read to understand succesful models of this problem?"<p>I'm just an interviewee still so I've never been able to give this method a try, but I'd be interested to see if results are better or worse than current methods.
Interviewing at Google is definitely an experience.<p>One guy came in and without introducing himself started to write numbers on the whiteboard. He drew borders around some of them. Then he sat down, introduced himself, and said that what he wrote on the whiteboard was machine code. After explaining some of his nomenclature he asked me what I think that code was doing.<p>Another guy asked me to solve a problem (don't want to say what specifically it was, because they may still use that question)... Anyway, I could not for the heck of me solve that problem. After 45 frustrating minutes of this he started to write down the solution, then hesitated, then stopped, saying something like "Hmm... It's not quite as easy as I thought".<p>In the end I ended up declining their offer. I spent some time on their campus, and the vibe just did not feel right. Can't put my finger on it, though.
I apparently passed a phone screen with them four years ago. Unfortunately, I only found out that I passed the phone screen a couple weeks ago when a Google recruiter called me up to inquire why I'd never interviewed on-site with them after this failed recruiting situation[1].<p>Seemingly, having a friend who's in a senior exec position at Google seems to be the only surefire way to ensure you get an onsite interview. At least then your friend can hold Recruiting's feet to the fire.<p>[1] true story. I've elided some minor details which make the whole thing seem even more farcical.
I've interviewed (onsite) at Google twice. First time I go invited back for more (which I declined) but the second time I failed.<p>My second onsite was a pretty miserable experience to be honest - I just wasn't doing well, and I knew it, but I couldn't get it together.<p>But one useful tip that did come out of it. The first interview (of 5) was via video, and it took 30 minutes to get going. It was the first time the interviewer had done one on her own, and she seemed more nervous than me. I didn't do great, but did nothing terrible either.<p>Anyway, when it came time to finish, she asked me if I had any questions. I was prepared, so asked her something, which she answered quickly - then asked if I had anymore. I said no, and so she goes "well in that case.." and asked me another interview question. And it was the one question I've had that I had <i>no idea</i> of how to approach.<p>Lesson: make sure you have <i>lots</i> of questions, and keep them talking.
<i>"If it’s any consolation, at least we don’t ask gotcha riddle questions anymore. Those were especially offensive."</i><p>What, no more Fermi Problems anymore? No more reasoning about how many piano tuners there are in Chicago? No more estimating how many hairs you have on your head? Not necessary to calculate the total number of sheets of 8.5 x 11 inch paper used by all the students at the University of Maryland in one semester? How many drops of water are there in Lake Erie? How many notes are played on a given radio station in a given year, has become irrelevant? What a loss ;-)<p><a href="http://en.wikipedia.org/wiki/Fermi_problem" rel="nofollow">http://en.wikipedia.org/wiki/Fermi_problem</a>
As it is in a lot of things, passing an tricky interview may not be the best metric of coding ability, but it is indicative of problem solving ability.<p>It is the same reason top companies tend to recruit from top schools. The chance that you pull a top notch programmer from a top school is higher than the chance that you pull one from a mediocre school. In the same way, the chance that the kid who passes your interview with flying colors is a good programmer is better than that of the one that completely tanks.
I'd love to talk more about how we can improve on the typical fare of programming and algorithm questions.<p>I've had to write my own sorting algorithm perhaps twice in the last some-odd years. If you're writing sorting algorithms from scratch, you probably should sit back and consult your standard libraries.<p>So if I ask a candidate some basic coding question and he can't write a for loop, I know it's a no-hire. But past that basic bar, sifting apart the good candidates from the great ones is actually very hard. Do we continue to ask these questions because we can't do better?<p>(That's why I ask algorithm questions. I realize they suck, but I just don't have any better ideas. I'm an engineer, not an HR flack.)<p>So what's a better way to test a programmer candidate?
recent college grad here<p>the conundrum is this. i spent my time learning the academics and theory of programming, design, and business. jobs want experience.<p>i am an extremely fast learner, but cannot get a chance at a full time job after being successful at a paid internship for over a year.<p>everyone is looking for experience, i feel like if you don't know Exactly what you are doing day one, then you can't get your foot in the door.<p>yes, i have a website up, resume tuned, and a portfolio of what i have done.<p>thank god for unemployment checks... =/