Yes, in retrospect, I think I was misunderstanding. OP clarified his comment, and in that case, I think it makes sense. I agree - that is the essence of programming, and if you truly cannot do that, you have no business being a programmer. However, there is more to software engineering than being able to translate algorithms into code, and I'm not so sure that a single litmus test should make the difference between hiring/not hiring a candidate.
There's more to playing baseball than running, but someone who can't run probably won't make a very good baseball player. Sure, there's going to be some error rate, but that's inevitable.
Yes, true, but curlers or rock climbers don't need to run the same way baseball players do.
All I'm saying is that there needs to be a multi-faceted look at a candidate. Some candidates are going to be so obviously poor that they do merit instant rejection. However, in my experience, that is the exception rather than the rule.
Out of curiosity: where do you come in, in the interviewing process? I don't have direct experience, but I frequently hear that very trivial programming questions weed out more than 50% of applicants to programming jobs.
I am in the middle; our candidates are screened by HR (a process I'm not super fond of), then they come to me for various levels of tech/cultural fit interviewing. Then my comments are forwarded for final approval. Generally, if I say "hire", they hire. If I say "run", they run.
And yes - trivial programming questions do weed out a fair number of candidates. However... it's tricky. A trivial programming question can look different to many different people, especially if they have varying skill levels and depending on their level of comfort in interviews.
I try to give people the benefit of the doubt. If one question stumps them, I'll try to gauge their understanding with another similar (but different enough) question. If that doesn't work... sometimes I'll give them another shot, but usually I'll start winding the interview down.
You're focusing too much on the wrong thing. The point is being able to take a (simple) problem and convert it to code. The problem doesn't matter, the method does.
