| In cover letters, I've made clear that I enjoy and welcome interview puzzles. You may never actually be asked such a puzzle; but since the vast majority of interviews are non-technical pageants, it "signals" some confidence and that you "get" what position the interviewer's in. I've been asked twice to solve out-of-interview puzzles, and once an in-interview puzzle. In each case, I asked for other people's (anonymized) solutions/times. In both cases, this was with Common Lisp using companies. Your experience may differ, but: * Everyone else took shortcuts in out-of-interview puzzles. Most wrote almost no comments (a couple had overly chatty ones), nor was the code packaged in an easy-to-run way. Even most good solutions would cut a corner by (for instance) assuming that the input was magically pre-parsed from strings into symbols. So, there'd be a couple of good-but-somewhat-unpolished answers, a few which were visually messy and over-simplified the problem, a couple where it wasn't really solved and the programmer maybe apologetically produced a best-attempt, and one which wasn't even in a known programming language. (The last one deserves the most sympathy, as he/she almost certainly had mental problems.) In contrast, imagining that everyone else was a hyper-professional Programmer O' Doom, I packaged it all with ASDF (including instructions) and polished it as if, say, generations of island-stranded maintenance programmers would use my solutions to figure out where to sit in order to not be eaten by a cannibal. One thing that probably goes over well is to point out a possible problem with a part of your code -- and a justification. Like a comment saying, "Note: Some Lisp implementations don't perform tail-call optimization. However, for real-world inputs, they would nevertheless suffice and be more maintainable than alternatives." * People are human, and often have problems with in-interview puzzles. Part of my mind mysteriously blanked for a short while when asked what I felt was a trivial question -- permute a list of 3 elements (performance irrelevant, run the solution in Common Lisp). My imaginary Programmer O' Doom no doubt typed it from finger-memory in seconds, after whimsically sketching a solution where she randomly permuted the elements until enough unique ones were uncovered, or enumerated them all at read-time or something. So, I stammered out an apology because I took a few minutes, jarred and ready to crawl into a hole for being unmasked as a fraud. Well, it turns out that the previously fastest solution took over an hour. (Of course I remained a fraud, albeit a still-unmasked one...) Maybe it helps to think of such interview puzzles as a symptom of society's diseased way of working; then there is less stress. They're fundamentally mindless and people often derive an elitist thing from them; it's hard not to. I may welcome them, but it's also the case that each side whores out natural curiosity for the sake of filling some corporate job. |
That's intended to mean that the the recursive solution is more maintainable than alternatives. (Or so I glibly claimed...)
And of course, I meant "masked fraud".