Puzzles, interivews

[izard]

Now every technical interview involves a whiteboard/computer coding/solving of simple/medium level puzzles. As any sport, one needs recent practice to perform well. I did not practice in that since 1998, and I only had one such interview in ~2010 with google, where I failed.

I don't argue that it is not a worst proxy for evaluating programmer's job performance (in the same way as running speed/stamina is a proxy for evaluating football player skills).

I decided to spend some time to understand my current status and improve it a little bit. So I selected a random puzzle from hackerrank with medium rating and low average pass count.

It took me about 3 hours in total to come up with a correct O square algorithm, and one hour to implement.

This Clojure implementation by the way is probably not O square as it times out on bigger tests. So I need either to profile it and fix, or re-write in C where reasoning about execution time is trivial.

So if I got this puzzle at a Google/Facebook/whatever interview, I would have failed, as one needs to solve this in 30 minutes, not 4 hours. And when I encounter puzzles of similar complexity at work (not very frequently, maybe once every couple of months), solving it in 4 hours is never an issue.

Upd:
For two people, who are much brighter than me, it took several minutes to find the algorithm which is O(n) and describe in the comments. I implemented it (took me half an hour), and now it passes all hackerrank tests:

Comments

[juan_gandhi]

Pretty simple, no? I'd rather collect the frequencies of remainders mod k, then choose those remainders which complements are smaller, with the exception of k/2 (here just take 1), and then scrape the list again, taking the ones that belong.

I believe though that coding exercise is not about solving puzzles (puzzles are for freaks), it's about simply checking whether the patient has a CCD ("can't code disease") or not. For that, almost any, pretty simple, problem would do.

Another thing is checking the patient's ability for abstraction; that's a harder problem.

[izard]

Right, I just read the same solution in livejournal cross-post, now implementing just so see how simpler it is.

For CCD, simple puzzles will suffice, and Google et al are using medium - like this one.

As for abstractions - I think discussing /reasoning about implementation details of database/OS kernel/CPU pipeline/CPU caches/IP routing/switching/filtering (depending on a job area) usually provide a clue. But that would be difficult to quantify, unlike puzzles.