Allow “Phone a Friend” during Technical Interviews?

Technical Interviews should be a sit down and code session for an hour or two with someone on the team (it can even be a remote screen-share session). Everyone I've ever hired/not hired I've done this with and it is quickly obvious if they can do the job. I just give them an issue from an open source project I have and a clone of the master branch and ask them to solve it, they can use Google or whatever resources they want. With me looking at their process I can easily tell if they are qualified for the job.<p>I just hired someone for a job who's first response was to copy and paste the error code into Google and view a stack overflow post with a similar problem. From there he took what the response on stack overflow said and crafted a solid solution to the issue. It took him about an hour and I saw that he had to Google a few functions (Python language) but he showed he knew the resources he needed and the basics to coding solutions to problems.<p>I don't care if you know how to create a linked list in C on a piece of paper or why we have round manhole covers instead of square, this isn't useful in the real world, I want to see if you can solve a real problem and the method you go about it.

We have candidates that make it through the first cut of "culture fit" interviews do an open ended coding project with some of our real data.<p>What they do and how long they take to do it is totally up to them. They can call a friend, use online resources, and even contact anyone at the company with questions. They present their project at their second interview.<p>It has been a great way to gauge technical, problem solving, and presentation skills as well as interest in our company.

All this interview crap is just that -- crap. It's a poorly performing, bureaucratic cover-your-ass piece of bullshit window-dressing that should largely go away. It's the interviewee crafting a word-picture of themselves that might as well be fictional while the interviewers are crafting an imaginary picture of the interviewee that might as well be fictional. The only way to figure out what it's like to work with somebody is to work with them.<p>EDIT: People have to communicate as part of their jobs. An interview is fine for determining that, because <i>that's what it is.</i> If you think it will help you determine how good they are to work with, or how well someone codes, you're living in a fantasy land.

Testing a candidate's ability to express themselves is a good idea, but there are probably simpler ways of doing it than phoning a friend. If you wish to test communication skills, ask them an open-ended question like "how does a browser/OS/compiler/database work?".<p>I wouldn't like put one of my friends in such a position when answering an interview question. Nor would I like to be (partly) responsible for a friend's performance in theirs.<p>Anyway, surely a candidate that can do the question on their own is better than one that can't. And surely the friend that can answer the question is better than the candidate?<p>A technical interview question shouldn't be about specific knowledge of particular problems (although bad ones often are, usually having "Aha!" moments). They should test areas of knowledge: reversing a linked list is checking if they <i>understand</i> how pointers work, something which is not really possible to <i>learn</i> in 5 minutes of Googling, even if they can then answer the question. Questions <i>should</i> test general technical problem solving skills, which are not easily Googled, even if a specific instance is.<p>Finally, if a candidate requires knowledge of a particular API (e.g. the order of parameters to a function), then the interviewer should tell them. If the interviewer doesn't know, then they must acknowledge that it's not really important, and allow the candidate to just pseudocode it.

That what practical tests are for. Throw a problem to solve, leave the programmer for an hour and see what he'll produce, while having normal access to the online world.<p>But you don't want to check encyclopedic knowledge during interview talk. You want to check how well he understands what he's doing, what is his approach to problems, what kind of problems did he solve in the past and how he did it, and lot of other things that don't require the only one correct answer (and cannot even be answered by one).

I let candidate ask me questions. If can't remember it either, I'll just allow the assumption that a method exists, as long as I know what it's doing (and it's not abstracting away anything core to the question I'm asking). In the same vein, I also explicitly allow pseudocode.

I've done the "google it" approach, so here's my .02<p>We talk to a lot of college grads. Clasically, colleges don't seem to teach a lick of web development. Just old-fashioned comp-sci uselessness. We know these kids are bright, but they're not going to be able to develop full stack out of the gate, usually, without some aide. We were all like that once.<p>What I want to see from a bright young talent is whether or not they know where to go to get the answer, and how quickly they can use it, and how quickly they can grok it. It doesn't take an incredibly long amount of time to start becoming useful to web dev with all the resources out there. I'm OK if they don't know some arcane bit of CSS, like that white-space: nowrap exists. They can and will find that information very quickly, and it's not difficult to remember, retain, or understand.<p>If I'm interviewing a candidate with a proclaimed 8 years experience in the industry, for a position of mid-to-senior level developer, they really shouldn't need that extra help. They should be shipping-ready (given the time needed to understand the idiosyncrasies of your company's style).<p>I've found that this approach has netted us a good deal of sleeper candidates that, on paper and on a white board, may not look like much, but end up being killer, driven developers.

I can see the appeal, if you're hiring for someone who can, eventually, figure out how to do what you want them to. However, if you're hiring for people with a common knowledge base (i.e. computer scientists), who will be required to think up novel solutions to problems that cannot be found online, then you're not going to get the right kind of candidate (and should, instead, be offering double what you would have to that friend who got the answer in 5 min, over the phone, with all the communication issues that presents, to what took the original interviewer 10 or 20+ minutes to figure out they couldn't do by themselves).<p>In short, if you're trying to hire someone to do work that's been done elsewhere many times before, then this is probably fine. But I don't expect the most innovative companies to ever want to filter for google skills.

I think this is a great idea in principle. Being able to learn and understand the solution quickly on the internet is a very valuable skill.<p>At the same time, there is deeper stuff that really isn't suited to this approach. If I were conducting an interview, I'd set the candidate a task the evening before their interview that involved something I knew they had know experience in, to see how well they can delve into and understand new tools.<p>A face to face interview is a great way to really understand how good a candidate's core knowledge is. Do they understand data structures and how to manipulate them? Do they understand algorithms and their complexity? Sure, you can look this stuff up, but it's the kind of knowledge you need to have before you even start.

Only if the interviewers are allowed to know the name and number of this friend :) Why bother with the person who can't answer the question when you can go directly to the goto guy? (and I say this as someone who's only ever been the interviewee).

It’s a shame that this post can even be deemed heretical when in fact it’s the normal mechanism for completing tasks by the vast preponderance of developers for overcoming technical challenges.<p>Understanding the ways in which technical people find answers, and can fully grok and socialize those answers internally with options is invaluable in a technical interview.

I think the phone-a-friend possibility is a lot more interesting because it does force the candidate to verbalize the problem and interpret verbal feedback. If you make them do it in front of you, you'll also get to see how they interact with other people under pressure and also how their friend treats their asking of the question will be revealing as well.

I don't see the point to this.<p>The purpose of any phone screen I've done is that it's simple enough that no self respecting programmer would have trouble with the questions, ie they are of the fizzbuzz variety.<p>The point being that if you need to "phone a friend" then you've probably already failed the interview.

I think that being able to "google it" is a technical skill by itself especialy for developers. For example, you are getting an exception in your code. How do you take that specific exception msg and figure out what to do with it. Do you just copy/paste the exact err msg in google and hope for a miracle ? Do you combine that err msg with some other keyword to get a more suited result ? Or do you just not use the err msg but google for the specific process you are trying to implement ? Depending on what you google, you could get different answers.<p>I think that if a developer knows <i>how</i> and <i>where</i> to look for the resources to solve a problem, he is worth a shot. I am sure if he has to look up "C++ syntax" when being interviewd for "experience C++ developer", then thats bad. You get the idea.

I would hire the friend since he can actually solve problems.

If you think this might be great for your hiring process, think about the questions you ask. In some cases it might be that you ask questions that hardly show candidates knowledge.<p>For instance, average and worst case complexity of various algos (usually sorting). This is kind of a question you might want a call/gooogle and I believe is common one. But I don't think it does make any difference in real-world practice whether you know (and can recall in a stressful situation) what is quick sort's worst case complexity and in what case it happens. If I need that, I will google it and find it less than 5mins. Obviously, awareness of worst-case is necessary but not memorizing for each algorithm.

I do variant number 2 all the time. I'm not interested in pop trivia. If someone wants to consult C++ STL docs, or unix manpages, or python library docs, that's fine. They just have to tell me they're doing it. Relying on what someone has memorized is silly.

The thing about interviews or any spoken communication. A lot of people just get really nervous. Even for the most basic questions.<p>What is your name?, "Fuck let me call in a life line".

This is a great idea

I think it's hokey to structure interviews on the model of a TV game show. Much better to see what they consider doing when they don't know the answer to a question, or suggest an approach to them in the moment to see their skills in finding information.