Chicken-parts processor interviews aren't like this, para-legal interviews aren't like this, firefighter interviews aren't like this, teacher interviews aren't

Chicken-parts processor interviews aren't like this, para-legal interviews aren't like this, firefighter interviews aren't like this, teacher interviews aren't like this, etc. Doing this sort of interviews on programmers probably wouldn't work even if current programmer interviews do suck for both parties and they're mostly embarrassing, too. I'm guessing here and might be wrong but all these professions have a rather fixed set of limited skills they have to know in order to qualify. Teachers have to teach a certain curriculum: on top of that they can be bad teachers or good teachers but basically what they have to achieve each year for each class is known and predicated. Firefighters have their training and as a baseline it's sufficient to be a good team player and just execute. Firefighters will have to improvise at times, and they will have opportunities to make some really good judgement calls based on their experience alone, but that's sort of extra. You're still a good firefighter if you just stick with doing it by the book. Now, the same for programmers would be something like "Must know Java and we'll hire you". This didn't end very well in the IT bubble twenty years ago. Knowing Java inside out doesn't make you a good programmer, not even a good Java programmer, there's so much more to that. Would you hire an artist based on "Must know how to paint in oil, watercolor, and draw in charcoal"? That's where the real skills begin, not suffice. If you're a Java programmer it doesn't mean you can just sit down and program anything for any company: there are hundred domain-specific skills and questions, all sorts of CS theory of which you know one or two fractions based on what you've worked on before, and a very specific mindset that makes a good programmer for a specific role. To some extent you can be a generalist and learn a bit of this and that but especially for heavy specialists it could take years to transition from one specific subdomain to another. All programmers are cathedral builders but they will all make very different cathedrals and they are continuously requested to make cathedrals that have not been built before. Then there are other jobs where they follow the blueprints and produce a cathedral one after another, meeting the same requirements each time. I'm not saying programmers are superb to these other professions when it comes to complexity and depth. It's just that a programmer's job can be about anything: the number of problem domains is endless and more so as the world becomes more software than hardware. You can do so much with computers and programming that whatever baseline there exists alone doesn't yet take you anywhere as a programmer. There's the fizzbuzz level of a baseline, there's the skillset, buzzwords and qualifications baseline, and there are a lot of other baselines that need to be met. That's why you need to figure out a way to interview programmers that takes all this into account. There's no single interview that could be used to qualify people for being hired as a programmer because the requirements are never fixed.