We created a new programming language just for our interview process
blog.momocentral.com
blog.momocentral.com
"...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.
What exactly are "brogrammer goals"?
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.
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.
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.
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.
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’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.
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.
https://web.archive.org/web/20180703102005/https://twitter.c...
This is akin to having candidates answer questions by calling a automated line and recording their responses in two minutes.