Embarrassing code I wrote under stress at a job interview

In the interviews I do, I tell the candidate that:

1. There is no time pressure. Work at a normal pace, as if you were working here. This is not a speed test. I don't expect you to finish. I mainly want to know how you think.

2. You should look things up. Behave the same way you would when coding at home. Use Google, Stack Overflow, documentation, etc.

This probably works better for the interviews I give because the problem is not implementing an existing algorithm. It's a realistic task, something that we've actually built on-the-job.

> But I wanted to appear smart, so I didn’t express any confusion.

And I don't get it. When I ask questions, if anything, I get told that I seem smarter for it. Asking questions is a sign that you're paying attention and actively trying to understand things. I don't think I've ever had anyone question my intelligence for asking questions for clarification.

(I'm not trying to criticize the OP in particular for this. I've heard it from a lot of places, and wanted to point out the fallacy.)

- Pick a real world task (e.g. text munging).

- Suggest in advance that they bring a laptop with their preferred work environment. Allow any reasonable language if you're willing to train them on your stack.

- Write the problem down ahead of time. Have someone else at your company read it.

- Do the problem yourself. Ballpark your estimate for a great candidate at 3x the time it took you.

- Tell them there is no penalty for using stack overflow over the language docs.

- After you give them the problem, give them a few minutes in peace (leave the room) while they think it over. Talk about their approach out loud before they begin working.

- Ask them to spend 5-10 minutes re-factoring their code once it's working.

Regarding the interview, there's this trick I learned that presenters do when they come on the stage. Instead of focusing on the audience and their talk immediately, they first drink a glass of water slowly. It lets you set your own pace, and deal with the first high of adrenaline a little.

In this case, they asked you a question and you immediately fired up a repl and started typing away as if it's a race. But if no one is holding a stop watch it's not really a race. If you're going to have to do this kind of interview more often, perhaps practice on your generic problem solving strategy.

If it were me, I'd probably ask for a piece of paper, and then write down the components of problem on the highest level, then drill down the details of each component. At each level of detail check with the interviewer if the requirements of the component match their intentions. When you're confident you've got the algorithm down on paper, then you can start on working it out in the REPL.

Also, I'm not a LISPy guy so no idea how you usually do this, but those first three mistakes you made were horrible. Obviously you were nervous, but these kinds of mistakes don't happen if you have a good IDE and disciplined code style. You can't miss matching brackets if every opening bracket starts a new line and a new indentation level. You can always clean up the new lines when your algorithm is done.

Practice and preparation are the best countermeasure to stress.

Not that I agree with this interview style at all by the way. You are most likely an excellent developer, and if they don't decide on hiring you they probably are making a big mistake. If I was hiring Clojure people I'd be surprised I'd get someone that would work a REPL like that without internet reference at all.

Live programming interview tests are rubbish, because:

a) They produce a huge rate of false negatives. People who do not "interview well" flounder in a programming task with someone peering over the shoulder.

b) They can only test "algorithmic" tasks (for lack of a better definition). Most programming is not algorithmic, it's higher level: glueing already written libraries, with very light data manipulation or validation.

The studies that get brought out every time this comes up are very clear. The best predictor of future success is a work sample test. Solving a bitesize problem in 20 minutes while someone watches over your shoulder is not a work sample test--it's about as far away from a work sample as you can get and still call it programming.

At the very least why not let the candidate work on the problem on their own for 30 minutes and then check back in.

I've said it before, the best interview process I've ever heard of is this:

Pair the candidate with an interviewing engineer, give them an hour or two to solve a problem as a team. The interviewer isn't an adversary; their job is to assist the candidate like they would if they were working on a real problem.

Repeat this process if necessary.

Get everyone together and talk about past projects the candidate has worked on. Have the interviewers evaluate the candidate, and make your decision.

You know whether the candidate can code, and you've removed the adversarial nature and unnecessary stress from the interview process. Most importantly, you got to see them work in a much less artificial environment that's closer to what they'll be doing day to day.

I remember once being so nervous that I completely blanked. I'd been asked to reverse a linked list. A very simple task, one I'd even practiced a few times in various languages prior to my interview and should have been able to breeze through.

But I froze. My hands were visibly shaking as the interviewer stared at my back... I shut my eyes tight, trying to think through the problem (I knew this was a simple task, and I was frustrated that I somehow couldn't recall the solution). At first I tried to write out a recursive solution to the problem, but my anxiety-riddled brain just couldn't cope with recursion that morning. So I erased the board and started over trying to find an iterative solution. That went even worse.

"Um, I need to repeat this block of code, I think, maybe. There must be some way, some kind of construct that causes a block of code to be executed several times, almost as if one were looping through the code." AGH! Think!

But I was coming up empty, I searched my memory, ready to seize on the first seemingly helpful thing I could find. And so my mind wandered back to a time when I was about 8 years old, learning to program for the first time on my Apple II. I had just discovered the magic 'GOTO' command, which was the perfect tool to cause uncomplimentary messages about my older sister's hygiene to scroll down the green mono display for all eternity (or until someone hit Ctrl-C).

So... I completed my solution on the whiteboard using a GOTO. The interviewer put his face in his hands and began laughing. Eventually, he stopped and said "Um, ever heard of a for loop?"

"Well.... yes."

Fortunately, they didn't stop there and I was able to do harder tasks better later on ;)

I reacted pretty much in the same way on my driving exam. Both that interview and that exam weren't telling you anything about how I actually program or how I actually drive - even under extreme conditions. Being judged is just a completely different experience that makes me behave in completely different way.

I was really nervous, and since it was a phone interview, I tried to speak my thought process, which didn't quite work out due to me constantly stammering. So I just took to typing all the time so that my interviewer wouldn't think I was taking too long coming up with a language or copying answers. I started making silly mistakes like using `int sum=0` in python. I took the input as a number, converted it to a string, and then further converted it back to a number, and did mathematical operations on it, trying to solve the problem. Every time I thought I did it, it would get stuck in another case.

Ultimately, the interviewer deleted 50 lines out of my 60-line code, and just added a print statement on a variable I was already using for storing things temporarily, which turned out to be the correct answer.

Needless to say, I blew the interview. I haven't done an interview since, and I'm gonna be up for it very soon. I'm not sure if I'd do better this time, but I'd be ready with a glass of water, and try to be as relaxed as possible.

This is an incorrect assumption, at least when I interview people. A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you:

Do you approach a problem with caution until you're sure you understand it, or jump in head first and start writing code you hope is correct? Can you verbalize your thought process and communicate it to others? How good are you at reasoning about the runtime behavior and correctness of your solution? Do you consider edge cases and naturally want to test them? Things like that are won't show up in a take-home coding test, and tell me a huge amount about what kind of programmer you are, and whether I want to hire you.

See: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programm... - there's a lot of truth to this article, and many of these flaws will be glaringly obvious in a live coding session.

And yes, of course some people interview poorly or are just having a bad day. That's unfortunate, but I'm not about to give up a powerful interview tool just because it can have false negatives. Until I find a divining rod that will point out the best programmer in a room, asking a candidate to write some code is the fastest way to learn what kind of programmer they actually are. (And also immediately weed out people who can't actually write real code.)

(EDIT: this was actually a joke...)

Bad situation, but I don't draw any conclusion from it. There are lots of inherently hard things in life that get messed up if you are nervous, insecure and can't communicate. That isn't necessarily an argument against them.

E.g. when he calls (happy 97) it prints 88. However, that's 9^2 + 7, when in fact the answer is 9^2 + 7^2 = 130.

1) Agree with the interviewer before starting to code on the algorithm and problem. I.e. You could say I need function X that would be used like such, and function Y that would loop through such and such. Even better is drawing a high-level example on the board. That way, the interviewer knows that you understood the problem and can be systematic about it. (If you don't have a whiteboard, just write in comment at the top, whatever)

2) Once you start coding, start small.. especially in the REPL. I.e. instead of starting with the whole function, start with the string, then separate it in digits, then sum it up, then work from there. That way, if something doesn't compile, it's perfectly clear what step it was and once you have your function, you're 100% sure it works. TDD style.

    next = (n) -> "#{n}".split('').reduce ((p,c) -> p + c*c), 0
        
    happy = (n, set = []) ->
        return false if n in set
        return true  if n is 1
        happy next(n), set.concat(n)

    console.log(n, happy n) for n in [1..100]

Give the candidate a research paper in PDF, then ask them to implement the algorithm described there in code.

You get the same feedback on whether they can actually code, and what kind of code they write, but it takes the pressure off having to think of what kind of algorithm to use, what the big O complexity of it is, and a thousand other factors that will probably never relate to what their day job will consist of.

Consider that the interviewer has now seen that this person will choose to, without clear understanding of either the goals of the task or the task itself, work alone as though he must solve the problem in isolation in order to prove himself.

The most important thing that a candidate needs to be able to do on the job is discuss expectations; failing to do this in the interview is more egregious than any compiler error. Another important thing is to understand the problems they are working on; failing to even discuss the problem is more egregious than any compiler error. Another is collaboration and humility; you can demonstrate these skills in a coding interview as well.

This interview demonstrated many more important indicators of a poor fit than typing ones. Just because you pose a coding problem doesn't mean you're unable to assess candidates on the things that matter.

P.s. You are not a bad programmer... Pressure can mess your mind. My secret to finding great developers that everyone else misses is by making them feel calm (giving them an easy problem and giving them encouragement so interview stress becomes less a factor, best way to find good developers who just are bad at interviews)

One was a very simple task, setting up a server as a customer would at an ISP using WebMin type tool. Really simple stuff. Guess what. I couldn't figure it out in time. Maybe because I had been consciously staying away with gui stuff to stay sharp with cli. Or maybe the proprietary tool the ISP was using was very unintuitive. Maybe the suit and tie I put on for the first time in 2 years got to me. Either way, had I NOT been in an interview setting, I would've figured it out. But with this interview, I couldn't figure it out.

In the 2nd company, I was giving an online test using https://trueability.com/, to complete from home. Set amount of time to complete some test scenarios. Far more difficult stuff than setting up a small web server at an ISP. And I would say it was a far more realistic test of my skills.

IMHO, interview should really only focus on compatibility, not actual tech skills. If your company is really spending time on tech skill test DURING interview (especially onsite), you are doing it wrong. just my 2 cents.

     (defn int-to-digits [n] 
       (map #(Character/getNumericValue %) (str n)))

    (defn next-happy [n]
      (reduce + 
        (map #(* % %) (int-to-digits n))))

    (defn happy? [n] 
      (loop [n n seen #{}] 
        (if (contains? seen n)
          (== n 1)
          (recur (next-happy n) (conj seen n)))))

    happy = (n) ->
      sum = 0
      while (sum += Math.pow n%10, 2 ; n = 0|n/10) then
      sum
    
    happyness = (n, s=[]) ->
      (n is 1) or (n not in s) and (happyness (happy n), [ s..., n ])
    
    console.log n for n in [1..100] when happyness n

    function happy(n) {
      for (var sum = 0; n; sum += Math.pow(n%10,2), n = 0|n/10);
      return sum
    }

    function happyness(n, s){
      s || (s=[])
      return n==1 || !~s.indexOf(n) && happyness(happy(n), s.concat(n))
    }

    function h(n,s){for(s=0;n;s+=Math.pow(n%10,2),n=0|n/10);return s}
    function H(n,S){return n==1||!~(S=S||[]).indexOf(n)&&H(h(n),S.concat(n))}

1) Decompose a number into digits. Less experienced candidates will likely convert the number into a string and then the characters back into numbers while more experienced candidates will tend towards a small loop using div and mod.

2) Use some kind of library to insert and test membership in a set data-structure. Less experienced candidates may not be able to do this without stackoverflow, big red flag.

3) Some basic flow control wrapping it all together. Less experienced candidates may fail here similar to fizzbuzz.

The interviewer likely thinks these things are a good proxy for the quality of a candidate. For example, the author would have failed #1 even without miscommunication/stress/time constraints.

So it seems here is a an instance of where life was not fair... in my favor. But now I'm in a position to hire other people. So I don't want to judge them in the same way I was. I want to find out who's got the chops completely apart from who can dance on cue.

(defn digits [num] (let [ x (map str (str num)) s (map read-string x)] (apply + (map #(* % %) s))))

I do think the interviewer should have pointed you in the right direction or offer some sort of hint to gain an understanding of how comfortable you are with the language rather then just having you fumble around but depending on the role they were hiring for these questions and this practice don't seem bad to me

You could also precalculate or cache the answer for 1 through 100 to save rerun time.

But maybe a little bit more math would reveal much better optimizations.

I can write white board code with ease as those are almost always two way conversations

Skype n_goles

    def happy(n: Int) = n.toString.map(_.asDigit).map(Math.pow(_, 2)).sum.toInt

    def find_happiness(n: Int, seen: List[Int]): Boolean = {
        if (happy(n) == 1) true
        else if (seen.contains(happy(n))) false
        else find_happiness(happy(n), seen :+ happy(n))
    }

While interviewing, I tell the candidate the problem and then leave the room. He is alone and comfortable (I hope). I check back after 30 min. If not done I still give him more time.

The cost of screwing up there is small and yet its excellent exercise in coding in front of an audience.

As far as this interview question is "Do you %?", I like it as a test. For the rest, I feel sorry for the author. Good luck next time :)

in the interview i fluked a question about js scope because the whiteboard handwrite of the interviewer made it hard to see which variable was i and which was j... but after he explained why i got wrong and i realized the letter mistake i was too stressed and dumbfounded to make a case, so i just left.

6 mo later, my current employer is still independent while that company is now owned by Microsoft...

Although some function decomposition of the problem would have been nice to see!

The idea is that we switch back and forth. One of us writes a failing test, then the candidate writes the production code. The candidate then writes the next failing test and one of us writes the production code and the next failing test. If the candidate gets stuck, we usually try to talk through the situation and if they are really stuck, one of us will offer to take over.

The candidate is allowed to look things up on the internet and even ask questions. Often we will suggest things. For instance, after the candidate writes some production code, we might say, "That works well. But how about refactoring it using inject," for example.

I often use a pomodoro timer set to 20 minutes. We'll do as much as we can in the first set. After that first set we'll ask the candidate how they think it is going. We'll offer some advice about technique and such. If it was an absolute disaster (happened a couple of times), we'll just leave it there and thank the person for their time. Otherwise we'll ask if they are up for another round. Usually the first set is pretty bad because the person may never have done real TDD before, or may find the ping-pong awkward at first, or may be very nervous. Talking about how they are feeling at the break usually helps and the second set is much, much better.

After the second set we'll ask the candidate how they think they did. I think this is important because if the candidate says, "It went really well" and it was actually awful, then we have a pretty good idea of their skill level. If they say, "I wasn't really happy with my performance, but I enjoyed the style of programming", then we will have to take into consideration a variety of different factors to see if we believe that the person can do better. If the person says, "I really didn't like working that way", then we can rule them out as a candidate regardless of their skill level (also happened a few times unfortunately).

The feedback we've gotten from candidates on the process seems to indicate that they really enjoy this interview style. I think it removes a lot of the spotlight from the person and allows them to relax a bit. Especially having us come in and help out in sticky situations allows the candidate to get over stupid blind spots (like the converting between string and integer in the article). So far, I think it has helped us spot potential in a few people that I'm sure we would have overlooked using a more standard, "Here, solve this problem" approach.

On the downside, there is still considerable room for improvement. Language lawyers (know every detail about the programming language but are still poor programmers) can often look very, very good in this kind of test. Similarly, inexperienced but very talented people can often be frustratingly mediocre because the unfamiliar method of development can hamper their style. You need to be very aware of the amount that the person improves during the interview.

One final comment about this approach. We have occasionally been in a situation where we said, "I'm not sure how good this person is. They seem like their skills are fine, but whether they will be really excellent, I don't know. However, it was really fun programming with them." In those cases we have hired the person and never regretted it.

As I understand it, you are taking the sequence

n -> (sum of the squares of the digits of n)

First, the sequence never diverges to infinity. For example, 9999999999 -> 9*81.

Second, not all numbers converge to 1. There is a stable cycle that does not include one.

Consider

4 -> 16 -> 37 -> 56 -> 61 -> 37 -> ...

So, any positive integer either

1. Converges to 1

2. Converges to the stable cycle I just mentioned above.

So the interviewer should be fired for not understanding the question he was asking.