[cmorrisrsg]

I actually reject people without pet projects for an entirely different reason. I can find out much more about how you behave as a developer and whether or not you'd fit in with our company by reading your code than I can from any kind of interview or whiteboard challenge. Ideally you'd actually hire the prospective developer for a short contract project before hiring, but that has significant challenges and costs as well.

Think of a carpenter that claimed to be amazing at producing furniture, but had none to show you. Would you trust them on how well he could BS you in an interview? It's not about passion or dedication. If you, producer of code, can show me code you've produce, I'm taking a much lower risk on hiring you. And fortunately, there are enough people around with code to show that rejecting others is a pretty easy filtering decision to make.

[factotvm]

Then give them a coding problem that takes a short amount of time but allows you to evaluate their skills. I relish these opportunities and respect the companies that ask me to do them.

To keep with your metaphor, ask the carpenter to make you a cabinet door.

Again, I agree with others here... if you're passionate about the startup you're working at (and you should be), that is your side project. I distrust people who work at startups that have side projects.

[eropple]

A coding problem is less illustrative than a decent--LOC is always suspect, but let's say 10,000 LOC--corpus of work. Something to show much more than a toy problem.

Better still, however, is collaboration with open source projects--you can see individual communication between people as well as the developer's ability to enter a foreign codebase and be productive, (hopefully) without introducing bugs due to ill-advised changes without understanding what's being changed.

(We don't look at side projects or open source at my current employer. I wish we did.)

[cmorrisrsg]

Any coding problem that could feasibly be completed in an acceptable amount of time would be too small to actually tell me what I want to know. I mostly don't want to know what algorithms you're aware of or how quickly you can type. I want to know how you structure and modularize code. I want to know how you debug things. I want to know if you can refactor well. In short, I want to know about how you handle building and maintaining real software. If I hired people to do coding problems all day, that would be another thing, but I don't.