Five Less Mushy Technical Interview Tips

First, a disclaimer: I am in no way any kind of an expert on interviewing. I'm writing this because I'm completing my senior year of undergraduate engineering school and I've watched myself, my friends, and my peers go through the internship/new hire interview process for lots of companies with vastly different results. I'm simply interested in making note of what seems to work, and what doesn't seem to work, specifically within the scope of programming students applying for actual real world programming jobs.

This post has nothing to do with me other than the fact that my experiences are one of the data points. In fact, this could probably more accurately titled Things I Wish Someone Had Sat Me Down and Told Me Four Years Ago.

Before we begin, let's assume that you've already heard the standard job interview advice: be yourself, dress up, make eye contact, ask them questions, etc. I'm not proposing that we throw out any of the age-old wisdom of folks in university career services offices. Rather, I'd simply like to offer up a few addenda:

1. Don't be Yourself

Yeah, yeah, I know I just said I'm not contradicting old advice, but trust me, I'm not. Hear me out on this one.

When an advisor says to "be yourself" in an interview setting, it makes it sound like you ought to be the person you are every day in engineering school. There's just one problem: that person is basically a schizophrenic shut-in with sarcasm tourettes. No offense; we're all like that. The only problem is that nobody wants to hire Jimmy Weirdo, no matter how good of a programmer he is.

So how do we fix it? Pretend to be someone totally different? Nope. Try this: take a couple of minutes and think about what you're going to be like in 5 years. You'll still be you, but you'll also be a mid-twenties professional developer. That's the guy this company wants to hire, and that's the guy you need to start acting like.

Now, let's be clear. I'm not saying that you need to act like you've already hit your midlife crisis to get people to like you. Rather, I'm saying that it's profoundly uncommon for a company to meet a programming student who is demonstrating that he is ready and willing to grow up.

So how do we do this? Here's my running list:

Get a haircut. A good one. Shave. Zero hair coming out of your neck. Buy some stylish business casual clothes. I know, I'm horrible at this too. Get a girl (not your mom, or your aunt) to help you. Practice wearing those clothes. Learn to tie a tie loose enough that your eyes don't bug out when you sit down (you know exactly what I'm talking about). Adults are comfortable in clothes.

And most of all, just act like an adult. I'll cover it more in a second, but seriously, just think about how you're probably going to act in a few years when you don't have Mountain Dew dripping off your teeth and try to emulate that.

2. Know Your Stuff

If there's one thing that will get you not hired, no matter how good of a programmer you think you are, it's not knowing the fundamentals. Whether you call yourself a PHP developer, an embedded systems programmer, or a system administrator, if you're showing up to a technical interview for a developer position, you absolutely will be asked the fundamental questions. It's incredible how many smart kids blow these. I'll admit that I've been one of them.

So what do you need to know? Well, that probably depends on what you're applying for, but I do have a running list of things that you should bring with you to a technical interview:

Polymorphism. If you aren't able to basically recite what polymorphism is, don't bother showing up. Memory layout. Seriously. If you don't know the difference between the stack and the heap, you might be about to look pretty stupid. Access modifiers. Specifically public , private , etc., as well as static , and sometimes more language-specific modifiers like abstract and virtual . Even if you don't use a language that uses them, know what they mean. Data structures. Know these inside and out. Literally. Know how they work, the efficiency of the operations on them, and what they're useful for. Start with this list:

Lists . Array-based and linked. Know the difference.

. Array-based and linked. Know the difference. Stacks

Queues

Hash Tables (the answer to 80% of programming questions)

Binary Search Trees (likely used as a set, which you should also know) I've also used Tries and Heaps from time to time in interviews, so those are great to know as well.

Sorting. Know Merge Sort, Quicksort, and the difference. It also may be useful to know a few of the less efficient but more common ones (Bubble Sort, Selection Sort, Insertion Sort, etc.) so you can quickly identify them in existing code. Searching. Know how to search the various data structures that you have in your utility belt, but also know something about solution finding (searching states in a problem). Specifically things like pathfinding in a maze, collecting rewards, solving sliding puzzles, etc. Know the difference between bredth-first and depth-first search, and be able to implement them quickly. If you're applying for a very technical job, you're probably going to need to know more. Optimizations and efficiency. If I had a nickel for every time I heard, "Okay, but how can we make it faster?" Know how to pick a faster data structure, be able to speak intelligently about your decisions. Also know a thing or two about memoization. Database structure. One kind of question that really seems to sneak up on students is the dreaded design question, usually worded something like, "So, take a few minutes and describe how you'd design eBay." Well, take some time and think about it. It basically comes down to being able to design good Domain Models, ER Models , and knowing a thing or two about database normalization. Design patterns. Ever heard of the Gang of Four? If not, time to put on your reading hat and learn something. If there's one thing that can really make you seem like a professional in interviews, I beleive that this is it. If you're unfamiliar, start here. Also make sure you're familiar with MVC. Other interview questions. Go hunting for classic technical interview questions. There are scores of them online, ranging from brain teasers to full blown implementation problems. Get good at thinking on your feet and solving these in 10-20 minutues or so.

There are tons more, but that should really get you started and prepare you for 80%+ of interview questions (and honestly probably make you immediately more qualified than half of your peers). In case you're still interested, a few that I left out are development methodologies, testing strategies, and dynamic programming.

CAVEAT: Although I've really tried to stress the importance of having a strong foundational knowledge going into your interview, one critical thing to remember is that under no circumstances should you pretend to know something you don't. You're only digging your own grave at that point. Unfamiliar with a term or concept? Just say so. You may be surprised the good conversation that comes out of it, and it may be the difference between you solving a problem and you looking like an idiot.

3. Don't be an Ass

This one. I'm pretty convinced that this is the number one reason smart people don't get good jobs. This is also one of the hardest things to do, because when it comes down to it, you have no idea that you're being an ass. I sure didn't.

Fundamentally, it's a matter of respect. If you can't respect the people who are interviewing you, you're unhirable. There are a lot of ways you can be incredibly disrespectful without even knowing it, so let's look at a few cases.

First, let's get one thing straight: you're not doing the company a favor. If anything, you are blessed that your inherent social awkwardness drove you into a field that happened to explode with jobs during your lifetime. Remember what you're doing: you're asking someone to consider you qualified enough to sign over large sums of money to you twice a month in return for time and effort spent in an office. That's not a favor.

"Yeah, but I'll make them so much more than they'll pay me." Yeah, that's the idea, and it's called being a business. Don't flatter yourself into thinking you're some kind of anomaly.

"Yeah, but I'm a rockstar programmer! Nobody in the whole class can sling code like me!" That may be. And that should make you the number one pick for the position, right? Wrong. The only person who can probably see that you're a great programmer is the developer conducting the interview, but he's not so much interested in money-making potential like HR is. He's hiring a team member who he may have to work with for the next 10 years. He can teach a mediocre developer the ways of the company, but he can't make you less unbearable.

Here's another one of my favorites: an interviewer is giving you the rundown of the company's software architecture, and he mentions a specific piece of technology/framework/library/whatever that you used at one time but don't anymore. You, being the extremely experienced developer, instantly say, "Ew!" and smirk like you're better than someone. Come on. First of all, you have no idea what sort of design and architecture decisions went into selecting this particular piece of technology, and your largest code base to date probably hasn't crossed 1000 lines of code, so you wouldn't even be qualified to speak on it if you did know the reasoning behind it.

I don't want to rant too much, but I do want to make this clear: I've seen more opportunity lost due to self-entitlement than I have due to lack of qualifications. If you walk in acting like you own the place, you'll come up short every time.

4. Be Interesting

Okay, let's take a break for a second. If you can master the previous three points, you're in the top slice, and you'll get job offers. No questions asked. From what I've seen, there are just a couple more things that really set you apart in the extremely competitive positions, so I think it's good to cover those as well.

One of the most important things you can do to win the really desirable positions is to be different from your competition. It seems obvious, but it's something that's largely lacking from those entering the professional world.

Now, I don't mean different like "I only wear sandals, because I don't believe in shoes." That's obnoxious. I mean different in that you've followed your personal technical passions, relevant to the position or not, and done something on your own without anybody telling you to. Did you make a website? Sweet. An app? Very sweet. Anything at all (sigh, yes, even a game) that you've done on your own really shows a ton about the kind of person you, and it gives you plenty to talk about in your interview.

Another easy way to be interesting is to read. Read Hacker News. Read /r/programming. Read Slashdot. Read something. One of the most satisfying feelings is being knee-deep in an interview with a company that uses all sorts of technologies you've never heard of and having your interviewer mention something you've read an article about. Being able to contribute that little information (as long as it's not some sensationalist blog article) sometimes completely changes the dynamic of the interview for the better.

Sometimes even more important than reading things is trying things. Take any opportunity you get to try out a new tool, framework, or language. Even if you never do anything useful with it, you just added something to your interview tool belt, and you might even be able to answer questions about it.

One way or another, it's important for you to be different from your peers. It seems that more and more employers are hiring batches of students from the same colleges, so being the one guy whose resume doesn't look exactly like his transcript is probably the biggest favor you can do yourself. Heck, it's about the only point in this post that's any fun, so why not?

EDIT: A great piece of advice from Kenny Gao:

I think it's worth adding that a big part of Being Interesting (or more generally, being memorable) is being knowledgeable about the company that you're interviewing with. I'm always surprised at the positive reaction that I get from interviewers when I ask them about something that's unique to their company that they're passionate about, and it makes for a great entry point into a meaningful discussion.

5. Be Charming

This final point is probably the hardest one to advise on, but it seems to really make a difference when it comes down to it. You probably know the situation all too well: someone who's half as qualified as you but is just so damn likeable that nobody can say no to him gets an offer before you. It's not sneaky or deceitful; it's just the honest nature of people: they hire who they like.

If you're one of these lucky folks, congratulations; you're already probably basking in a wonderful life. As for the rest of us, let's do our best to emulate some of this charming behavior.

Why? Well, if there's one thing you learn from interviewing, it's that there will always come a time when the ship is sinking. It's these times when the only thing you've got left to save you is a grin, a little joke, and as much charm as you can muster up. It's not that the charming guys among us don't make mistakes; it's just that their mistakes seem so insignificant since we like them so much.

I really don't have any great advice for how to be more charming. It's something I don't think I ever really got a good hold of. If you can find some way to channel your inner Sinatra though, you've got the world by the tail.

Well, that about wraps things up. Again, this is in no way a definitive list of interview tips. Rather, it's just a collection of things that get said a lot but never officially written down. If it helps even one person get a job, it'll be entirely worth the time it took to jot it down.

Cheers,