Ask YC: Does interviewing developers leave you depressed? | Hacker News Reader

Ask YC: Does interviewing developers leave you depressed?

41 pointsFlemlord124 comments

I'm hiring a senior developer right now. Our first interview has a 4-question screen, 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).

~70% of the "senior developer" applicants fail

We're extremely happy with our process--this is only step 1--and it's been amazing at yielding a great set of candidates for each hire, but two weeks of administering the tech screen to applicants leaves me a bit depressed. (sigh)

View on HN

Just out of personal curiosity, 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?

For example I consider myself a reasonable programmer, I can certainly do any project put in front of me. But I failed a YouTube phone interview because they asked me to "say" a function for finding the longest common subsequence of a set of strings.

I learned the following issues completely stop me from being able to program:

1. Someone waiting on an immediate answer.

2. Someone watching/listening to my though process.

3. Not being able to experiment with the code on a computer.

That didn't cut it for them because apparently at YouTube a lot of your programming is done over the phone (sarcasm).

I guess my point is, try to think of the exact tasks this hire would be doing, and ask them to do that. Will they really be writing recursive functions often? Also if possible give them a take home project, so they can work in a more natural environment.

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

Case closed.

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.

Case appealed.

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.

This is @ pj:

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.

Appeal denied.

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.

OK ALRIGH

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

I agree. When I first meet someone over the phone or in person I'm in a social mood and prefer to talk rather than do a code dance for them.

Once I'm alone at my desk though it's easy to get down to business.

Think it would be cool if companies just said show up to work, and you work for free for the first week. After that both parties can decide if they want to continue.

Maybe it's just me, but I tend to immediately discount any advice or proposals that suggest I work for free.

I would actually enjoy a one week type engagement to get a good fit for a company.

It works both ways. You are selling your time. They are selling their environment.

The problem is that the employer is accepting a lot more risk than the employee. Do you like paying for something you can't return and you can't get your money back for if it is crap? This is the situation a lot of companies are in. They hire someone, they pay them to write the code or build the project and it turns out it's all a lot of garbage and the company is out the money.

This problem is really tainting our industry. I think a lot of people who call themselves programmers are really just some kids off the street who grabbed an open source package and started hacking away. They can build a website with some graphics and stuff, but they have no vision, no experience with large systems that are actually going to be used for any significant period of time.

It is quite depressing actually.

Set aside the whether or not you get paid for the week's trial period for a minute.

How the hell does someone with a job arrange to take a week off to do this trial period for another company? Maybe it works for entry-level or the unemployed, but I don't think you'll find a lot of good senior developers who would be able to make this arrangement work. I've taken jobs entirely based on their interview process. "If I made it through that, and everyone else I'll be working with also did, I'm pumped to work with these people!" Same benefit would apply to the week long trial, but making it work logistically is difficult.

I would actually enjoy a one week type engagement to get a good fit for a company

So would I. But since I'm WORKING for that one week, I expect to be paid for it. I really don't think anyone should be surprised by that!

Hmm... I see your point. Perhaps we disagree on the word "work." When I think of "work" I think of moving a company in a desired direction.

A lot of people think of work as "sitting in a cube."

The question is, "How do we determine if the candidate's definition of work matches the employer's definition of work?"

Maybe what you think you are doing when you are working is actually causing more problems and moving the company backwards because they are going to have to undo all the crappy code you wrote. I'm not meaning to attack you, I'm just trying to illustrate a point. Know what I mean?

Maybe such an engagement could work out where, "If we hire you, we pay you for the week. If we fire you, we keep the money and you are out."

This reduces the risk for the employer while also giving the employee a chance to examine the company and be paid if the work is satisfactory.

Or perhaps better: the week's pay is given to the new employee if hired, or to a mutually-agreed charity if not hired. Then there's no financial incentive for the company to cycle through candidates for a free week's consulting.

Excellent! I really like this idea. I'm going to work on how to implement this in my hiring strategy.

Makes no difference: they hired me, they pay me. Doesn't matter if I create $1M in profit that first week or I sit there with my thumb up my ass. If I'm there I expect to be paid for it.

Furthermore, I have no interest in reducing the risk for the employer: I expect them to do that. I reduce my own risks. If I'm the employer, then of course my perspective will shift 180deg.

FFS, it's a job, not a hobby!

I think pj's suggestion is a means of reducing the risk to the employer. The way they reduce their hiring risk is to make sure you can do the job before hiring.

> This reduces the risk for the employer while also giving the employee a chance to examine the company and be paid if the work is satisfactory.

How about a one week stipend. You're view point is too company-centric, I MUCH prefer to work for people-centered companies. Either way you need something a little more symmetric if you don't want to become standard laughing stock among developers. (Or maybe you and your-co are so badass you can't do wrong and developers intrinsically trust you so it doesn't matter.)

What are you going to do in one week at a place? It could easily take that long and much longer to ramp up and even understand a part of the existing code base.

I've gone into a company with software systems that were a complete rat's nest, learned the enviroment, accessed files and utilities needed to make changes, and implemented a significant change in 2 days. A lasting and flexible change that will enable the company to operate more cheaply and be more agile in the future.

Many information systems can be implemented in a week. You could set up email, an e-commerce site, a CRM, SCM, or even substantial portions, if not an entire ERP system depending on the size of the company.

A week is a long time if you know what you are doing.

Ah, the area where we disagree is on the size of the company in question. I was thinking medium to large, while it looks like you are thinking more start-up. I agree that a week is much more viable to assess someone in a startup. In a large corporation, they'll be lucky to have a computer by then!

Agreed. I don't respect a company that won't give a person two weeks to get the feet wet... i.e. set up dev station, learn the network topology, and bone up on the development stack.

By not letting someone acclimate to your tech environment, your potentially shoving them off on the wrong foot (not to mention stressing them the fuck out,,,which WILL kill their productivity). A mistake that could cost you months of 50% productivity because you didn't (as a company) empower your developers to do their best work.

When I see managers pulling some "whip them harder" management styles, I can't help but be left with the want to remind them about the french revolution. Pointy-haired bosses will soon figure these things when "their" work force becomes a bit too empowered.

The question is, "How do we determine if the candidate's definition of work matches the employer's definition of work?"

Well, the candidate would be giving away a week of his time, which can be a bit problematic. How would you arrange this if the candiate was already employed?

He'd take a week of unpaid vacation from his current workplace, and give it away on a chance he might want to switch jobs and be accepted? Besides, 1/4 of your monthly salary is definitely a noticeable loss.

What if this was a common practise? "Oh well, this didn't work out. I'll take another week of unpaid vacation to try out for that other company then"..

A lot of people think of work as "sitting in a cube."

Working for some place means exchanging your time for money. Whether that time is spent coding with a burning passion, moving a company in a desired direction, or looking at lolcats is another matter.

I think show up and work for a week - with your old pay + 20%, then we'll talk about further negotiations - (perhaps another 10% or so) ... or we can both walk away.

I know a bunch of smaller startups that do the "come in for a week and we'll decide" out here in the bay area. Peanut Labs, e.g.

I've also seen a lot of "contract for hire" jobs at larger companies that are short (3-6 month) contracts, with an understanding that they are evaluating whether to hire you full-time at the end of the contract. If not, you still got some contract work and can move on.

That's basically how open source works.

I thought it was very common practice to have a [paid] probation period, where the company is free to keep someone or let them go. Usually the period is less than 6 months. That seems a sensible approach to making sure your hiring decision was good or not.

Under US law (in most states), the company is free to let someone go at any time barring a specific contract to the contrary. I guess if you tell someone the first n months are a probationary period, they'll have their feelings less hurt if they're fired during that period.

That's a really good idea. If wish we had that too.

oh man, this is my downfall as well. hearing stories about the way google conducts interviews convinces me that i'll never get in there, or anywhere like it.

i'm perfectly willing to write code as part of a job interview. just not on a whiteboard or over the phone.

i'm perfectly willing to write code as part of a job interview. just not on a whiteboard or over the phone.

why not on a whiteboard?

Like I mentioned, I just get flustered when people are watching me, or want me to speak my though process aloud.

Those skills, (being able to code complex problems when people are watching) have never been a requirement of any job I've seen so I've come out of many interviews feeling that they got an inaccurate picture of my skills.

It's a skill that can be practiced, though. And it might come in handy in general discussions, not just in job interviews.

With some preparation, you can transform the problem from one that may not be part of your job (solving completely new problems in front of an audience) to one that certainly will - explaining your solution clearly to an audience.

If you try hard enough, you can be familiar with likely interview questions and then the problem is how best to present your solution, which is an important skill, and one worth practicing.

Really? You never get together in a room with other devs to talk through & pseudocode a solution to a tough problem?

Yeah, I guess it's different with people I know. And to already be familiar with the problem helps too.

But to solve something say from project Euler on a whiteboard in front of three strangers and talk about my thought process at the same time, that's hard.

No, that sounds about right. 70% of the people you interview will not be able to code their way out of a sack. It actually sounds like he must have done some form of initial screen just to get the success rate up to 30%.

We are currently going through the same daunting process trying to hire a PHP developer at CollegeHumor. I would say 70% of the applicants we interview cant answer basic computer science questions. We don't give a written technical test. We don't expect a developer to be able to code on paper. In a real environment they have access to tools, compilers, docs, etc. It's an unfair and unnecessarily stressful test.

Good luck with your search.

Shameless plug: If your interested in a development position at CollegeHumor in New York City... Email techjobs@connectedventures.com.

Companies could always do the interview on a tool such as etherpad.com so they could watch the interviewee write.

because they asked me to "say" a function for finding the longest common subsequence of a set of strings.

That's rough, asking for a solution to an NP-hard problem over the phone? http://en.wikipedia.org/wiki/Longest_common_subsequence_prob...

Or maybe they were just expecting you to say "for each combination of subsequences of each string, check if they are equal ..."

We may be mishearing their intended formulation, which could have been asking for the longest common substring (described here: difference is that subsequences don't have to be entirely contiguous, just in the same order.)

http://en.wikipedia.org/wiki/Longest_common_substring_proble...

That's an interesting problem with some simple solutions worth understanding. I don't think it would be unrealistic to expect a high-quality programmer to be previously familiar with it, or, if not previously familiar, to be able to make progress toward the DP solution with some thought.

"We may be mishearing their intended formulation, which could have been asking for the longest common substring "

Good Point. And asking a clarifying question would be a very strong positive in a candidate.

No, they wanted a working function. I used Python :-(

I got asked to write a fibonacci function in an interview once, but they were kind enough to say "go sit at your text editor and write it and then read it to us". I was still flustered a little (since I wasn't sure whether to just talk through it or actually say "int fibs open-parent int n close-paren open-brace...") but apparently I passed the phone screen. I did remark that the naive recursive approach was a terrible algorithm, which may have helped.

Of course, I failed their day-long battery of on-site interviews later. But I did get interviewed by the entire development team, plus the CEO. That was kind of fun.

Senior Developer does not always mean coder. It means, in my view, senior-level experience and senior-level judgment.

What are the job requirements?

I was a manager for 10 years and didn't code except to fix bugs. When I coded, I used C/C++. As a senior manager, I oversaw the JavaEE application strategy at Sun.

At any rate, today, I am a Senior Developer at a start up that uses LAMP. I would have no problem answering your questions today but it took me a full month to get back up to speed.

It may be that you are focusing on the wrong questions, it may be that your job description is attracting the wrong candidates, or it may be that you are not promoting the job in the right channels.

Good luck.

Not depressing at all, completely representative of the job pool.

The technique you're using isn't common - a lot of traditional companies don't interview on skill and technique (like Google do).

Backing up your 70% of failures, we recently hired a fashion designer at our startup (we're in an interesting market!) I decided we should use the same kind of interview we would for a developer.

Everyone we interviewed was completely baffled, but it really sorted out the wheat from the chaff. At least 80% of the people we interviewed couldn't do what they said.

Thankfully though, we've ended up with someone who is really incredible. In fact, I think she has the 10x higher productivity that us developer types talk about, and her old employer is trying to hire her back.

tl;dr - looks like you've got a normal pool of applicants!

what is an objective interview for a fashion designer like?

Difficult. IANAFD so this may be slightly technically inaccurate:

We got them to actually draw something (called a flat) from a half-drawn garment, draw a full flat from scratch, identify trends from a series of photos, pick textile colours from photos, identify designers from "signature" garments, have them debug a spec. to see if a garment was reasonable (say the spec called for a notion like a chunky zip on an unsuitable fabric), and a few other things.

I would be careful with your questions. There's a lot of bias that you can create without being aware of it.

I once had an interviewer ask me for the five rules of database normalization. Beat the heck out of me at the time -- I was just drawing a blank. I could do the work all day long, but I couldn't remember the stupid names he was looking for.

Similarly, I had a guy ask me to name the seven categories of this course he was interested in that I had taught years ago. Same deal -- just couldn't recall it, although I was very familiar with the material and had no problem teaching it.

The problem with memory questions is that they bias against people who don't currently have the answer in working memory. Simply because somebody has done something recently is no indicator of performance. The best interviews warm up on general questions about the material before diving deep. That gives a candidate time to "change gears"

I also very interested in "why" questions over "how" questions. Classrooms and cram-lessons are really good at "how" questions -- it takes some degree of actual work to understand the "whys" of something.

I've interviewed a lot of developers over the years. 99% of them really aren't anywhere near as good as they think they are. That's sad, but it's also an opportunity for developers who care about their work to get ahead. It doesn't take much ongoing effort to be truly outstanding.

Good developers get hired and removed from the pool. Bad developers go to the next interview.

http://lesswrong.com/lw/gy/you_are_not_hiring_the_top_1/

That doesn't imply the top 1% isn't there; just that they are more likely to be under-represented. Also, programmers are prone to move to new areas that are more interesting, especially the top/best, so that can skew it back in favor of the upper echelons. It always seems that the mid range to bottom developers are more likely to find somewhere and stay, as they have so much trouble finding a new place to go to. They are the ones that have 'stickyness'.

What is the biggest factor, from what I can tell, is that the best don't send out their resumes but get poached by other companies or use their networking to land a job.

This theory may also apply to VC funding.

do you screen them over the phone? seems to me like it would be much easier and less depressing if you just gave them the work, gave them an hour, and told them to email the results back to you. stuff that is nontrivially difficult such that they can't just search and find answers. they have to know.

edit: i think i'd prefer having to do this myself, as well, because i'm a shy person in person and i find myself floundering when i'm on the phone and have to "explain my thought process" to someone as i'm working through it. i'd much rather write down an explanation.

I think "quiz" type of questions are pretty ineffective at filtering out candidates. You do filter out the bad candidates, but great ones could also be left behind. Who knows, the person could be an brilliant developer who got nervous during the interview and had a blank. Or the phone call is breaking up. Or the person is in a non-ideal location. Etc... I would not filter out a potential hire just because the person couldn't remember the SQL syntax on the spot...

For me, a senior developer is someone who is able to work in a TEAM, be dependable (i.e.: The guy who you can call at the 3am with an urgent matter), mentor others and be able to contribute and implement new processes and practices. The technical stuff is important but should not be the main filter IMO.

It also seems to me that you want to apply a certain logic or algorithm to the process. Personally I prefer to call up and just have a conversation with the person (trying to find out the aspects I listed above). Unless I am Google and I am getting a gazillion applications, that's different...

i can agree with this. i don't like quiz types of questions either. if i were to hire someone, i'd rather hire someone who i know i can rely upon to get a job done, regardless of their knowledge. someone who knows how to teach themselves, who is able to learn and learn quickly.

but, i still think that a longer-form, more essay-like quiz is better than grilling someone over the phone and expecting them to continuously talk to you while they're working through something.

I agree. I used to make the mistake of screening on language trivia and simple functional ability (like they're doing here). HUGE mistake.

Now I screen on much bigger topics that tend to be more philosophical in nature. The role of design patterns, benefits of one language over the other (particularly functional languages), value of unit tests...

They submit their answers via e-mail, and within a minute or two I already know if there is any value in at least talking to them in a more formal interview setting. I've found that folks who understand development at this much higher level always handle the basics well.

Are you depressed because your filter has proven very effective? It seems you should be happy. ;-)

The thing to worry about with a very discriminating filter is, like tocomments post, whether you are filtering for something different from what you really want...

Yes, it is depressing.

That said, I've had success with doing the pre-screen in a Campfire room and asking them to Pastie/Gist their code into the room. That way, you eliminate some of the weirdness associated with coding over the phone, but you maintain much of the immediacy.

That's exactly what I do. The first interview is over the phone and they type out their answers over a WebEx link.

For my current job (for an entry level position), I took a one hour test asking to do pretty basic coding prior to interviewing with anyone. It asked to find errors/poor practices in a code snippet, some quick logic/binary operations, and a larger question involving linked lists that required a few minutes of planning before I began writing code out.

This was a comfortable setting for me. Though in previous interviews, I would completely freeze when someone wanted a technical explanation, simply because I need a moment to collect my thoughts, and it's difficult to do so when someone in front of you is looking for an immediate answer.

The only ones that somewhat depress me is a particular class of bad developer: Fresh out of college, these people have their curriculum nailed... and know absolutely nothing else.

One example that really struck me was an interviewee that I asked to write a simple pre-order traversal on a seven-node tree that we print out for our interviews. Instead I got a moderately lengthy and correct description of how to search for a value in a sorted binary tree. Correct, except for A: it wasn't the question I asked and B: immediate visual examination of the tree we were looking would reveal it was clearly not sorted. Other things in this interview led me to the conclusion that I got that answer because this person had studied that topic, but almost couldn't even hear, couldn't perceive a question that wasn't essentially right off an exam.

These are the ones who depress me a little, because they have clearly done everything everyone told them to do (study hard, do well on tests, etc) and must have some significant raw intelligence to be able to do this well on a challenging curriculum... yet, for all that, they have walked away with so very little useful knowledge or skills. I also feel some anger at the system that they have learned too well to navigate... but by the time they get to me, it's too late to change anything.

I comfort myself in the near-sure knowledge they will find a job somewhere. Some percentage of them will even adapt to the real world and perhaps they will become great programmers. I don't know. I can't know. That's life.

But I can't in good conscience give a thumbs up for them. We are willing to train solid developers and we have a track record of hiring people that don't even know the language they will be working in (since they have demonstrated the ability to learn languages in the past), but you can only take that so far.

On the other hand, those who sat in college for four+ years and know neither the curriculum, nor any other skills, just barely squeaking by with the necessary grades and forgetting everything as soon as the class is over, well, they had every chance to realize they were in trouble and didn't take it. I don't feel depressed about them at all. That such people exist is just a fact of life.

I'm not sure why that's depressing. You've managed to filter out the majority of people you'd not want to hire with just a simple set of tests.

Perhaps a way to screen out many of these people without spending the time administering the screen is to have a simple coding test that these people complete before you'll even have them in for an interview. A couple places I've interviewed with did this, and they both expressed high satisfaction with the reduction in interviews of hopeless candidates that resulted.

Part of it may be your questions, and part may be HOW you're asking (e.g. over the phone, or putting someone on the spot).

2) Not a lot of people write SQL by hand anymore. I used MySQL for years, long ago, and never wrote a join. Then ORMs came along and handle joins automatically, so I've still never written one. So not being able to do it without looking it up doesn't really tell you anything. I've written far, far more complex things than an SQL join statement. A more pertinent issue I'd be checking for is whether user input is properly escaped to prevent SQL injection -- again, not an issue with ORMs, but an issue when building SQL query strings by hand.

1) A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years.

3) Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other.

Also keep in mind that many introverted people get very uncomfortable when someone is waiting on them. This can make it difficult to concentrate at all. Being asked to perform on demand is normal for a musician but foreign to most programmers. On top of that, it's usually in an unfamiliar environment, such as verbally or on a whiteboard -- imagine asking a violinist to play on some lines you drew on a piece of paper.

PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files.

"I used MySQL for years, long ago, and never wrote a join."

Scary! I wonder about your definition of "used", if you used an RDBMS in a non trivial app "for years" and never wrote a join! The database design must be very ... unusual :-).

And this was in the days before ORMs :-D.

" Then ORMs came along and handle joins automatically, so I've still never written one. "

I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM.

"So not being able to do it without looking it up doesn't really tell you anything."

It does, really! ;-).

"PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files."

The interesting thing about this statement is that it shows one way out of potentially being asked to code on a whiteboard/over the phone. If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, in other words, if you can show , well before the interview, that you are as good or better than the job demands, you are very unlikely to face the "find the longest subsequence in a string" or "write a join" type questions. But then if you could do all that why would you look for a job?

In my case, after writing some open source software, (and posting an url as the first thing in my cv) I've found that these kind of elementary questiong simply drop away. When a few thousand people use your code everyday, people know you are good.

The OP's post is about when all you have is a cv that looks like the last 100 cvs you reviewed, and people who can't answer simple questions about how to write a join (hence his depression).

"I used MySQL for years, long ago, and never wrote a join."

Wow.

Note to self: start asking candidates to write SQL in interviews.

It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly.

And really, you can get pretty much any piece of information out of a database using just four keywords. It's the least memorization of any language in history. SELECT, FROM, WHERE, and for extra credit, LIKE. That's it. That'll get you any non-aggregate dataset you could want, joined or otherwise.

Learn IN and GROUP BY and you've got everything else you'll ever need for reporting. It's just the simplest language ever.

> Note to self: start asking candidates to write SQL in interviews.

Heh. Quite a few people (~20%) take the attitude of the parent poster, saying they're not solid on SQL since they've been using ORMs for a while. So I ask them to write the same select in LINQ or their ORM language of choice. Not a single one has been able to do it.

> It had just never occurred to me that people who spend their entire lives talking to databases wouldn't know how to talk to them directly.

You're begging the question. Most people who use databases don't "spend their entire lives" talking to them.

Of course I've talked to databases "directly", tuned them, "alter"ed them, indexed them, replicated them, and so forth, but just happened to use logic at the application level instead of the SQL level for JOIN functionality.

Ok so hopefully the places where you used to work hired someone that wouldn't write horribly inefficient client-side code to join two tables together when its a SQL RDBMS, and sped up those applications|sites considerably.

I would fail if this was a 'live' screening. It's rare that I write SQL by hand, and remembering the syntax for a JOIN is something I pretty much always look up. I just don't do it by hand very anymore.

I'm a very good developer (my track record would suggest as such), but I would fail at least one part of this test due to the simple inability to remember elementary SQL syntax.

The interesting thing about this statement is that it shows one way out of potentially being asked to code on a whiteboard/over the phone. If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, in other words, if you can show , well before the interview, that you are as good or better than the job demands, you are very unlikely to face the "find the longest subsequence in a string" or "write a join" type questions. But then if you could do all that why would you look for a job?

That's just not true, particularly at the larger companies out there. Amazon, for instance, has a rigorous process that you can't (more or less) circumvent. It involves a lot of saying algorithms over the phone. It was one of the most challenging interviews I've done in my life. Not because of the content, but because of the method.

"That's just not true, particularly at the larger companies out there. Amazon, for instance, has a rigorous process that you can't (more or less) circumvent. "

"more or less" is key. If someone at the level of PG or RTM (or Linus or Hejlsberg, say) were to apply to Amazon (or Google or Yahoo), I am sure they aren't going to be asked to code "subsequence of a string" on the phone! They'd no doubt get a good interview but i highly doubt thatthis kind of "ask trivial questions" interview would occur. The purpose of such phone interviews is to eliminate clueless people who have the knack of writing good resumes , the "all hat and no cattle" types.

I was specifically responding to this sentence "PG, RTM, and TLB would probably fail your test". I doubt that somehow!

> I was specifically responding to this sentence "PG, RTM, and TLB would probably fail your test". I doubt that somehow!

But you'd be wrong.

> if you used an RDBMS in a non trivial app

Depends on what you mean by "trivial".

You can use a database for most of the things most websites use them for without ever using a JOIN. It just takes application logic instead of SQL.

Sites like this aren't exactly heavy on the SQL. This site doesn't even use SQL. Something like Reddit or Slashdot would, but still wouldn't need JOINs.

> I've never yet seen a non trivial RDBMS based app where the existence of an ORM absolved developers from having a good grasp of SQL when they needed to drop below the abstraction layer provided by the ORM.

You don't have to drop below it; you can go "above" it into the application layer.

> If you have a PhD' from MIT and/or have a strong track record of writing Open Source software, creating and selling a startup, build robots (and electric unicylces ) for fun etc, [...] But then if you could do all that why would you look for a job?

Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!"

There are a lot of people who aren't "PhD millionaires" or famous open-source magnates and yet are vastly capable. A lot of them don't write joins. And a lot of people who CAN write joins can't do a bunch of other stuff.

You know what else PG doesn't do? CSS. He runs a website but doesn't use CSS or SQL.

So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X.

"Depends on what you mean by "trivial". "

Anything that has more than say, 2 tables, is what I meant by "non trivial" ;-)

"Sites like this aren't exactly heavy on the SQL."

Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and.

I never said you had to use an RDBMS to make a useful website. But if I was hiring for an RDBMS backed website , and you claimed to have used an RDBMS "for years" you'd better damned well know the basics. No "I don't know how to do a join across two tables because I did it in the application layer" doesn't cut it. That is a really stupid explanation of your ignorance and blows a big hole in your supposed "experience" with RDBMS.

"You don't have to drop below it; you can go "above" it into the application layer."

Sure you don't have to drop below the ORM. But you'd better know how to and when to . I wouldn't trust a developer with an ORM who didn't know ultra basic SQL. And a join in an RDBMS is ultra basic - someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables (the OP's question was aa simple join across two tables) is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers). Is that possible? I guess, Is it probable? Not at all.

Besides, using an ORM and doing a join in the application layer (without knowing how to do a SQL join) is ... unusual ;-).

"Let's consider the case of someone with a PhD who ISN'T famous, and then you give him some kind of SQL test and he fails. "Man, what a load of bullcrap his PhD is! He can't even do a simple JOIN!""

Well if the PhD applied for a job that needs SQL he'd better know how to use SQL (or learn - it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query? If the PhD couldn't do that and claimed he had lots of experience with RDBMS and then said he didn't know how to write a join, then I'd write him off as incompetent (and possibly a liar) for this job, irrespective of his degree, sure) .

" A lot of them don't write joins."

as long as they can write a join after claiming to have worked with RDBMS for ages ;-)

"So, once again, the danger of using any litmus test is you can end up filtering out extremely capable people who don't do X (but could obviously pick it up quickly), while passing minimally-capable people who CAN do X."'

The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage and you end up wasting a lot of time talking to incompetent people.

> Invalid refutation, I said "if you used an RDBMS and ". That "and" was a boolean and.

Valid refutation. You can use an RDBMS without making use of most of its facilities, and indeed, that is the typical usage case.

You can easily have a non-trivial app which makes what you'd probably consider trivial usage of a database.

> someone claiming knowledge of an RDBMS and not knowing how to do a simple join across two tables is like someone claiming to be an expert in c and not knowing how to write a for loop (let alone use pointers)..

You're mixing up "working knowledge of SQL" with "expert knowledge of RDBMSes". I agree I am nowhere close to an RDBMS expert. However, I can use SQL, which was the point of the original post.

> after claiming to have worked with RDBMS for ages

Something is wrong in your mental model of my description. I used MySQL for years, starting many years ago. I did not say I was an expert in RDBMSes, or used advanced functionality in any sense, and I said the join functionality was done at the application level. My usage of SQL was basic, but I have a working knowledge of it. If there's something I need but don't know, I can read the docs and do it.

> it would take what, one day of reading a basic book on SQL to understand what a join is and formulate a query?

Reading an SQL book doesn't mean you're going to recall the syntax, until you have written queries a number of times by hand. I agree it is not complicated. I do not agree that asking someone to write a JOIN tells you anything about WHY they can't do it.

> The danger of NOT using a quick and easy litmus test is that all kinds of idiots get through to your personal interview stage

You'd probably filter out Pete Norvig, and Linus, and who knows how many other expert programmers, if you asked them to write an SQL join off the top of their head.

"You're mixing up "working knowledge of SQL" with "expert knowledge of RDBMSes. I agree I am nowhere close to an RDBMS expert. However, I can use SQL, which was the point of the original post."

Hmm you seem to be laboring under a concept that to know how to join two tables you need to be an RDBMS "expert" and "working knowledge" is not sufficient.

On the contrary, if you can't join two tables with SQL, you don't have any "working knowledge of SQL". Neither can you "use SQL" worth a damn. Every answer you make exposes the hollowness of your supposed "working knowledge"!

"However, I can use SQL"

Sure, as long as you query single tables (and do joins "at the application level") ;-)

> Hmm you seem to be laboring under a concept that to know how to join two tables you need to be an RDBMS "expert"

You're misreading. You kept bringing up the point of "expert" knowledge (e.g. in C and for-loops), or knowledge of RDBMSes, and saying you couldn't know X without also knowing Y.

As the question was about SQL, NOT RDBMSes or "expert"-level knowledge of SQL or RDBMSes, I pointed that out.

> On the contrary, if you can't join two tables with SQL, you don't have any "working knowledge of SQL".

Depends on what "can't" you're talking about. I can look it up and then do it. A lot of people don't remember the syntax. Obviously anyone with working knowledge CAN do a join; the question was whether they could tell you how to do it off the top of their head.

Even things you've used a lot, if you haven't used them recently, you'd likely slip up in an interview.

> Every answer you make exposes the hollowness of your supposed "working knowledge"!

Not really. I can make things work (hence "working knowledge") and look up what I don't know and use it right away.

I've been using in-memory databases and of course the equivalent of a JOIN is a basic function but it's not an SQL JOIN.

Well, if you're using ORMs to handle all your SQL needs (and they literally must be handling all your needs if you're never writing anything with a join) then I don't think that you actually have a working knowledge of SQL in any sense. There are certainly plenty of jobs which require that knowledge, and I'm not sure an employer would want someone who didn't have direct SQL language experience.

To be honest, I don't understand how you manage not writing joins even if your ORM is perfect and flawless. I use the SQL prompt like an interactive debugger, writing queries to look at the internal state of my database.

(I assume that the original post refers to applicants that listed "SQL" somewhere on their resume, or else he wouldn't be asking SQL syntax questions -- I hold that if you have "SQL" on your resume, you had better know how to write a join.)

> then I don't think that you actually have a working knowledge of SQL in any sense.

Of course I have working knowledge of SQL, that's how I used MySQL back when we had to write things by hand. I just don't have a working knowledge of JOINs. I could look up the syntax if I needed to use it. [Looks it up] Looks easy enough.

There are numerous SQL commands most users of SQL would probably need to look up.

Arbitrarily deciding that having not-used X means you don't have a working knowledge is a fallacy. Someone else could arbitrarily decide the litmus test is stored procedures. MySQL didn't have those, so instead of using them we had to code at the application layer, and just happened to use application logic in places of JOINs as well.

I don't even remember if MySQL had joins, or non-buggy joins, a dozen years ago. Other people would say, "it doesn't have transactions, so it's not a real database", et cetera, et cetera. You work around limitations and get used to doing things a certain way.

It had JOINs but a lousy, lousy optimizer, also sub-SELECTs were (are?) a problem. I can't say that having a sort-of knowledge of some (very little)of MySQL is equivalent to having a working knowledge of SQL. Most commands that SQL users would probably need to look up would be the DDL commands, not simple (yes, it really is simple) stuff like LEFT OUTER and INNER JOINs. Also while saying MySQL didn't have SPs is an (fair) indictment of MySQL, you using application logic instead of JOINs is an indictment of you and your supposed 'working SQL knowledge'

I have enough SQL knowledge to replicate most websites I see. I am also familiar with it enough to look up things I don't know and use them. If that's not "working knowledge", you're using some different definition.

You can have working knowledge of e.g. calculus but need to look things up because you haven't memorized everything yet, and can learn some new method quickly. Someone without working knowledge would simply be lost, no matter what cheat sheets you put in front of them.

"PG, RTM, and TLB would probably fail your test -- they don't use SQL, they use flat files."

Well, then they likely wouldn't be a good fit for the position the OP is hiring for, since it requires using SQL, not flat files.

It would be nice to see who's upvoting this so I could add them to an IDIOTS file.

Any of the above people could obviously EASILY pick up whatever SQL you happened to be using. RTM could wipe the floor with you, the OP, and everyone else on your team.

If your interview process filters out people like RTM, your filtering is broken.

When you're hiring for any normal development position, ability matters more than reputation. If I was interviewing someone for a job that required writing SQL and asked them to write some SQL, and they couldn't, I wouldn't hire them. What is so hard to understand about that?

I'm sure that I could EASILY pick up the skills required to be a gardener, but would you hire me to tend your rose bushes based on that fact? No, and that's what this discussion is about.

I don't think the violinist comparison is fair.

Any violinist worth their salt has practiced sight reading to death. Absolute death. It's difficult to do, yes, but if you're playing in any sort of group situation (orchestra, etc), sight reading is extremely important.

Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument." In which case it's a worthless interview. Whiteboards are fairly common for code snippits and pseudocode at most of the jobs I've worked. Pieces of paper with representational lines for the strings are used as individual studies (e.g., sheet music) - not for collaboration. That's usually done in jam-format..

> Unless you're saying "I drew some lines on this piece of paper that represent the strings on the violin; I want you to play the piece of paper like you would the instrument."

Yes, that's it.

> In which case it's a worthless interview.

I'd say the same applies to whiteboards. I have never sketched out code on a whiteboard except in an interview. Of course you can do so and become accustomed to it, just like you can finger a paper violin or piano.

"A lot of people use languages where recursion is unusual (i.e. NOT Lisp). Even a senior developer (especially of something like PHP) might not recall this, not having actually written a recursive function for years."

There are tons of languages that support recursion. Whether or not you use it is a function of the problem, not the language. (I'm not counting tail recursion since I consider tail recursion to be a functional way of expressing iteration.)

"Representing a car as an object: A lot of software people don't know hardware, so the confounding part might be recalling various attributes of cars and how they relate to each other."

Well, if I was given this question in an interview, I would ask, "are we building a CAD program or a car-racing game"? CAD programs (I've never written one) would probably have a CADObject class for all drafted objects that the car parts and the car itself would inherit from, and you'd have to discuss not only what was in the car but where it was connected, so just saying that it's a composition of "engine, body, brakes, air filter, etc." would be insufficient. A car-racing game would just have a car object with a shape, performance characteristics, and be able to hold states for its physical motion at a given time, as well as being able to take messages/method calls for things like "pressing the turbo button" or "emergency brake" or "shoot a missile" (depending on the racing game). You can build an entirely sensible object model for a car and be totally wrong if you don't know what you're building it for.

> There are tons of languages that support recursion

Obviously. But I don't remember ever writing a recursive function in PHP for a website.

If writing PHP for websites is the limit of your skill set, I'm worried for you. Not a personal remark, but a comment on the interviewing process.

Sorry, we decided to go with another applicant. We'll keep your resume on file.

As noted, there are numerous expert programmers who couldn't do an SQL join in a live interview.

Besides PG, RTM, and TLB, most or all of the Linux kernel programmers, including Linus; Pete Norvig; embedded systems programmers; and on and on.

You could find a lot of people who can handle the SQL you need while screening out brilliant people who are FAR more capable, but just happen not to know item X.

Flemlord, a lot of responses seem based on hypotheses about what a good answer would have been. Could you follow up and give examples of what you'd have considered correct?

My hobby-programming experience suggests...

simple - int add(int a, int b){int result; result = a + b; return result}

recursive - um, I like fibonacci sequences: void fib(int term){if term = 1 return 0; if term = 2 return 1, else return fib(term - 1) + fib (term - 2)}

SQL join: no idea, I haven't used SQL for years. I assume you mean something like for(i = 0; i < table1.length; i++) do {newTable.fullname[i] = oldtable.firstname[i] + anothertable.lastname[i]}

Car as an object: well I guess I'd have a struct with variables for size, weight, power, turning circle and so on, and methods for accelerating, setting direction [steering heading, speed (forward and reverse, or multipliers for forward gearing)] and braking...then I'd have create multiple instances of that object using a table of values...do you make racing games?

I'm not looking for a job, but I'm interested in knowing what sort of answers you were after. The above seems super-simplistic to me, I'd feel nervous they were trick questions of some sort and the obvious answers are actually the failing ones.

Your fibonacci algorithm is crap. You're tree-recursively calculating the exact same values over and over and over and over again. Just try running it sometime on a large n if you want to test your computer's ability to stall and ramp up the cooling fans.

"do you make racing games?"

That's a question to ask first, not second. Maybe he's making a "Pimp My Ride" style game where the actual driving part is less important but you need detailed modeling of the seats and the ability to add a bunch of random shit to the interior of the car. Maybe he's making a CAD tool for people to do body design, so you need to be able to do computational fluid dynamics on it and test weight balances, but also be able to visualize it in high resolution to see if it looks cool and to print mockups for focus groups to say "this looks like a kickass car".

Agreed, but this is the very question I'm getting at - does Flemlord want to know the quality of algorithms someone naturally comes up with, or is this just to screen out the total BS artists?

Hence my mention above of how it feels like a trick question. I really don't know whether the interviewer wants the autistic-but-informative answer or the quick of-course-I-know answer. Trying to guess what sort of answer you are seeking induces mild panic in me: I don't know you, but if your response in an interview was 'what a crap algorithm' I'd be thinking 'this guy is a bit Machiavellian...'.

I mean, I can think of a much faster way (than this) to get a given term in the fibonacci series using a loop, but this one recurses, which was what was requested - I had to quickly choose a problem domain in which to demonstrate it. Towers of Hanoi would have been more impressive, but I don't know if I could just rattle that off correctly, verbally. See what I mean?

If I was interviewing you (I've never interviewed anyone) and you gave that fibonacci algorithm, I would probably say, "Hmm, and how does that algorithm perform? Can you think of a better one?" If you said "its performance is crap, storing the previous two results and using iteration is better", I'd be happy. If you said "exponential" and "linear" instead of "crap" and "better" you'd get bonus points. Volunteering that information at the outset would get more bonus points because it shows that you really care and that you don't even feel comfortable writing down an exponential-time algorithm without loudly warning everybody they shouldn't use it.

The standard interview question is "write a function to solve this problem which has an elegant recursive solution", not "think of a recursive function". But if you do want to think of a recursive function, try factorial.

    int fctl(int n){ return ( (n = 1) ? n : n * fctl(n)); }

(Don't use that code in an interview. It's questionable style for C, and the ternary operator is scary to people.)

I was asked to write a fibonacci function once, and I actually said, "you can do this recursively but the performance is awful" and wrote an iterative solution.

The point of an interview is for you to show off. If you start going on and on and on and on about unnecessary details the interviewer might stop you, but if you launch into a talk about the space and time properties of recursion vs. iteration and show some judgment for how to use recursion and how not to use recursion, then I know how knowledgeable you are.

Dammit, I made a syntax error. The factorial function in C should be

    int fctl(int n){ return ( (n == 1) ? n : n * fctl(n)); }

(n-1) for the recursive call. God, I'm failing this interview.

Heh. Our actual interview question is similar but we ask them to add instead of multiply. We ask them to add up all positive whole numbers equal to or less than x. Good developers (who make it to the next round) bang out the answer in literally 30 seconds. Ok developers (who still make it to the next round) usually struggle for a while, maybe implementing it non-recursively first. The other 70% just type nonsense until I cut them off after 15 minutes.

If somebody makes a mistake I tell them and give them hints until they fix it. Well... it depends on the magnitude of the mistake I suppose. If they're not even in the right ballpark I keep my mouth shut.

Thanks for your considered and interesting reply. I agree that a discussion is much more informative (for both parties) than a rapid-reaction test, but with the rise of a speed-dating approach to business in recent years it's hard to know what people are looking for, sometimes.

Your better employers will thoughtfully talk with you though, and this is a good way for you to pick a good employer. That's an unseasonably optimistic attitude during this recession though.

Join question:

select * from books join authors on books.author_id=authors.id

Now you get the fields from each table in your result matched up correctly.

Steve Yegge's post on this is apt and may help those who haven't read it.

http://steve-yegge.blogspot.com/2008/06/done-and-gets-things...

I have kids, and whenever I do interviewing, I get worried about their future. I think the secret is to get them to feel passionate about something; as long as they have the motivation, they'll want to learn. But how to do that? And what if I fail? I shudder to think they'd have to stay in some of the crappy jobs I've been able to leave.

Outsource Step 1 with an on line programming screen. There are many companies that do this. Sure you'll have to pay for each one, but they will weed out the bottom 90% pretty quickly.

Yes. I used to do the chatty bit first before subjecting interviewees to the "technical evaluation"; it seemed polite to engage people first.

That was depressing. At least I found out the technical evaluation was worth giving. An astonishing proportion of people that came off well in less technical conversation would utterly flunk the test.

I'm not talking minor errors caused by interview pressure. I mean people with "5 years of C++ experience" writing void reverse_string(char* in) { char b[] = new char; b = in; ... }

I think the best solution is to ask the questions in as many possible ways you can think of.

Some people are great at coding, but suck at whiteboard, others aren't comfortable talking about their thought process.

So why not give them numerous ways to show their stuff? Have them find bugs, have them code on whiteboard, have them write code in a compiler, etc etc.

Your goal is to find a good programmer, not a programmer who is good at white board.

Speaking of someone who's basically right out of school, I can tell you that I probably wouldn't hire most of my classmates. It _was_ depressing.

In reference to the post I made directly above yours, a classmate of mine got an interview with my employer about 3 months after I started. The HR guy approached me after his interview, and told me he left the entire linked list question blank.. no pseudo code.. nothing. I was embarrassed.

Interviewing leaves me depressed. I just spent most of an hour proving I can't verify whether a tree is binary. Mostly, we didn't focus on anything relating directly to the position or talk about my experience in any way. We proved that there are holes in my education pertaining to basic CS, that I never encounter on a daily basis as a web developer. I guess the rest of the stuff was taken for granted.

I understand that these tests can be important, but I can't help but feel that I will fail to qualify for any position that requires me to hold a host of basic CS algorithms in my head, but that I could still do a good job in the position - because I'm very good at learn as you go, and have learned lots of higher level stuff while building elegant, complex systems - without knowing how to verify a tree's binary nature.

I've been working for 3 years as a front-end developer and somehow have managed to pick up all of those skills minus the join (just started learning SQL last week). Maybe your pool of samples is tainted. Where do most of your applicants come from?

70% sadly sounds about right. end depression by making the screening process as quick as possible.

Heck, I can do all of that and I'm nowhere near a "senior developer"

How will the interviewee know that interviewer is smarter than him?

My experience has been identical to yours. Ask simple questions, get constant failures. In bad times, the signal to noise ratio is completely out of wack. A recession is the worst time to hire people.

If you're going to put someone in the coding hot seat like that, at least give them the decency of having 30 minutes alone with a computer.

Reply on news.ycombinator.com