There are more reasons, in short it takes me couple of hours/days to warm up and grasp the problem.
And secondly I refuse to waste my time, on half arsed throw-away code, with zero results.
Even if you are exactly as you claim, MOST people who claim "I can code but don't care to demonstrate it during an interview" are actual disasters as co-workers. I've been there, done that, cleaned up the messes, and would prefer to pass on some good people to avoid that.
And yes, you do have to pass on some good people. There are competent programmers who freeze up during interviews. You do what you can to make the interview as accommodating as possible, but some people can't show what they've got. However the opportunity cost of passing a good person by is far less than the damage from hiring a bad one. This leads to being risk adverse.
Personally, I've never been a part of a company where the code test isn't:
1) Short (1 hour) 2) On their own time 3) A real problem (algorithms are OK in my mind as long as you help them with the core problem)
I do not expect everyone to know every algorithm... I guess it is kinda weird if you do not know Dijkstra's algorithm, but I only think it is weird because the courses I took focused heavily on it and similar algorithms.
But, do I want you to know all the same stuff I know? No, definitely not. I don't want 2 of me I want me and someone else that works well with me but ultimately has their own ideas.
That's a very wierd thing to say. Does that mean that each and every side-project that you do ends up being substantive? If writing few lines of code gets you a job at a good company where you can spend your time working on exciting problems how is that wasteful?
I do program a lot too, and I typically don't mind writing code in an interview. The only thing that sets me off are stupid level-order binary-tree traversal questions which test nothing but rote-memorization skills.
Also my job is to design database structures, and there is no such thing as simple problem. Even binary tree needs thousands LOC for tests, concurrent access, writes...
But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc...
Oh I'm not discounting that. I'm just saying that off the bat binary-tree traversal don't really test my understanding of the data structure. Recently in an interview I was asked a problem which eventually required using a binary-search-tree to improve the running time. This, I believe, is the right way to test but it requires the employer to spend more time designing interview questions rather than relying on a problem bank[0]. (which is a strong filter for good companies in itself)
> But they completely ignore the other 80% of the job which is design, soft skills, estimates, timelines, code reviews etc...
This is true but this is really really hard to test. In the interviews that I've been giving, I've indeed been asked design questions. I assume soft skills are implicitly tested while speaking to the interviewer (to some extent, at least). But other factors, AFAIK are very hard to test. Also, I would argue that a candidate doesn't need to know everything coming in. Estimates, timelines etc can be learnt on the job.
IMO, if somehow employers could find a way to reasonably trust that the code I have on my Github is indeed written by me then I think that should be strong indicator of my competence. Evaluating candidates who don't have any code in the open is a different matter altogether to which I have no solution.
[0] - http://leetcode.com
For every good developer offended by coding in an interview, there are 50 idiots who can't code, who are using that as an excuse to con their way into jobs they're not qualified for. IMO, it's an acceptable trade off.
If you're that awesome you wouldn't be going through the usual interview process, anyway.