I used to work at a company that used XSLT. They know that it's an obscure language that probably none of the potential candidates have ever worked with. But it's easy enough to learn the basics in an hour or two.
So the entry test was to strip some tags from an XML file. You had a day or two (maybe more) to do it. My solution wasn't ideal, I didn't use several of the shortcuts available in the language. But at least it did what it was supposed to.
A few weeks after I had started working there my boss came up to me, visibly frustrated and asked me whether the test was too hard. Thinking back on my problems I replied that maybe having the desired output ready so that you could test your own solution against it might be nice. But my boss's problem was that none of the last 5 candidates could even send in a solution that would run.
You had so much time, and running an XSLT script is really easy and takes no time at all. And for some inane reason these people couldn't even manage to test their code and still decided to send it in.
And I thought I was an idiot when I didn't know if it was spelled grey or gray in CSS during the in-person interview.
You can tell this is fake because the code interview actually tests basic knowledge instead of giving you 13 minutes to create a templated polymorphic class which accepts arbitrary flatbuffer arguments and implements factory pattern constructors written in Haskell, with the end goal of recursively sorting nanoparticles by bond strength. Intro level position, $8/hr, must supply your own MacBook.
Oh geez, I'm one of those people who can't code on paper. I was applying for something ages ago and I went in for a programming test and they handed me a paper test and my mind completely shut down. Put me in front a computer and I have no issues at all... It was embarrassing.
And that's why we're moving away from coding games where I work. Bad people try to cheat, good people can panic and shit the bed.
When I do interviews, I'm more interested in the candidate's relevant experience, what kind of issues they faced, how they were solved, if they think they could have done things differently, and how they think. Code itself is irrelevant unless I can review a sprint's worth of PRs.
When I ask more technical questions, I never ask for code but for an explanation on how they would tackle the problem. For example, I often ask about finding a simple solution to get all data relevant to a certain date in two, simple, historized tables. If you know window functions, it's trivial. If you don't, your solution will be slow and dirty and painful. But as most devs don't know about window functions anyway, it lets me see how they approach the issue and if they understand what parts should have a trivial solution to make it simple.
I hope these aren't real. I, and most people here, could probably write these codes top to bottom on paper without an eraser or strikethrough parts because we have it fully solved before the interviewer finished the sentence.
I knew a dude who got a job for a programming language he never wrote. Not only that, the guy was hired to be the experienced / lead programmer to give guidance on how to use the language. In fact, I knew multiple people like this. Some were actual programmers and good at other programming languages, but some had decided it was time to switch from another field (geology, marketing, database engineer, ...).