Setting Up Your Interview Toolbox

Posted bykchodorowPosted inProgrammingTags:

This post covers a couple “toolbox” topics that are easy to brush up on before the technical interview.

I recently read a post that drove me nuts, written by someone looking for a job. They said:

I can’t seem to crack the on-site coding interviews… [Interviews are geared towards] those who can suavely implement a linked list code library (inserting, deleting, reversing) as well as a data structure using that linked list (i.e. a stack) on a white board, no syntax errors, compilable, all error paths covered, interfaces cleanly buttoned up. Lather, rinse, repeat for binary search trees and sorting algorithms.

These are a programmer’s multiplication tables! If someone asked me “what’s 6×15?” on an interview, I wouldn’t throw my hands up and complain that I learned it 20 years ago, I’d be fucking thrilled that they had given me such a softball question.

Believe me, if you can’t figure out my basic algorithm questions, you do not want me to ask my “fun” questions.

If you’re looking for a job, I’d recommend accepting that interviewers want to see you know your multiplication tables and spend a few hours cramming if you need to. Make sure you have a basic toolbox set up in your brain, covering a couple basic categories:

  • Data structures: hashes, lists, trees – know how to implement them and common manipulations and searches.
  • Algorithms: sorts, recursion, search – simple algorithm problems. “Algorithms” covers a lot of ground, but at the very least know how to do the basic sorts (merge, quick, selection), recursion, and tree searches. They come up a lot. Also, make sure you know when to apply them (or they won’t be very useful).
  • Bit twiddling – this is mainly for C and C++ positions. I like to see if people know how to manipulate their bits (oh la la). This varies on the company, though, I doubt a Web 2.0 site is going to care that you know your bit shifts backwards and forwards (or, rather, left and right).

If you are applying for a language-specific job, the interviewer will probably ask you about some specifics. A good interviewer shouldn’t try to trap you with obscure language trivia, but make sure you’re familiar with the basics. So, if you’re applying for, say, a Java position, get comfortable with java.lang, java.util, how garbage collection works, basic synchronization, and know that Strings are immutable.

Protip: when I was looking for a job, every single place I interviewed asked me about Java’s public/protected/private keywords. Nearly all of them asked about final, too.

Don’t freak out if you get up to the board and can’t remember whether it’s foo.toString() or (String)foo, or if you forget a semicolon. Any reasonable interviewer knows that it’s hard to program on a whiteboard and doesn’t expect compiler-ready code. On the other hand, if your resume says you’ve been doing C for 10 years and you allocate an array of chars as char *x[], we expect you to laugh and understand your mistake when we point it out (I know I might do something like that out of nerves, so I wouldn’t hold it against you as long as you understood the problem).

Good luck out there. Remember that, if a company brings you in for an interview, they want to hire you. Do everything you can to let them!

12 thoughts on “Setting Up Your Interview Toolbox”

  1. “Remember that, if a company brings you in for an interview, they want to hire you”

    I’m not sure that is the case, they could just be collecting resumes and information about who’s about. Most recruiters won’t actually tell you what is going on or why.

    Like

    Reply

    1. Companies don’t want to waste developers’ time interviewing people they’ll never hire. By the time we get to an in-person interview, we try to be pretty sure about the candidate. Doing an in-person interview is much more time-intensive than doing a phone screen.

      Like

      Reply

      1. Well I’m glad to know you lot take it seriously, not everyone does 🙂

        Though from an interviewees point of view it’s great to experience that, so you can answer the question “Is this the kind of place I want to be” and answer no, before wasting any more time.

        Like

      2. I’ve subsequently found out that this major games company in Burnaby, Vancouver, BC ……. has a “quota” for the number of people it must interview for senior roles ……… so they were wasting just about everyone’s time!

        Like

    2. I’ve had my time wasted by recruiters at recruiting firms, but not companies looking to hire directly. Also, Kristina’s article is about technical interviewing, and I’ve never had a tech question asked of me by a headhunting firm.

      Have you actually had companies (not head hunting firms) interview you, and end up not hiring anyone?

      Like

      Reply

      1. Yes, I’ve experienced that quite recently, it even inspired a blog post about how bad the whole process was from a company in Vancouver.

        http://www.jeremyhutchings.com/2010/12/worst-job-interview-ever-for-software.html

        They were just fishing, though all they did was inspire some more people to reinforce their negative reputation in town. Out of 3 posts, they didn’t hire for 2 I’ve been told.

        I appreciate the point of the original post, and getting asked easy tech questions. Though it was the point about “if they bring you in, they want you”which I know to be wrong. Some places are just sloppy, and think nothing of wasting huge amounts of the employees (and the people they call in) time.

        Like

      2. That sounds miserable. I meant, “If they are a well-run, sane company and they bring you in…” I’m sure some companies just suck at this. I think (hope!) most companies don’t waste everyone’s time like that.

        Like

      4. >> Some places are just sloppy, and think nothing of wasting huge amounts of…

        Yes, this is absolutely true; however, these companies are generally the exception and not the rule. As with anything worth doing, you will put in some significant time doing homework on companies that are worth working for. All this company proved to you is that they don’t belong on your list. Generally if you are brought into a “technical” interview, someone is getting hired and you have a good shot at being one of those people. Most good development companies do not waste their developer’s time interviewing people for positions they don’t plan to fill.

        Like

  2. Strongly disagree. Unless you’re building a database engine (which, granted, you actually are!) the *only* time sort algorithms come up post-university is at job interviews. It’s a waste of everybody’s time. I’d rather test a candidate’s applicable skills than their interview cramming abilities.

    Like

    Reply

    1. I agree that if I were hiring a web developer, I probably would give a very different interview. Other than that, I can’t think of an (interesting) programming job where a strong understanding of these fundamentals wouldn’t be beneficial. Also, “applicable skills” is tricky: any good programmer can go from language to language or framework to framework pretty easily. I had zero experience developing databases when I applied for a job at 10gen.

      Also, I’m actually the “nice” one: many of my coworkers don’t think people should cram for the interview, and that any decent candidate should be able to figure out any of these basic concepts/algorithms on the fly.

      Like

      Reply

Leave a comment