Ask YC: Does interviewing developers leave you depressed?

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.

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.

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.

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.

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