8 ms·

Allow “Phone a Friend” during Technical Interviews?

45 points by matan_a 14y ago

churnek 14y ago
This is a great idea
- gedrap 14y ago
  And this is a great contribution to the discussion
chollida1 14y ago
I don't see the point to this. 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. The point being that if you need to "phone a friend" then you've probably already failed the interview.
- testbro 14y ago
  If you allow the candidate to do what they'd do at their desk you can ask more than trivial questions. Certainly, if they have to ping google to figure out how to write fizzbuzz, that's a red flag, but it depends what the person spec is. How many positions would you estimate (I'm an academic so have no experience) where encyclopedic and gap-less knowledge is required to accomplish a task? I envision a technical interview as an opportunity to make sure the candidate can actually do the task you need them to - the screening of non-programmers should be done beforehand.
  - chollida1 14y ago
    > I envision a technical interview as an opportunity to make sure the candidate can actually do the task you need them to - the screening of non-programmers should be done beforehand. Ahh I see where we disagree, I might have read the blog post wrong. To me a phone interview is the actual screen. I'd never do an actual interview over the phone that was the basis for the final hire/no hire. If the OP means phone interview as the actual interview rather than a phone screen then yes, I'd certainly relax my position somewhat. usually for phone screens I'll open a shared google doc site and get the user to do a problem like fizz buzz.
stevewilhelm 14y ago
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. 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. It has been a great way to gauge technical, problem solving, and presentation skills as well as interest in our company.
- apawloski 14y ago
  This is a tough one, because I can see two sides of this pretty easily. In one sense, I can understand what makes this so valuable to an employer trying to evaluate a prospective employee. On the other sense, I'm reluctant to do free coding with production-level potential. Have you seen any resistance from applicants to this method?
  - wting 14y ago
    A balanced approach is use trial work as a level 2 filter and pay the applicant contract rates for a day / week. If the person turns out to be a no hire, you managed to avoid an expensive false positive.
  - stevewilhelm 14y ago
    We have already done the culture fit interviews. We only extend the opportunity to work on the project to people we want to hire if their technical skills meet our expectations. If that isn't clear to a candidate when they are offered the project, or if they still are reluctant, then they aren't a good fit for us anyways.
chucklarge 14y ago
I would hire the friend since he can actually solve problems.
- fusiongyro 14y ago
  It doesn't seem likely to me that the friend wants the job.
racbart 14y ago
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. 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).
mjmahone17 14y ago
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). 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.
- bearmf 14y ago
  An interesting question is if Google itself would consider "google skills" an advantage!
yakshaving 14y ago
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. 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.
- illuminate 14y ago
  The applicant can already do this, in asking the right sorts of questions from the interviewer to help them solve whatever rut they've found themselves in.
npsimons 14y ago
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).
dclowd9901 14y ago
I've done the "google it" approach, so here's my .02 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. 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. 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). 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.
- elliottcarlson 14y ago
  > Just old-fashioned comp-sci uselessness. Yet so many interview tests tend to have a focus on CS backgrounds. I just went through a few weeks of interviewing and some of the questions asked were really there to see if you knew your CS stuff. For some companies the questions were at least relevant to the industry and tasks they were trying to accomplish, but some were so far out there it just didn't make sense. The company I finally decided to accept at had a sane interviewing process, one that had challenging enough questions to show that you know what you are talking about - and when there was one lesser known method I wanted to use, but couldn't remember the syntax, they allowed me to look it up real quick. In the end, I was able to teach the interviewer about this method, and it helped me complete the task in a far more efficient manner.
- fusiongyro 14y ago
  > Just old-fashioned comp-sci uselessness Everything you're saying is reasonable but this phrase reminded me, one of my favorite profs used to say, "Knowing about computational complexity won't ever get you a job, but it will keep you from being fired." Several times I've started a job and discovered my predecessor had coded himself into a corner because he didn't see the combinatorial explosion on the other side of what he was doing.
fredley 14y ago
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. 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. 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.
largesse 14y ago
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.
lizthegrey 14y ago
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.
fusiongyro 14y ago
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.
mseebach 14y ago
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.
- logn 14y ago
  This is my vote. Open up a dialog between interviewer and interviewee. Everyone can use a hint sometimes and it gives a chance to have a technical discussion. That being said lately I worked hiring contractors. We give them a week long paid trial assignment (paid if they pass). Half the people I hire I don't even have a resume for. This is really the best way to hire people.
  - jacalata 14y ago
    No, the best way would be paid even if they fail. Making someone work for you for a week for free is horrific.
    - illuminate 14y ago
      Yes. This appears to be massively exploitative. They should never get to the point of hire if they're too unqualified to be paid.
      - logn 14y ago
        I happen to agree but I have no say in this. If it mitigates this at all, the trial assignment is not actual work. It's been solved many times and the candidates who are good do it in 2 days, not much different than the time it takes to do an extensive round of interviews.
Jabbles 14y ago
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?". 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. 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? 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 understand how pointers work, something which is not really possible to learn in 5 minutes of Googling, even if they can then answer the question. Questions should test general technical problem solving skills, which are not easily Googled, even if a specific instance is. 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.
- bencollier49 14y ago
  I agree. Generally, open ended questions give you a pretty good idea of a candidate's aptitudes. I had a guy come to interview who'd supposedly got a CS degree with first-class honours from a fairly well-ranked British uni. He couldn't tell me what functional programming was, which I thought was pretty peculiar. I tried to call the uni to verify his degree but they wouldn't confirm it without consent (Data Protection Act), and I wasn't going to employ him (for several reasons), so I didn't take it any further.
  - Jabbles 14y ago
    I agree. Generally, open ended questions give you a pretty good idea of a candidate's aptitudes. I would still have to test their ability to code something, as I know how good I am (if I may say so) at blagging my way through open ended questions.
  - 14y ago
overshard 14y ago
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. 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. 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.
- codegeek 14y ago
  This. Technical interviews are important but their purpose should not be to check whether you know a particular function/API whatever. Their purpose should be to take a real world problem and show the interview how you resolved it. Sure, remembering specific details of a technical subject is always handy but just because I don't remember the function that does task 'x' in language 'y', doesn't mean that I cannot use it.
- eksith 14y ago
  This is pretty much exactly how I got hired. In my case, I had to show design capabilities in addition to code and being creative didn't mean just applying hacks found on the internet. But my boss had to actually see if I can get through with building the project using a combination of existing knowledge and the ability to find solutions. My challenge was to build a discussion forum from scratch with user registration and a reasonably attractive UI. So that's PHP + Photoshop + CSS/HTML/JS
  - reefoctopus 14y ago
codegeek 14y ago
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. I think that if a developer knows how and where 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.
stcredzero 14y ago
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. EDIT: People have to communicate as part of their jobs. An interview is fine for determining that, because that's what it is. 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.
gedrap 14y ago
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. 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.
berlinbrown 14y ago
The thing about interviews or any spoken communication. A lot of people just get really nervous. Even for the most basic questions. What is your name?, "Fuck let me call in a life line".

45 points by matan_a 14y ago

churnek 14y ago

This is a great idea

gedrap 14y ago
And this is a great contribution to the discussion

chollida1 14y ago

I don't see the point to this. 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. The point being that if you need to "phone a friend" then you've probably already failed the interview.

testbro 14y ago
If you allow the candidate to do what they'd do at their desk you can ask more than trivial questions. Certainly, if they have to ping google to figure out how to write fizzbuzz, that's a red flag, but it depends what the person spec is. How many positions would you estimate (I'm an academic so have no experience) where encyclopedic and gap-less knowledge is required to accomplish a task? I envision a technical interview as an opportunity to make sure the candidate can actually do the task you need them to - the screening of non-programmers should be done beforehand.
- chollida1 14y ago
  > I envision a technical interview as an opportunity to make sure the candidate can actually do the task you need them to - the screening of non-programmers should be done beforehand. Ahh I see where we disagree, I might have read the blog post wrong. To me a phone interview is the actual screen. I'd never do an actual interview over the phone that was the basis for the final hire/no hire. If the OP means phone interview as the actual interview rather than a phone screen then yes, I'd certainly relax my position somewhat. usually for phone screens I'll open a shared google doc site and get the user to do a problem like fizz buzz.

stevewilhelm 14y ago

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. 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. It has been a great way to gauge technical, problem solving, and presentation skills as well as interest in our company.

apawloski 14y ago
This is a tough one, because I can see two sides of this pretty easily. In one sense, I can understand what makes this so valuable to an employer trying to evaluate a prospective employee. On the other sense, I'm reluctant to do free coding with production-level potential. Have you seen any resistance from applicants to this method?
- wting 14y ago
  A balanced approach is use trial work as a level 2 filter and pay the applicant contract rates for a day / week. If the person turns out to be a no hire, you managed to avoid an expensive false positive.
- stevewilhelm 14y ago
  We have already done the culture fit interviews. We only extend the opportunity to work on the project to people we want to hire if their technical skills meet our expectations. If that isn't clear to a candidate when they are offered the project, or if they still are reluctant, then they aren't a good fit for us anyways.

chucklarge 14y ago

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

fusiongyro 14y ago
It doesn't seem likely to me that the friend wants the job.

racbart 14y ago

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. 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).

mjmahone17 14y ago

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). 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.

bearmf 14y ago
An interesting question is if Google itself would consider "google skills" an advantage!

yakshaving 14y ago

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. 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.

illuminate 14y ago
The applicant can already do this, in asking the right sorts of questions from the interviewer to help them solve whatever rut they've found themselves in.

npsimons 14y ago

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).

dclowd9901 14y ago

I've done the "google it" approach, so here's my .02 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. 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. 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). 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.

elliottcarlson 14y ago
> Just old-fashioned comp-sci uselessness. Yet so many interview tests tend to have a focus on CS backgrounds. I just went through a few weeks of interviewing and some of the questions asked were really there to see if you knew your CS stuff. For some companies the questions were at least relevant to the industry and tasks they were trying to accomplish, but some were so far out there it just didn't make sense. The company I finally decided to accept at had a sane interviewing process, one that had challenging enough questions to show that you know what you are talking about - and when there was one lesser known method I wanted to use, but couldn't remember the syntax, they allowed me to look it up real quick. In the end, I was able to teach the interviewer about this method, and it helped me complete the task in a far more efficient manner.
fusiongyro 14y ago
> Just old-fashioned comp-sci uselessness Everything you're saying is reasonable but this phrase reminded me, one of my favorite profs used to say, "Knowing about computational complexity won't ever get you a job, but it will keep you from being fired." Several times I've started a job and discovered my predecessor had coded himself into a corner because he didn't see the combinatorial explosion on the other side of what he was doing.

fredley 14y ago

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. 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. 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.

largesse 14y ago

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.

lizthegrey 14y ago

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.

fusiongyro 14y ago

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.

mseebach 14y ago

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.

logn 14y ago
This is my vote. Open up a dialog between interviewer and interviewee. Everyone can use a hint sometimes and it gives a chance to have a technical discussion. That being said lately I worked hiring contractors. We give them a week long paid trial assignment (paid if they pass). Half the people I hire I don't even have a resume for. This is really the best way to hire people.
- jacalata 14y ago
  No, the best way would be paid even if they fail. Making someone work for you for a week for free is horrific.
  - illuminate 14y ago
    Yes. This appears to be massively exploitative. They should never get to the point of hire if they're too unqualified to be paid.
    - logn 14y ago
      I happen to agree but I have no say in this. If it mitigates this at all, the trial assignment is not actual work. It's been solved many times and the candidates who are good do it in 2 days, not much different than the time it takes to do an extensive round of interviews.

Jabbles 14y ago

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?". 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. 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? 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 understand how pointers work, something which is not really possible to learn in 5 minutes of Googling, even if they can then answer the question. Questions should test general technical problem solving skills, which are not easily Googled, even if a specific instance is. 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.

bencollier49 14y ago
I agree. Generally, open ended questions give you a pretty good idea of a candidate's aptitudes. I had a guy come to interview who'd supposedly got a CS degree with first-class honours from a fairly well-ranked British uni. He couldn't tell me what functional programming was, which I thought was pretty peculiar. I tried to call the uni to verify his degree but they wouldn't confirm it without consent (Data Protection Act), and I wasn't going to employ him (for several reasons), so I didn't take it any further.
- Jabbles 14y ago
  I agree. Generally, open ended questions give you a pretty good idea of a candidate's aptitudes. I would still have to test their ability to code something, as I know how good I am (if I may say so) at blagging my way through open ended questions.
- 14y ago

overshard 14y ago

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. 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. 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.

codegeek 14y ago
This. Technical interviews are important but their purpose should not be to check whether you know a particular function/API whatever. Their purpose should be to take a real world problem and show the interview how you resolved it. Sure, remembering specific details of a technical subject is always handy but just because I don't remember the function that does task 'x' in language 'y', doesn't mean that I cannot use it.
eksith 14y ago
This is pretty much exactly how I got hired. In my case, I had to show design capabilities in addition to code and being creative didn't mean just applying hacks found on the internet. But my boss had to actually see if I can get through with building the project using a combination of existing knowledge and the ability to find solutions. My challenge was to build a discussion forum from scratch with user registration and a reasonably attractive UI. So that's PHP + Photoshop + CSS/HTML/JS
- reefoctopus 14y ago

codegeek 14y ago

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. I think that if a developer knows how and where 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.

stcredzero 14y ago

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. EDIT: People have to communicate as part of their jobs. An interview is fine for determining that, because that's what it is. 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.

gedrap 14y ago

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. 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.

berlinbrown 14y ago

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