I think you're misunderstanding. This is not a test to see if you know what Pascals triangle is....it's a simple test of your ability to take a simple algorithm that has been explained to you and translate it into code. This is the essence of programming.

Pascal's triangle is simple a triangle which starts at 1 and where each number in the next row is the sum of the two numbers above it, with 0 being assumed for numbers on the edge.

A program to produce one is nothing more than a couple for-loops, printf, and some basic logic.

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.

Sadly, for baseball, this is far from the case :(

Algorithms are one thing, but I don't know of a single business that is dependent on Pascal's Triangle. That is, is it realistic to use PT?

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.

I have no idea what Pascall's triangle is. But I'm able to write bookkeeping/accounting software and webframeworks. So I guess we'll have to look for jobs elsewhere :)

I had no idea either but he qualified his statement saying he would explain what it was. I just looked up the wikipedia entry which explained it pretty well and I would think that you'd have no problem building a prototype given your listed experience. The point he is making is that he will give you a problem (and Pascal's triangle seems to be a fairly simple one at that) to then be involved in your analytical process. It sounds fair to me.

I've been putting food on the table writing code every day for almost two decades along similar lines as king_magic and I also do not know what a Pascall's triangle is.