[ understand your audience ]
Disclaimer: This is taken from my personal experience interviewing candidates. I am by no means an interviewing expert, well-studied as a human lie detector, nor have I ever dedicated an ounce of time or energy into reading a book about the art of the interview. Luckily for you, neither has your interviewer. Most likely, the person sitting across from you (the candidate) is a normal human being of average intelligence who merely wants to see if you’re the type of person they could see themselves working with for an extended period of time without wanting to pull their hair out.
Note: If this is a consulting firm, then they just want to ensure that they can use you to extract the maximum amount of dollars from clients without them growing suspicious. Your actual personality probably doesn’t matter at all.
[ don’t panic ]
That’s easy, right? Don’t sweat profusely and make the interviewer feel weird you big dummy. Just plug your glands and remember to smile, but not too much… oh god, what do you do with your hands? Are you talking too fast? Too slow? This is how humans stand right? I think so.
Seriously, just relax. It’s already a really tense situation for everyone. Just be cool, okay? The interviewer will sense your anxiety, and will respond to it by asking you really easy questions. This might seem good, but really it’s like letting a kid win at basketball to make him feel better about being adopted. You want to prove that you are a smart, confident individual, and looking nervous until you get a few pity questions lobbed your way isn’t going to do anything to help your case.
[ know the bare minimum ]
If I ask you about design patterns, and all you can talk about is Singleton, the interview is fucking over. You should be able to explain language and technology agnostic concepts such as:
- Basic Control Flow
- Object Oriented Design Patterns
- Static vs. Dynamic Typing
There is a lot to know in the world of computer science, and often there is so much that we tend to forget the core topics. Know the basics inside and out so that you and the interviewer are speaking the same language. This is not to be confused with buzz-wording. These are not merely words you say and the interviewer quietly nods approvingly. You’ll be expected to know enough about any of these to talk about them in detail. If you don’t, I suggest you read up on them now and save yourself from getting in to trouble with the next piece of advice.
[ don’t bullshit me ]
There is nothing more repugnant than an interviewee who tries to bluff. It oozes out of them like a lanced boil:
“Oh yeah, polymorphism. It’s been a while, but I can do it. I just don’t remember the specifics. I would just google it. <sheepish grin>”
What was your plan here? Did you think I didn’t know enough about the topic I just asked about to call you on your obvious bullshit? Just own up about your lack of knowledge. The risk of outing yourself as an obvious charlatan far outweighs the minor inconvenience of admitting “I don’t know”. There are plenty of things I don’t know, and when people ask me about them, I try to be honest. Not knowing something doesn’t make you seem incompetent, but being a phony makes you seem like a dickhead who is wasting my time. In my head, the interview is over. I might explain how wrong you are, but there is no real way of clawing your way back from this position, so please, remember what your mommy told you: honesty is the best policy.
[ be smart, or have a plan to get smarter (or both). ]
[ be memorable ]
I see a lot of people, and they are all pretty generic. We all tend to do the same sorts of things in our day-to-day, e.g. making the button say this instead of that, or when the user clicks the thing, do some other thing. It’s boring, and repetitive, and not at all entertaining to hear re-told. Talk to me about something awesome you built, or about that time you brought down production, or the hard-to-find bug that saved your coworker hours and sent him into a fit of face-palming. I probably won’t ask, so just blurt it out. The less likely it is to come up in conversation, the better.
[ show me the code ]
Get yourself a github account and put up something, a pet project, an experiment, a few Project Euler solutions. Something with your name on it that is indicative of your coding style. This is equivalent to your artists’ portfolio, and there is really no reason not to have it available.
[ accept defeat gracefully ]
Sometimes, despite your best efforts, things will not go well. There are lots of reasons for this, but generally, it will mean that you are not the candidate the interviewer was looking for, and you know it. Resist the urge to ask “how did I do?”, it just feels desperate. Instead, ask the interviewer if there were specific areas where you are weak. If he or she has lots to tell you, just accept your fate, and try to turn the experience into something positive. Smile, take notes, and learn the things they mention. Your next interview will be better.
Tune in, well, let’s face it, whenever the hell I decide to get off my ass and post something, for an F-bomb filled tirade about passion.
-smugly yours, Ross