An instant Do Not Hire decision
Following a phone screen, we typically ask candidates to complete some coding tasks. The idea is that we want to see their code and asking a candidate to program during an interview… does not go well. I had a candidate some years ago that was provided with a machine, IDE and internet connection and walked out after failing for 30 minutes to reverse a string. Given that his CV said that he has 8 years of experience, I consider myself very lucky.
Back to the candidate that prompt this post. He sent us answers to the coding tasks. In Node.JS and C++. Okay, weird flex, but I can manage. I don’t actually care what language a candidate knows, especially for the junior positions.
Given that we are hiring for junior positions, we’ll usually get solutions that bend the question restrictions. For example, they would do a linear scan of a file even when they were asked not to. For the most part, we can ignore those details and focus on what the candidate is showing us. Sometimes we ask them to fix a particular issue, but usually we’ll just get them to the interview and ask them about their code there.
I like asking candidates about their code, because I presume that they spent some time thinking about it and can discuss the topic in some detail. At one memorable interview I had a candidate tell me: “I didn’t write this code, I have no idea what is going on here”. I had triple checked that this is indeed the code they sent and followed up by sending the candidate home, sans offer. We can usually talk with the candidate about what drove them to certain decisions, what impact a particular constraint would be on their code, etc.
In this case, however, the code was bad enough that I called it. I sent the candidate a notification about the issues we found in their code, detailing the 20+ critical failures that we found in the space of a few minutes of looking at it.
The breaking point for me was that the tasks did not actually work. In fact, they couldn’t work. I’m not sure if they compiled, I didn’t check, but they certain were never even eyeballed.
For example, we asked the candidate to build a server that would translate messages to Morse code and cause the server speaker to beep in Morse code. Nothing particularly fancy, I think. But we got a particular implementation for that. For example, here is the relevant code that plays the Morse code:
The Node.js version that I’m using doesn’t come with the relevant machine learning model to make that actually happen, I’m afraid.
The real killer for me was this part:
You might want to read this code a few times.
They pass a variable to a function, set it to a new value and expect to see that new value outside. Basically, they wanted to use an out parameter here, which isn’t valid in JavaScript.
That is the kind of fairly fundamental issue in understanding the flow of code in a program. And that is something that would never have worked.
I’m okay with getting sub optimal solutions, I’m not fine with it never have been actually looked at.
Comments
Yeah I think you can be pretty confident that if you hired that candidate they'd follow the "write code, commit code" model of development, without the "compile code, run code" steps in the middle!
It highlights the lack of understanding of the fundamentals i.e. pass by reference vs value here and knowing the limitations of a language.
The typo in "let mosre" also tells me the applicant is not a perfectionist. I know I am, and this makes my eyes bleed... However, would the rest of the code have been perfect, I'd probably have let this slip as I know I'm sometimes more on the over-quality side than the just-right one...
Btw, aren't the key and value inverted in this lookup? This dictionary is supposed to translate from characters to morse, not the other way around?
Olivier, this is how you handle MOSRE code
Olivier,
Yes, and they were like that for the candidate . No idea why
Well now I feel a little better about my solution lol.
Comment preview