Life, the Universe and Technical Interviews

“There is a small satellite orbiting an unremarkable planet 50 light years from Earth. In spite of its tiny size, this floating cube of metal and silicon carries a load of paramount importance to the infrastructure of our galaxy. Inside its computer resides the Big Developer Matrix. As you can infer from its name it is fairly large, and it contains information about developers. More specifically software developers, because it was created by software developers. Each row of this matrix represents a company, and each column a developer. Every cell contains a binary value, which means either HIRE or DON’T HIRE.

The Big Matrix is rather sparse, and it is widely used by software managers across the Milky Way. In fact, it is the standard tool for hiring decisions pretty much everywhere. There are some fringe planets like Earth who rarely query the Big Matrix, and nobody is quite sure why. One of the maintainers of the software suspects it may have to do with a mismatch between the latency of communications and the average life spans of humans.”

— The author of this post, just now.

Unfortunately for us humans, we have little choice but to conduct technical interviews. We need an answer to the question of whether we want to hire someone or not, and we don’t have the time to really assess someone level of technical competence. Many try to approximate the Big Matrix with a series of progressive Bloom filters: techniques that tell you DON’T HIRE this person or INCONCLUSIVE. FizzBuzz is a good example of a Bloom filter question. I’ve never asked it to anyone and I don’t think I will; if you have to ask that question, you probably should rethink your pre-interview selection process.

One of the things I dislike about FizzBuzz is that it reminds me of customs forms with questions such as “have you ever been a member of the Communist party?” It’s almost insulting, and there is no way to show that you’re a good developer by coding FizzBuzz. There are questions that serve a similar purpose, while at the same time giving the candidate an opportunity to show off some skills. Here’s an example of a question that I like, even though I’ve never asked it:

Write some code that calculates how many numbers under a million (positive integers) have digits that add up to 42.

Why do I like this question? For one, it doesn’t require any specific knowledge besides basic programming techniques and math. Anybody who spent some time programming in some language should know enough to solve that in a few lines. Also, it has a mundane element that you normally encounter in real-life programming: one straightforward way of answering the question involves converting integers to strings and back. Furthermore, it lends itself to elegant functional solutions. Finally, getting the reference is an added bonus for personality fit 🙂

I asked this question on Twitter a couple of nights ago just for fun, and got some quick responses. The first one, in Haskell:

another one, in Python:



One of my favorites, in C and bash:

One I did in Clojure, without using strings and using recursion:

(count (filter #(= 42 %)
               (map (fn d [n]
                      (if (> 10 n)
                        (+ (mod n 10) (d (quot n 10)))))
                     (range 1e6))))

One in Forth by @technomancy:

s dup if 10 /mod recurse + then ; : f 0 1000000 0 do i s 42 = if 1 + then loop ;

I couldn’t fit a Java version into a tweet, but someone did it with Java 8:

class S{public static void main(String a[])
{int i=0,j=0;for(;i++<1e6;j+=(i+"").

@ejenk reduced the Haskell version to:

length . filter (== 42) . fmap sum . replicateM 6 $ [0..9]

There were a few other good solutions. The shortest were in languages like sed or Wolphram, which allowed the authors to “cheat” somewhat.


I will never get to ask the 42 question in an interview. If I did, I wouldn’t expect a candidate to show off code-colfing skills. I might ask about performance considerations for a larger space, and be pleasantly surprised if the candidate pondered solving the problem  mathematically for a second.

While this particular question may seem very easy in the comfort of your browser and favorite editor, it’s not trivial in the context of an interview. Always remember that technical interviews are very stressful; some of the best candidates I interviewed had sweaty palms upon entering the room. Even the best of us sometimes forget to bring a towel.