Comment by lifeisstillgood | Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

Parent Full thread

lifeisstillgood

I think the main point from a candidate perspective is that long, unusual or difficult interview processes are fine as long as we have already decided we really want to work for you (that is you are Trello or SpaceX or some amazing startup we love)

otherwise, just as you are faced with picking a rose from a faceless mass of candidates so are we faced with picking a decent place to work from a faceless mass of mission statements and "100%code coverage" blog posts (if we can find any)

And 2) yes I can believe it - that's what fizzbuzz and its ilk are for. The number of companies offering hackerrank/codility tests and justifying it as we only hire the very best has left the lake woebegone test way behind.

There has to be some middle ground - where someone can pass a basic capability test to weed out the crap without demanding several hours of coding. I mean I spent two evenings recently polishing up a "Oyster card system for TFL" as a hurdle for a government department I have been angling to get in for a year. A no-name corporations wanting CRUD development can take a running jump if it thinks my evenings come cheap.

(amazingly at the turn of the century I used to use "has listed Python on CV" as a marker of "worth an interview" - it was rare enough and indicated an interest outside of corporate mainstream. Maybe Erlang today??)

Edit:

So my compromise suggestion is for companies to say "We have an OSS project (or even recommend one of the bigger ones). Take any of these 5 bugs and supply a pull-request"

At least then the evenings work is not totally wasted and you get to see an important skill - how fast can they come up to speed on an unfamiliar codebase?

The trouble with using bugs is that most of the work for fixing them is in isolating just what's going on and where the problem is, and there's no telling how long that will take until you do it. A bug on a new codebase could be anywhere from a few minutes to a few months.

In particular, if you don't know the codebase, you're going to be guessing on places to look. If you're lucky and guess right, you may spot it right away. If you guess wrong, you could spend a lot of time diving around irrelevant details. There is some skill in guessing well and not spending too much time on things that don't give any progress, but there's still a lot of luck too. Because of all that, it doesn't seem like a good idea to assign a bug that you haven't already essentially fixed.

Maybe it'd work to just timebox the task, i.e. 'work on one bug for an hour', along with 'document everything you find and learn' (and add it to the public issue). I'm a habitual documenter and I could imagine something like those 'papertrails' being a useful way to evaluate someone's thought processes (and written communication skills).

We actually only do 2 interviews total, and for some roles a Hackerrank quiz.

The only times we use coding tests, we use Hackerrank to administer them. That way you have a distinct time limit (we give an hour, which is honestly way too long) so you don't spend all weekend one something that doesn't matter.

I definitely agree about the difficulty of picking a place to work. We reserve half of our final interview (and part of our initial interview) to be a Q&A for the candidate to interview us.

I think that Hackerrank etc are optimising for the wrong question. 98% of the time as a hiring manager I am not looking for a AAA coder - I am looking for an A level coder who fits the team and has other soft skills that matter.

At a certain point "can code" stops being "can write perfromant algorithms" and starts being "can work without direction, can be placed in front of users without fear, can defend their decisions, is not an asshat."

Ten minutes on a shared screen and we can find out if you pass fizzbuzz, can make a rational stab at an algorithm question. After that it's mostly cultural fit.

You cannot automate a test for "is not an asshat" so we get more and more people proving they can get 99% on programming tests when programming tests are 5% of the job.

Hackerrank is terrible as well. The questions are worded in a way that takes ages to think about unless you are a mathematician. The time limit is pointless.It doesn't tell you why things are failing. For the type of problems it gives you a debugger would be really useful but you are coding in a web browser.

Oh wow that's really, really good -- turn recruiting into fix bugs in an OSS project. Nice! That's good for everyone.

Haskell rather than Erlang.

Reply on news.ycombinator.com