"...hire not only coders who are familiar with today’s technology but those who are capable of learning any new technologies that spring up in the future."
But it seems like a vanity project with brogrammer goals and a huge waste of resources.
I personally feel that interview gimmicks like this are a major reason we lack diversity in our field. Want to keep marginalized candidates out of your organization? Create a gimmick to intimidate and mock them during the interview process. Then sit back and pat yourself on the back for being so clever.
This is like looking to hire an English teacher then asking them to prove they can teach in Esperanto in order to get a job.
If they sent me a home test with a custom programming language I would laugh and tell them to withdraw me from consideration. I'm busy, I'm not learning a new language so that you can pat yourself on the back, others might, but I won't.
When you go out of your way to create a programming language for interviews that says to me that you think you are smarter than everyone else and you have nothing better to do than prove it by belittling candidates until you find one with the balls to push back. That is a brogrammer move.
Further, I'll naturally assume your entire workplace culture is poisoned by code ownership and interpersonal hostility and that your most promising employees "failed" your recruiting tests or quit following an endless barrage of bike shedding code reviews.
I've already done enough "ping-pong balls in the aircraft" nonsense that I tell recruiters up front that questions like these and other make work tasks designed to make the interviewer feel superior will simply not be tolerated and I will and have walked out of such interviews.
I once was interviewed for a C# position but then when on site asked to complete a coding assignment in Visual Basic on a computer with no mouse. I told them to go fornicate themselves just as I would today if asked to compete coding tasks in some made up language.
Good lord that is awful you had to go through someones ego wet dream. I've seen many firms belittle a candidate who was otherwise extremely talented outside of a firms quest to seem intelligent. A lot of firms seem to have this tech bro problem. But the world is waking up to the unreasonableness that the industry is practicing.
I think this is a ridiculously bleak way of looking at things. The glaring flaw in your reasoning IMHO is this: when someone puts out a test like this, _they want you to succeed_; after all they are trying to hire people, it is to their advantage to find someone who can pass the test. If you immediately see every challenge that you're not sure you can handle as evidence that someone "[thinks they] are smarter than everyone else" and is trying to belittle you, you must be suffering from an inferiority complex.
Not to put too fine a point on it, but reactions like "you must be suffering from an inferiority complex" or "you need therapy" are exactly the sort of blame shifting one should expect from SV brogrammers. The only voice missing is the one saying "if you can't hack it, quit". The problem is never them, the problem is always you.
I don't see a challenge as evidence that someone is/or believes they are smarter than me. On the other hand I can clearly see that some tangential challenges are given to job candidates "because FAANGs did them" making the potential employer at best a parrot and that they likely feel smarter than those they hire. I don't feel I have an "inferiority complex" but neither am I intimidated by smart candidates. I feel no need to make them sweat or demean them. In fact I would rather hire people who I feel are smarter than me. Wouldn't you?
Programming in a made up language and solving problems like "How many toilets in NYC?" serves no productive hiring goal other than to make the test giver feel smart about knowing the answers while the test taker struggles to to remember if your made up language used let or was it set and why the hell are they asking me about toilets?
Along the same lines, I feel if someone is asking typical programming challenges like "balance a tree" then they are wasting their time and the candidate's time. That is an implementation detail that you can lookup. Likely there is a library that will do it for you.
In my opinion a clearly superior question is "Why might you want to rebalance a binary tree?". A better version of the afore mentioned task would be "Now you have explained why one might want to balance a tree, using any and all available resources show me how you might do that in practice." With top marks going to the candidate that finds the standard package and calls balanceBST().
I hire and manage an international staff of coders from North America, Eastern Europe, South America, and India and frankly I could care less if someone can implement a recursive tree walker or regurgitate a k-means clustering from memory. There are literally libraries maintained by others to do that. If for some reason I cannot fathom, we needed our own, I would damn well expect my staff to use resources like google, wikipedia, and open source to assist in writing it rather than have us all thank our lucky stars we work at that company where everyone knows how to hand roll a tree balancer only to find that we wasted a sprint dealing with an "off by one error". If one feels they absolutely must test for understanding of basic concepts such as recursion, composition, or inheritance, there are plenty of established interpreted languages to use.
Do you (rhetorically speaking) really want to make your job applicants uncomfortable by shoving a made up language at them that only you and your buddies know? Is your stack so mutable that you need candidates that can deal with regular resets to the platform of the day? Hopefully great candidates realize that a test in a homebrew language is a dick move and likely a signal of a larger organizational problem and politely thank you for your time then take their expertise elsewhere. There are plenty of other opportunities.
> In my opinion a clearly superior question is "Why might you want to rebalance a binary tree?"
How would you answer a prospective candidate who's convinced the only reason you would ask such a question is to make them feel stupid? [After all the concrete choice of a BST to implement a collection is an "implementation detail" that most programmers probably rarely have to worry about.] Is this attitude less defensible in response to your question than the test in the original post? It seems to me that if you feel that way, it is only because you have an inside view on how your question is testing something valuable. The author(s) of the original post almost certainly feel that their test is testing something valuable too.
> In fact I would rather hire people who I feel are smarter than me. Wouldn't you?
within reason :P
But I would certainly rather work with/hire people who will not assume everything I tell them to do is primarily/solely motivated by some narcissistic self-serving intent until I dedicate extra time to proving otherwise. I feel life is too short to deal with that.
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.
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.
This feels so almost right and so full of footguns at the same time. Learning a New Language is something that can be 2-3 weeks or several months or even years. Learning a New API should be N + M where N is the complexity of understanding ~basically what’s being expressed and M is the complexity of the API. (With a big amount of wiggle room for wildly different abstract concepts)
I’m all for “we created a new language for interviewing”, but I think its primary goal should be resiliency from language unfamiliarity (eg it must be both interpreted and reasonably able to translate approximately correct pseudocode to whatever its runtime or compiled code expectations), and then you can evaluate how people interact with the new API they learned.
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.
And I don’t even know if any of that’s realistically achievable but I’d find it much more valuable than evaluating also can you learn an in-house private language while trying to demonstrate you can code?
"...hire not only coders who are familiar with today’s technology but those who are capable of learning any new technologies that spring up in the future."
But it seems like a vanity project with brogrammer goals and a huge waste of resources.
I personally feel that interview gimmicks like this are a major reason we lack diversity in our field. Want to keep marginalized candidates out of your organization? Create a gimmick to intimidate and mock them during the interview process. Then sit back and pat yourself on the back for being so clever.
This is like looking to hire an English teacher then asking them to prove they can teach in Esperanto in order to get a job.