+972 52-548-6969
How to really fail a coding interview
Our current interview question is from this post. We use that between the phone interview and the actual interview to get a feel about a candidate abilities. You can learn a surprising amount of information from even small amount of code.
Note that one of the primary goals of such a question isn’t to tell you “You should really hire this candidate” but to tell you that “You really shouldn’t”. To clarify, this is a “do it on your own, and you got the whole internet at your disposal” kind of question. Typically we give a week or so to answer this.
Sometimes we get a very clear signal from the code, like in the case of this code:
But I think the crowning glory was this code:
I picked two of the worst offenders, but there were more. Some things I can sort of let slide, and some things I’ll just say no to.
Comments
Well, there are really bad candidates who have no idea what they're doing. You didn't really need such a difficult test to weed them out, a simple FizzBuzz-level test would probably have been enough.
Would it, Thomas? The two applicants above seem capable of writing working code, the issue is that their code is surprisingly inefficient. (It's surprising, because there is a much simpler and seemingly more obvious way to write the code, which performs much better.)
I think something like FizzBuzz might be too simple to reveal that issue, especially since FizzBuzz does not give you much opportunity to have bad performance.
The first one is quite amazing!
Slightly OT: Currently in a battle with some members of my team that insist on using Equals for comparison, even for built-in types
on Principle of Least Astonishment grounds (see here)
What is really astonishing (pun intended) is the ability of some people to overcomplicate even the simplest thing. As I tell them, "coding is hard enough as it is, no need to make it any harder".
Where's "fuck.cs"?
Fidel, That is implied.
Comment preview