We created a new programming language just for our interview process

I interviewed at a startup years ago that did a similar thing. They set up a half-ass web site to screen candidates with their hastily implemented lisp. I easily did all the screening questions and also wrote a detailed critique of their language (it was lacking a lot of basic things like a reliable way to check for equality). The whole thing felt like a pet project.

You've clearly been hurt in the past and I recommend seeking therapy because this reaction is literally from signs of abuse.

I would submit this article as evidence showing that the programming interview process is broken. There's absolutely no reason why any one needs to write a new language for a programming interview.

If you want to screen for programing ability, the pseudocode is your go to tool. If by some chance you want to test for the ability to learn a new language then there are plenty of programming languages to choose from. I think they are in the 1000's so you have plenty to choose from.

Creating a new language just wastes everyone's time and energy and introduces added stress to the interviewees.

What's worse is that many of the hired programmers will leave for better jobs as soon as they get a chance. Also, many of the programmers they hire will end up managing code rather than actual programming. So all this work is for nothing.

This is just a way to put your ego over the need of the company to hire programmers that can accomplish the company's goals. I see this often.

I feel similarly. Interesting concept for sure, not deserving of the mockery elsewhere in this thread. And if it's really as quick to learn (starting from zero, mind you) as they claim, which I find fairly credible, I don't see how it favors "privileged" candidates (if the mechanism for that is that it only passes people who have free time to "learn a whole new language zomg"). If it's really similar to JS, most of my knowledge of other languages will transfer, and I'll just need a cheatsheet for syntax and stdlib (which might make it less suited for their stated purpose, if it doesn't force me to grok new language concepts, hmm).

All of this depends (as so many things do) on the details of execution. Did they actually make a language that's quick for moderately clever people to learn? Are they setting expectations correctly elsewhere in the process? Probably other failure points as well.

That said, I think the strongest way to deal with language unfamiliarity is to allow candidates to pick their most comfortable language.

Admittedly that works against my other interesting interview idea, which is to give candidates a small running application to modify: it would be infeasible to keep even a few different-language versions of this balanced in difficulty, to say nothing of letting them code in Racket when they feel like it. The idea here is to test their ability to grok and modify the abstractions of an existing codebase, which I think is more realistic than starting from scratch. Obviously creating an application suited for that purpose would be Tricky.

"Damned be your 10 yoe because we can't learn how to be dynamic and flexible in our interview process. "

This is akin to having candidates answer questions by calling a automated line and recording their responses in two minutes.