Hacker News new | ask | show | jobs
by gilleain 3157 days ago
We do the same. It's amazing to me how many people with superficially impressive CVs do one or more of:

* Cheat

* Fail to follow simple instructions

* Write no tests for there code (even the given examples!)

* Just horribly fail to implement an algorithm

All in all, it's just a filter to be used before proper face-to-face interviews.

3 comments

> Write no tests for their[sp] code (even the given examples!)

Well, I've been on the fence on this one. With imperative languages, testing is pretty much a requirement because of side effects and scope-creep (nahh, throw it into global).

Tests can be a good sanity check for simple checks like "I fixed a bug where X is supposed to give 22. Lets verify that"... But the problem is the tests are then code that can update and rot as main code changes occur.

I've preferred a more functional method. I don't want to test - I want to prove a function handles its inputs and provides the correct outputs. Unless there's a good reason for state , I prefer keeping functions clean. And even then, with state (say, a tally function for bandwidth), I prefer to have the variable updated with its own function. Keeps clean/nonclean separate.

Now.. one thing that's absolutely not acceptable is not commenting code. "Magic sequence in perl doing 6 things unintuitively" is not code comments. :(

One person's "Magic sequence in perl doing 6 things unintuitively" is another person's "I actually know Perl, and the standard functions being used here, so this is nothing special".

Comments are good, but what's aceptable as a comment is entirely subjective to someone's competence in the language in question.

For example, if you can't look at a Schwartzian Transform[1] in Perl and understand what it's doing, if not immediately than after a moment or two of looking at the steps, then you do not actually know how to program in Perl, you're just muddling your way through. Nothing in the transform is special, and if you are confused by anything in it that's the equivalent of being confused by arrays and simple array syntax in C. A comment of "optimized sort on computed X attribute" should be more than enough, but to anyone slightly unfamiliar with Perl it will seem woefully inadequate.

1: https://en.wikipedia.org/wiki/Schwartzian_transform

it is java, so yeah. of course production code could have all sorts of levels of tests and qa and all that jazz.

really, though, if i'm implementing an algorithm that i've never coded before it would seem strange not to write at least some kind of verification of its correctness.

comments can be language dependent - perl yes, java maybe (on an API, definitely) - and situation dependent. i wouldn't care about comments on small amounts of code with good variable names and sensible structure, for example.

edit : also apologies for the formatting, i hate typing on a phone!

> Write no tests for there code (even the given examples!)

Just curious, do the instructions ask for tests? If one of these "programming quizzes" asked me to implement algorithm XYZ, I would follow it to the letter and implement only the algorithm.

we don't ask them to actually provide their tests, but implementing a non-trivial algorithm without tests is optimistic at best.

we give them a couple of examples (input, output) pairs - surely you would at least run your implementation past these, right?

I find that the quality of candidates is a function of the quality of the hiring funnel and the money offered.

If your funnel spits out 'surprisingly' shitty candidates then it's probably not the best funnel.

there are also surprisingly good candidates, as well. this is just the top of the funnel, but agreed that it could be better.