Interesting...

Having just finished reading this article: http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-for-me-on.html by Tony Arcieri I wanted to make a few comments about coding interviews.

I’ve had several coding interviews in the past everywhere from Amazon to Zynga. Unfortunately several companies/government agencies have NDAs and don’t want you talking about their interviewing habits.

I’ve nevertheless picked up on some best practices on the employers side (I’m still not sure what the best practices for the prospective employee are) and thought someone/somewhere might benefit from my insights.

1. Under no circumstances should you treat the person being interviewed like cattle. You want to make a good impression on the candidate. 
   
   At Amazon I had three interviews in one day. The first went wonderfully the interviewer was respectful, introduced himself, had read my resume and asked pointed questions. He also looked at my schedule (which I was not provided with) and had the decency to warn me that my next interviewer was a little tough.
   
   The second was worse than miserable. The interviewer walked in, sat down, and started asking questions. He had not read my resume and expected me to write perfect code on a whiteboard in C++ when no experience with it was listed on my resume. He belittled my responses by immediately saying “absolutely the wrong way, that’s just stupid” before I had even finished writing a line of code… keep in mind, I don’t ever use C++ professionally… The worst part is that the way I personally code (i.e. plan, stub out, pseudo code, real code) is apparently completely antithetical to his desire to immediately produce code without writing anything else on the board. He stood up and left without saying goodbye or letting me know what was going to happen next. I didn’t even know if I had another interview. 
   
   The third interviewer came in and asked a few polite questions. We went through the first few questions quickly in my native Python and on the last question I discovered a particularly elegant solution that he claimed wouldn’t work. I thought this must be a trick but nevertheless I carefully reviewed my code and made sure everything was working. The interviewer then got angry at me for insisting that the code was fine. I asked him to point out the error and I realized that what he thought was an error was an optimization I’d made. Not every value needed to be looked at to solve the problem as he described it to me but he insisted it was necessary, though he couldn’t tell me how to correct it or why it was necessary. I still don’t know to this day who was right.
   
   After two weeks I got an email saying I was accepted for a position which I did NOT interview for and I wrote Amazon off my list of companies I might want to work for… the entire system was impersonal and incompetent. Don’t be Amazon.
    
2. As a programmer interviewing another programmer you should try to work on problems you’ve solved on the job. See how the candidate’s thought process works. Is it useful? Did they approach it differently? What are the pros and cons of that approach? Make sure you’re not mired in the “my way or the highway” approach. A diversity of ideas is infinitely more useful than one super-coder no matter what some blog tells you.
   
   When I was lucky enough to interview at 10gen one of the interviewers was kind enough to ask me some questions about how they managed replica sets and what the best way to design and code that system might be. We didn’t write much code and spent the entire time animatedly discussing the problem and it’s various solutions. This interview went almost 20 minutes overtime because we were having too much fun talking about it. This is after my first interview was 40 minutes overtime because we were once again obviously enjoying ourselves working on some interesting problems. I almost missed lunch!
    
3. Make a schedule, stick to it, make the candidate aware of it. Don’t go overtime.
   
   I once had the misfortune to interview at MITRE where I was orally told my schedule of interviews several times but never actually given a copy of it. With 8 interviews that day remembering who exactly I was talking to and where their office was supposed to be was kind of difficult.
   
   Another problem with MITRE was that they had no idea if I could actually code or not.
    
4. Give the candidate a chance to code. I mean on a computer and not on a whiteboard. Hopefully, on their computer. Look at their workflow. Pair program even. This will let you see how efficient they are.
    
5. Have the candidate triage/talk about/explore a recent bug report (solved or unsolved). This was a really cool interviewing trick that I had not seen anyone do until REDACTED offered me an interview. I really enjoyed this aspect of the interview because the interviewer sat next to me helping me out whenever I was obviously stumbling around the bug tracker or the source code of the project. The interviewer was extremely familiar with the section of code we were working on and was able to quickly guide me to the write section and I wrote and submitted a patch that we both agreed on all in about 50 minutes. I’ve never felt more fulfilled during an interview. Unfortunately the rest of the interviews at the company didn’t go very well for me (I botched some basic stuff!) and I did not receive an offer.
    
6. Have your employees offer their company email to the candidate and encourage the candidate to submit cool ideas/bug reports directly to the individual. Yelp used this trick and I’ve since submitted ideas/bug reports and gotten fairly immediate replies.
    
7. Stay on topic! It’s okay to be a little tangential but don’t spend 30 minutes discussing the dorms at the college you both attended.
    
8. Have the interviewers explain their role at the company, not what the company does.
   
   Especially if a candidate has multiple interviews in one day, you should make sure the first interviewer explains what the company does and maybe another interviewer after lunch will give his or her take on what the company does… but do not under any circumstances have every single person in the company explain the exact same keyword happy slogan *cough* MITRE *cough*.
    
9. Try a few non-programming challenges but don’t grade the candidate on them and make sure to reveal the solution if it seems like it’s taking too long.
   
   A lot of people say that brain teaser questions are bad. While I don’t think they’re particularly useful they’re not outright counterproductive. Feel free to ask a few but don’t leave me dangling for 30 minutes making no progress.
   
   Yippit was actually really good at this. I had mostly coding interviews throughout the day and my final interviewer of the day popped in and asked if I was tired of coding. I said I wasn’t all that tired but was open to anything so she gave me this really cool brain teaser-esque problem that we laughed and solved over the next 10 minutes or so. I found developing a rapport was easier with the brain teaser than with coding problems and I’m not entirely sure why this was the case.
    
10. If you accept a candidate but they turn down you offer make sure you find out why!
    
    Yippit did a great job again when it came to this. The day after I turned down their offer they asked if they could schedule a phone call. I was amenable thinking they were going to up the offer but in fact they just had me on speakerphone explaining to the whole team why I turned down the offer. They didn’t try to aquiesce or apologize or up the offer. The entire focus of the phone call was summed up by the first question they asked me “What could we have done better?”

All in all I’ve had a great time interviewing at a lot of companies over the years and I’ve learned a lot while doing it. Hopefully someone will find these tips useful. I’m sure I could have presented them a little better but I’m not the best writer in the world.