"you should try to find out if any of these failed candidates are actually skilled developers but there's something about the questions or interview that's messing them up?
hard to think of a halfway competent developer failing to answer
"where I ask them to implement a simple function, implement a recursive function, write a simple SQL select (join across two tables), and create a simple object model (how would you represent a car as an object)."
in about a minute or so all told, even verbally, over the phone.
"YouTube phone interview because they asked me to "say" a function for finding the longest common subsequence of a set of strings."
This is (ever so slightly) different from OP's ultra simple questions above , but otoh , YouTube has a lot of tough algorithmic problems to solve. I am not sure what position you interviewed for, but the question itself sounds decent for a position that could involve algorithms and searching and so on. Now if the interview were for a job involving "code up a basic enterprise app" I can see how it could be inappropriate.
All that said, I am not a fan of extended phone interviews , but asking very basic questions (as the OP seems to have done) eliminates a surprisingly large number of looks-good-on-paper-but-can't-code-for-nuts type "programmers".
The key to not getting depressed is not to waste any time on people who can't answer ultra basic questions. If in 30 seconds you feel someone is too incompetent, shut the conversation down politely. Spending long periods of time with incompetents is depressing.
One solution is to send a (moderately complex) programming problem by email and ask them to send code back. This will weed out a lot of people without wasting your time.
I agree. The questions the OP asked are all very easy. It'd be easy to describe a function to find the longest common subsequence of a set of strings as well. The reason such a question is asked is because it isn't something that we do everyday and how we solve problems that we don't immediately know how to solve is what sets good programmers apart from bad programmers.
I find anyone who immediately blames the environment for their lack of ability to answer the questions correctly to be suspect. These types of complainers are externally motivated and will never accept fault for their lack of capabilities. "You should have asked me in a different way." or "I need to be taught differently" or "There's too much pressure"... look, you can come up with whatever excuses you want, but the fact is, you can't solve the problem and what we are looking for is someone who can solve problems.
If you ask me, having someone say a function over the phone just sounds stupid. If you're going to have them say it, why not have them SING it instead? Would be more entertaining, and since the way they're doing it doesn't matter, what the hell?
I don't say SQL queries out loud, and trying to do so would probably screw me up; I don't know about you, but I don't sit down to write stuff and get it perfect every time. I often start writing a query, go back and adjust something, start working on another part, tweak this or that, and then finish. You can't do that when you're forced to say something over the phone. And I don't solve problems I've never come across by just starting to code on my own and see where it gets me; especially when it sounds like the kind of problem that someone else out there, probably smarter than me, has already solved. AND I wouldn't want to hire anyone who took that approach. Sometimes, it's fun to reinvent the wheel, especially when you're trying to learn things, but I wouldn't want my developers sitting around all day reinventing everything.
If you really want these people to do these things, plop them down in front of a computer, give them a time limit of x minutes, leave the room and come back and see where they are. This relieves the pressure of you standing over them watching them, gives them time and space to work the problem out, and is much closer to how they'll eventually be working...unless you work at some freaky place where the boss stands over your shoulder and watches you type all day long, in which case I feel sorry for you.
I totally agree, but I also think that introverted programmers work better in the situation you describe, whereas extroverts feel better about talking-out solutions, even over the phone. Don't get me wrong, I'm not calling you an introvert, but I, as an introvert, have experienced this.
Don't forget, our society rewards extroverts, is built for extroverts, and this is one way the ruling extroverts can weed out introverts.
There are definitely people who are capable of solving problems but whose performance drops appreciably under pressure. Now, you may not want to hire those people, but that doesn't mean it has anything to do with external motivation or making excuses, and you can keep your contempt for yourself.
There are many different kinds of pressure. The pressure in an interview is very different from the kind of pressure experienced when the database is down.
For example, I have no problem at all with on-site interviews but I choke pretty easily during phone interviews. I also have no problem with public speaking, but I have trouble engaging people I don't know in one-on-one conversations.
As an employer, I want employees who can solve problems whether they are under pressure or not. You really want an employee working for you, or even a team member in your group who can't work under pressure when your site is down and they are the only one who can fix it? If you can't work under pressure, you can't work. Or maybe you can work, but I'd rather work with someone who can work under pressure or who can't. That's my point. And I believe it has a lot to do with external motivation. I apologize for the contempt.
Under pressure and "in a strange environment" are two different things. You could put interview candidates in SCUBA gear and take them down 5 fathoms to see how they'd do under pressure, but that's also completely unrelated to predicting their actual job performance.
We don't ask trivia questions (what's the order of arguments to fputs, list all the overloads of foo in class bar) because knowing that (or anything else that's a 5 second lookup or context-sensitive help away) doesn't predict how someone will actually perform on the job.
Can any of us code as effectively on a whiteboard as we could in our favorite editor? I'd expect not, and if you were equally able on a whiteboard as in an editor, I'd wager that it's because you're not particularly good at either.
One thing I learned a while back at one interview (or rather, I just worked it out after experiencing it a few times) is that I find it much harder to think/code on a whiteboard. I don't know what it is, but it seems much easier for me to sit down with a pen and paper and work things out.
I mean, still coding without a computer - but it's something about standing up at a whiteboard. Maybe it's normally not so bad for me, but with the pressure of an interview, it's bad enough to give me problems.
I don't think it is only about pressure. I can think up a solution to a problem in my head, but to really work it out I have to be behind my computer and start typing. I almost never get something right in 1 try.
I think my style is more trial and error, I make something and see if it works, if not I continue. So of course, a lot of great programmers actually are able to do that, but I think there are also a lot of people who work like I do.
Are you saying that the context and type of the problem in the interview doesn't matter at all?
I think you'd understand how I can take your argument to its extreme conclusion and justify posing psychotherapy problems to candidates.
You're seeing complaining where there isn't any. It's in the employers interest to ask questions that will narrow down candidates in a way that best fits the job. Putting candidates under extremely unusual circumstances and pressure to answer unrelated questions is only going to help you know how the candidate responds to unrelated questions under extremely unusual circumstances, and pointing this out is not complaining. Acknowledging that a high pressure phone interview does not accurately reflect your abilities is not complaining either.
Are you saying that the context and type of the problem in the interview doesn't matter at all?
I think it doesn't matter if it is consistent for all the candidates. A company can't change to suit every employee. Working for a startup like Youtube is high pressure. You have to be very self-aware and able to work under extreme circumstances. When your app crashes and millions of people are angry, you have to fix it! You can't create a special case scenario for your employees because they need to work in a stress free environment.
Of course that is a simple case, but high stress engagements occur at some point in almost every environment and how the candidate reacts to the high stress is very important, perhaps the most important.
IMO, it is more important for the employee to adapt to the environment than for the environment to adapt to the employee. Every candidate is going to want questions asked a different way. Every candidate is going to want their cube to be a different color -- that's why they are all gray or beige.
My point is, if you want A players on your team, you will be well served to waste as little time as possible on candidates that want you to ask them interview questions the way the candidate wants them asked and focus your attention on candidates that correctly answer the questions how the interviewer wants to ask them.
This is not a question about whether an interviewer needs to customize the questions for each interviewee. This is about a possible mismatch between the environments of the interview versus the workplace and the relevance of the questions to the actual job.
You make a case for developers needing to be able to handle "high stress" or "high pressure" conditions. Those are pretty broad terms, as they could mean anything from "very competitive and high standards" to "quick firefighting emergency work 24/7" to "your boss will micromanage the living hell out of you". So, in effect, you're saying, "Look, you complainer, working for YouTube is like being in a phone interview all day." All I can say is that if that is true, I am certainly not a match.
>One solution is to send a (moderately complex) programming
>problem by email and ask them to send code back. This will
>weed out a lot of people without wasting your time.
This is I think the best solution. A friend works at a company here called Tachyon and they have this part as part of the form on their jobs site where you can apply for jobs.
http://tachyon.in/jobs.html
hard to think of a halfway competent developer failing to answer
"where I ask them to implement a simple function, implement a recursive function, write a simple SQL select (join across two tables), and create a simple object model (how would you represent a car as an object)."
in about a minute or so all told, even verbally, over the phone.
"YouTube phone interview because they asked me to "say" a function for finding the longest common subsequence of a set of strings."
This is (ever so slightly) different from OP's ultra simple questions above , but otoh , YouTube has a lot of tough algorithmic problems to solve. I am not sure what position you interviewed for, but the question itself sounds decent for a position that could involve algorithms and searching and so on. Now if the interview were for a job involving "code up a basic enterprise app" I can see how it could be inappropriate.
All that said, I am not a fan of extended phone interviews , but asking very basic questions (as the OP seems to have done) eliminates a surprisingly large number of looks-good-on-paper-but-can't-code-for-nuts type "programmers".
The key to not getting depressed is not to waste any time on people who can't answer ultra basic questions. If in 30 seconds you feel someone is too incompetent, shut the conversation down politely. Spending long periods of time with incompetents is depressing.
One solution is to send a (moderately complex) programming problem by email and ask them to send code back. This will weed out a lot of people without wasting your time.