I actually like to give a problem that we just recently solved as a takehome test. It's by definition representative of what I need them to know, and since I know "an answer" it helps to see if they come up with a far more elegant or more kludgy way of doing it.Having been on both sides of the table, I've grown to see interviews as a necessary evil. As I've gotten older, I've learned the true power of networking. Once you build a name for yourself and have worked with some great companies, you basically can write your own tickets. That said, the worst part of a programming interview for me is the technical portion.
I've been in positions where I've hired people, and I know the difference between a good interviewee and a bad one. Bad ones tend to overtalk answers which is usually a sign that they're not very sure of their answer. Honestly though -- we would phone screen people and 90% of them were just fucking awful. They put all these buzzwords on their resume and when we asked a basic question like "What is Amazon's S3 service used for?" and they would say things like, "Well, it's a DNS server for Fortron servers...uhhh...It's like a phone book. That's what DNS is..." -- Like WTF dude, you put "Expert in Amazon EC2 services on your resume and you don't even know what the fuck S3 is?"
That said, in the rare instances someone gives me a technical interview, I'll be honest and tell them that I don't code well under pressure (not that kind of pressure) and if they'd like to give me a take home assignment to see how I do, I'd be more than happy to do that. Just be honest with them -- if you are a good candidate and know what you're talking about, they'll usually give you the benefit of the doubt.
Honestly, I hate hiring -- because we get people referred to us from hiring agencies and these people don't know their ass from a hole in the ground. We've had people agree to a time and when we called them, they sounded drunk, talked real low, never asked questions (that's a big one for me -- at least ask one question about what we do as a company) and would answer a question like, "What is an IP Address?" with "Uhhhh....(sound of keyboard being typed) ... uhhhh well .... (more typing) .... " Jesus.
If you know the difference between RAM and ROM, you're ahead of like 80% of the potential hiring pool.
As for timed on-site coding tests, if that's representative of how the company's devs work, then why the heck would anyone want to work there? If it's not representative of how the company's dev's work, then why the heck would anyone want to work for a company that tested applicants using something that was completely non-representative of how their dev's actually work? If you're self-taught and trying to break in it might be a necessary evil. Otherwise it says a lot about what your future work conditions will be like, and not much of it good.