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,

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.