You can ask a carpenter to make a small, simple thing and you will see how competently they use their tools, how steady their moves, how efficient they are with the material. And use that information to understand if they will be good carpenters working on much larger project.
But mostly my coding tests are there to weed out people who can talk but not actually program so that I can save time on the rest of the interviewing process or so that I don't have to fire them in 2 months for no results.
I respect your position. But understand, you are making it tough for me to know if you are good developer or just one of those people who are good at talking their way through interviews or need to go to a hundred interviews to get a job by accident. You will not get hired if I have anything to say about it.
I don't need to hire every good developer. I just need to hire some. The interview is optimised to make it unlikely for a bad apple to come through because it just cost too much to deal with people who are unable to perform. It is very hard to tell if a developer is in fact a good developer but it is pretty easy to spot a person who can't program their way out of a paper bag -- just get them to write a piece of code while you are watching them do it and explain what they are doing. And I also prefer to work with people who are easy to work with -- like people who don't make demands that don't bring them any value.
One definition of stupid is people who cost other people without any benefit for themselves. They are just drag on everything but don't benefit from it. If you come to an interview that I have designed and tuned and start making demands to change this or that derailing my plan and creating no advantage for yourself it is a sign of particular flavour of stupidity, in my view.
Smart people try to find a way to benefit themselves and even smarter people try to find a way to benefit both themselves and others by trying to find a mutually beneficial solution to their problems.
That's literally what interview process is. Because we can't immediately tell who is this person, we need to compensate for it and spend a bit more time with them.
That's why it is called "interview" and not "welcoming ceremony".
This is smack in the middle of what I call a toxic, self absorbed and entitled personality.
Good luck in your life.
plonk
Imagine for a moment if the interview process you describe actually went both ways. Have you ever seen an interviewee demand their hiring manager perform some mock management scenarios for them as part of the interview process? Of course not, because that's insulting and ridiculous. Just as ridiculous as doing the coding interview performance art.
Hiring managers/interviewers often perceive themselves as being in a position of power, which is why they feel comfortable demanding ridiculous rituals of subjugation. It's very jarring for them to not be in a position of power, when an interviewee perceives themselves as their manager's moral and intellectual equal.
“Just hire better, bro”
That’s why there’s a system design round.
To be clear, I am making the distinction between "coding exercise" and "brain-teaser". Brain-teasers are not useful in an interview context, and only result in adding stress to an already stressful situation. Simple tasks like "Write a function that rolls two dice and calculates the position of a game piece as it moves around the edge of a game board" are much better. I am not looking for the candidate to give me their masters thesis in a piece of code on demand, I am looking to weed out candidates that clearly don't have the skills to fill the position.