I write terrible code when I go to a job interview. That’s mostly because, when they ask me to solve a coding question, I get nervous. I thought it might be entertaining if I wrote about one such encounter.

Yesterday I went to a job interview, at a company in New York that had once built their stack (for managing online advertising) in Ruby but who are now transitioning all of their stuff to Clojure (Adaptly).

On this particular day, I was to talk to 3 of their senior developers, and 2 of them would hit me with their favorite questions about how to find something in a given number series.

When I got to the company office, they put me in a conference room and sent in one of their senior engineers. He asked me to fire up a REPL, so I launched Emacs and then “nrepl-jack-in”. I was ready to go, but I was also very nervous, because of these 3 reasons:

1.) I’ve got a guy looking over my shoulder and he’s watching every mistake I’m making

2.) I’m suddenly self-conscious about the prettiness of my code — it doesn’t matter if I can solve the problem, since I’m also competing against candidates who can solve the problem, so the real competition is probably about how elegant and idiomatic our code is

3.) this isn’t about getting the job done, it’s about being quick — the pressure to move fast is strong

I was typing code into a live environment, which would then execute my code when I hit “enter”. For those of you who haven’t seen the REPL in Emacs, my screen looked like this:

And yet, as our conversation proceeded, one problem I eventually faced wasn’t Clojure or math, it was English — we had a misunderstanding in our native language!

He asked me if I knew what the “Happy number sequence” was. I said I had never heard of it. He described it like this:

“Take each digit in a number and square it, then add the sums together. Keep doing this recursively.”

The next sentence of English is where the problem started. I thought he said:

“The sequence will either go to one or to infinity.”

but he actually said:

“The sequence will either go to one or infinitely.”

He then offered an example of how to find the next number in the sequence:

“Suppose you start with the number 31. Well, 3 squared is 9 and 1 squared is 1, and 9 and 1 added together is 10, so the next number in the sequence, after 31, is 10.”

And then, with “10″, the “1″ squared is 1 and the “0″ squared is 0, and when you add 1 and 0, you get “1″, therefore we know that “31″ is part of the Happy sequence, because, after 2 iterations, it ended up being “1″.

That much was obvious, but I could not figure out how to test a sequence that goes to infinity — how would I know when to stop testing for more numbers? I mean, I might get to a septillion, but I’d only be taking a small step toward infinity — and then I would need to keep testing till I get to infinity… which is impossible? But I wanted to appear smart, so I didn’t express any confusion. I was thinking that if I dove into the problem, then it would eventually make sense to me. So I started coding in the REPL. The first thing I needed was a function that would find the next number in the sequence, and this would surely be easy:

Oh, good lord. This was the only way I could think to get each digit in a number:

snc (str x)

but this actually gave me a sequence of Characters, not strings. In the real world, I would have stopped at this point, gone to look at the documentation, and maybe found a more elegant way to do this. However, under pressure of time, I just started piling on bandaids to try to fix things enough to get it to work:

Ah, damn! The correct answer is “10″, but I am getting 2601! What the hell went wrong?

At this point, the guy interviewing me is starting to get bored. I can see his eyes drifting elsewhere, he starts checking his phone for messages. I am thinking that in his mind he has already decided that I’m a pathetic loser. In a different industry, he might simply shout “Next” and kick me out and drag the next applicant in, but our industry is slightly more polite than that. So he waits for me to stop screwing up. But he looks very bored.

I notice that I am, for some strange reason, summing twice, so I take out the redundant “+”:

In retrospect, the error is obvious, but under the pressure of time, my mind was racing and I was not seeing the problem, so I added some print statements so I could better understand what was happening:

Hell! What is the right method call? I’ve done this many times before, I just can’t recall, right now, the way to write this. I turn to the guy and ask him permission to look this up in my old code. He gives me permission. I look at some code that I’ve written and see the correct way, and so I can do this correctly:

Uh, so, I have a bracket in the wrong place? I have keybindings set up so that Control-1 takes me to the start of any form, and Control-2 takes me to the end of any form, so I can usually, rather easily, see how the brackets line up. But that doesn’t save me from bad thinking under stress.

The guy who is interviewing me has mostly stopped watching, because he’s already decided there is no chance in hell that they will be hiring me. He is looking at his phone. I half expect him to start playing Flappy Bird.

I realize now that the verbose and horrible “Integer/parseInt (str” needs to be applied to the sum at the end of the “if” statement:

And yet, I am only at the start of this problem. Writing a simple function to find the next number in the sequence was suppose to be the easy part, and I just wasted 10-15 minutes on it!

So, how do I find out if a number is in a sequence, when the algorithm might lead to infinity? I had previously postponed the question, but now I came back to it. Again, our problem was English, not Clojure.

Thinking out loud, I said: “If the sequence can go to infinity, then I could create a generator that returns the numbers lazily… but at some point we would need to realize those values, to check them… ”

“That is one way to think about it,” he said.

I kept thinking out loud: “…and if they go to infinity, then they will crash my machine…”

“Are you sure?” he said.

I thought long and hard about that. Was I missing something obvious? Was there a way that my machine could count to infinity?

I was quiet a long moment because I was worried that whatever I said next would make me look stupid.

“Well, I could pass in some bound, like perhaps 10,000. I could pursue a finite number of tries before giving up.”

“Are you sure?” he repeated. “Are you sure the numbers go to infinity?”

“Didn’t you tell me that they go to infinity?”

“No,” he said, “I said they go infinitely.”

Finally, the light dawned in my head.

“Oh,” I said, “So they loop?”

“Yes.”

“Oh!” I finally got it. “So they loop over a finite set of numbers?”

“Yes.”

“Ah! So I only need to store the numbers in a set and then I can see if I start to loop?”

“Yes.”

Okay, so now I got it. I could store the numbers in a set, and if I ever saw the same number twice, then I knew that the number that I started with was not in the Happy sequence.

Wait, what am I doing? The “happy” function simply finds me the next number in the sequence. I need a function, higher up the chain, that can loop through the whole series, and call “happy” on each iteration of the loop. I reset the “happy” function to the previous version that was working, and then I start on a new function:

I have to take a deep breath and think, for a moment, about what I want to return. By this point, so much time has dragged by that the guy who is suppose to be interviewing me has largely stopped paying attention to what I’m doing. I figure the interview is a bust anyway, so I can take a moment and think about things clearly. The pressure of time disappears once I realize there is no chance I am getting this job.

I know I want this:

(if (= next-integer 1)
true

That is, if the next number in the series is ever 1, then we know the starting number does belong to the Happy sequence, so we should return true.

And I know I want:

(if (seen-so-far next-integer)
nil

That is, if I have a set called “seen-so-far”, and I store all the numbers that I discover as I iterate through sequence, then if ever I see a number twice, I can conclude that the series is settling into an infinite loop, and I can return false, because then I will know that the starting number is definitely not part of the Happy sequence.

Needless to say, the job interview was a disaster. I think they want someone who can write something like this in 5 minutes, but between the English-language confusion over the definition of the sequence, and the many mistakes I made, this dragged on for almost 30 minutes.

After I was done, the guy said something polite about “good effort” and then he said he would sent in the next engineer.

A few minutes later the next engineer came in. He asked me if I knew what the Collatz number sequence was. I said no. He drew a definition of it on the white board. He asked me to write some functions that would allow me to find the longest iterations through the Collatz sequence, given a set of starting numbers.

What followed was similar to the above: for more than 30 minutes I stumbled through the process, making dozens of mistakes as I went.

Interviews are weird: the pressure of time, and not being able to look things up, distorts the code. I am aware that the code I wrote was ugly, especially the atrocious casting of the number to a string, then to a sequence of Characters, then back to a string, and then back to an integer. But now that I am back in the real world, and able to do a Google Search, a quick search brings a top result that points me to an example by Saul Hazledine:

(map #(Character/digit % 10) (str number)))

So, in the real world, that is what I would have gone with and my code would have looked a bit better.

I guess there are engineers who stay calm in situations like this, and I assume this must be true of all the programmers who got hired at the place. I guess this is a bit like the situation in basketball, do you panic when a defender is faster and taller than you, or do you stay calm and pass the ball in an intelligent way. These tests perhaps bring out how I write code under pressure, like if its the end of the sprint and I’m working on a task that absolutely has to go out during this sprint, though hopefully such crunch-mode programming makes up less than 5% of our programming, since this is when the worst kinds of “technical debt” gets created. Or, possibly, tests like this allow them to hire those programmers who never create “technical debt” no matter how much pressure they are under — but I would be skeptical of that claim.

Expressing confusion in an interview doesn’t make you appear dumb. In reality it’s quite the opposite.

This is terrible advice. The advice is common, but it is wrong. Multiple studies show that your questions can have a subconscious effect on the person interviewing you. Even if they say “Please feel free to ask questions” if you phrase the question the wrong way, or ask a question outside the bounds of what they were expecting, it becomes a mark against you. The effect can be subconscious, but the bias will cost you a job. When you are in the presence of someone who really wants you to ask questions, that typically becomes apparent after a few minutes of talking to them, and in those cases you can feel free to ask what’s relevant — however, it is unwise to start with the assumption that the person who is interviewing you will automatically give you the benefit of the doubt — it is much wiser to start off cautiously and figure out who you are talking to, before you ask too much.