Cracking The Coding Interview: 12 Things You Need To Know

Cracking the coding interview is the holy grail of many programmers and software developers, but is cracking the coding interview really possible?

Nothing, I mean nothing, terrifies more software engineers than the dreaded coding interview.

Sure, Gayle McDowell, wrote an excellent book that is actually called “Cracking the Coding Interview,” but is it actually possible?

Yes, but I don’t think memorizing a bunch of programming questions is all you need to do to be successful at cracking the coding interview.

Here are 12 things you need to know if you really want to stand a chance at cracking the coding interview:

#1 How to code algorithms (really cracking the coding interview)

It’s a coding interview–duh. If you want a chance at cracking the coding interview, you have to be able to code.

I’m often surprised how many software engineers don’t realize this simple detail.

Now, writing regular day-to-day code is a bit different than writing the kind of code to implement the coding interview problems you are likely to get–which mostly consist of algorithms.

You may get questions like: Write an algorithm to find an element in a linked list and move that element to the end of the list.

Or you might get a question that basically asks the same thing, but disguises it in a clever word problem involving robots on an assembly line. Regardless, you need to know how to program algorithms.

But, are you born knowing how to program algorithms?

Perhaps you were, but I wasn’t. Instead, I had to practice.

Sure, you may have learned a little bit about data structures and how to implement different kinds of algorithms in college–and you may even remember a little bit of it–but, you probably didn’t do a whole lot of practice at writing bubble sort algorithms or searching binary trees.

But, I wouldn’t give you a problem and get you all nervous without giving you a solution, would I?

No, I wouldn’t. Well, I might, but I wouldn’t be that obvious about it.

Anyway, here are some good resources to practice coding algorithms.

• Top Coder – I wrote a blog post about how to use Top Coder to practice programming problems. (It’s an older post of mine, so cut me some slack.)
• Programming Pearls (2nd Edition) – Classic book by Jon Bentley. (I even remembered his name without having to look it up.) Chock-full of hard problems that you have to write code to solve. Great practice and a lot of fun. I’m serious. If you don’t like solving these problems, what are you doing being a programmer.
• Cracking the Coding Interview: 150 Programming Questions and Solutions – Even though Gayle’s book is beating out mine on Amazon, I still have to recommend it, because it really is good and does have a lot of good problems to practice and learn from. But, make sure you don’t just memorize those problems. Work them out on your own, so you can get good at doing it. Yes, I’m talking to you!
• My Pluralsight Course, Preparing For a Job Interview – See, I didn’t even put my course first. In this course, I basically walk you through solving a few of these algorithm problems and do something that I haven’t seen anywhere else: I give you an actual process for how to learn how to solve these types of problems yourself. I also cover a bunch of other job interview tips and questions.
• Project Euler – If I don’t include this one, I’ll get a bunch of emails from people whining about how I didn’t include project Euler. So, there, here it is. (That is an awkward sentence.) Anyway, this is actually a really good resource. Plus, there are lots of examples of how all kinds of people solved these problems in all kinds of wacky ways, doing all kinds of psychedelic drugs.

Ok, enough about that one. I’ve got, like, 11 more to cover.

Just make sure you get to the point where you feel comfortable writing some code to sort an array containing the color of hair on a cat into three lists in order of hair length, or something like that.

#2 Write code WITHOUT tools

Yes, Visual Studio with Resharper basically makes you a demi-god.

Yes, I know you Java people, that IntelliJ and Eclipse do the same things without any plugins.

Yes, I know that you Node people do it all without an IDE and can do it all with just your Sublime Text. (Oh, and about 50 plugins that essentially make it an IDE, but we won’t talk about that. Shhhh.)

Anyway, IDEs and bare-bone-text-editors-with-50-million-plugins, are extremely powerful, but when you walk into a coding interview, you might just get handed a piece of chalk.

(So, that means you Linux guys and gals with your VM and Emacs will need to take heed as well.)

I’m not suggesting that you write your everyday production code on a chalkboard. But, you might want to at least practice sketching out some code by hand without auto-complete or typing some code into notepad if you really want to be cracking the coding interview. Do you feel me?

#3 Have a portfolio

You know what proves you can code more than anything else?

Code.

Yes, I know. It seems like far too easy of an answer.

But, if I am wondering if you can write code and I see your code–or something you built with code–that kinda proves it for me.

Yup, this guy either randomly hit keys on his keyboard until an app magically popped out, or he can code.

So, it only makes sense that someone who has hopes of cracking the coding interview would have a portfolio full of code and applications they built using code to show any prospective interviewer.

What? What’s that you say? How do you get a portfolio?

I’m glad you asked. Here are two easy ways:

1. Build mobile apps and have the source code ready to show. I always harp on the idea that new developers, especially, should take advantage of how easy it is to build a complete mobile application all by themselves. Seriously, go learn Android or iOS, and build at least one or two simple mobile applications that you can show off. It’s nice to be able to point to some app you built that is in an app store and then show them the code you wrote to make it.
2. Get GitHubbing. GitHub is a wonderful place where you can put open-source code you are working on for the world to see. You can also contribute to open-source projects, which will give an excellent example of the kind of code you write and prove that you can work on a large-scale application. GitHub is an excellent portfolio for any coder.

You can also build web apps or VB6 apps to showcase your talents, but I’m going to stick with my top two choices. (Mmm… VB6. Now that is how you really get to cracking the coding interview. Throw down some printed out VB6 code on their desk and shout “wa-bam son!”)

#4 Think out loud

Interviewers are not mind-readers. They don’t know what you are thinking when you are scratching your head trying to figure out how to insert a new node into a linked list.

Sure, you might not get the interview question right, but you can at least let the interviewer know you are on the right track or that you aren’t completely stupid, by thinking out loud while you are trying to solve the problem.

Trust me, I’ve been on the other end of the interview table enough times to know that there is nothing worse than someone frantically sweating, soaking through their shirt, while crushing the whiteboard marker in their hand and frantically erasing things in complete silence.

It’s awkward. It makes me uncomfortable. It makes you uncomfortable. It makes the little duck I have sitting in my office that I tell all my problems to uncomfortable (and he’s got a high tolerance for this shit.)

So, just talk. When you are trying to solve a problem, talk through it.

You do get bonus points for thinking about a problem the right way and showing your problem solving skills–even if you don’t get the answer right.

#5 Don’t argue, blame or make excuses

I really shouldn’t have to say this one… but, sadly I do.

Seriously, as Vince Vaughn would say:

“Our little baby’s all grows up. You know what? … Our little baby’s all grows up. … I’m not even hungry, I couldn’t touch it. … Our little boy is all grows up tonight. You know what big boy? You’re grown up. You’re grown up! Yeaaaheyha! Dig that! Is this a f*****’ production for ya? Cuz you’re growns up and you’re growns up and you’re growns up! I’m the asshole in the bar place is that right? I’m the asshole? I’m outta here. I’m not eatin’ anything. I wouldn’t eat here, I would never eat here anyway.”

#6 Don’t give up

I’m so tempted to drop another Vince Vaughn quote on you right now, but I am going to resist the urge and just tell you to not throw in the towel too early.

Really, at the first sign of trouble, don’t just throw your hands up in the air and give up.

Try a little. Try a little more. Make them tear you from the blackboard kicking and screaming while you swear that all you need to do is just swap this one variable and your algorithm will work. (Ok, don’t do that, but I think you get my point.)

F*** it, you’re getting Vince Vaughn after all:

Trent: You know what you are? You’re like a big bear with claws and with fangs…
Sue: …big f****ing teeth, man.
Trent: Yeah… big f****in’ teeth on ya’. And she’s just like this little bunny, who’s just kinda cowering in the corner.
Sue: Shivering.
Trent: Yeah, man just kinda… you know, you got these claws and you’re staring at these claws and your thinking to yourself, and with these claws you’re thinking, “How am I supposed to kill this bunny, how am I supposed to kill this bunny?”
Sue: And you’re poking at it, you’re poking at it…
Trent: Yeah, you’re not hurting it. You’re just kinda gently batting the bunny around, you know what I mean? And the bunny’s scared Mike, the bunny’s scared of you, shivering.
Sue: And you got these f****ing claws and these fangs…
Trent: And you got these f****ing claws and these fangs, man! And you’re looking at your claws and you’re looking at your fangs. And you’re thinking to yourself, you don’t know what to do, man. “I don’t know how to kill the bunny.” With this you don’t know how to kill the bunny, do you know what I mean?
Sue: You’re like a big bear, man.
Mike: So you’re not just like f****ing with me?
Trent: No I’m not f****ing with you.
Sue: Honestly, man.

Ok, so it wasn’t even completely relevant, but just pretend like it was, ok?

Anyway, an interviewer will respect you a lot more if you try hard. No one wants a coworker that whines about how hard something is and gives up and browses Facebook all day. You have claws, use them. (See, what I did there?)

#7 Test your code

AW YEAH! MY CODE IS OFF THE HOOK. I DON’T NEED TO TEST IT.

Yes, I know your code is perfect the second you write it.

Yes, I know that angels sing and the clouds part when you place the last curly brace on the algorithm you implemented.

But, you gotta make it look like you at least gave it some effort.

You don’t want your interviewer to reject you simply because you would create a completely unobtainable standard by which all mere mortal programmers would be judged, once you joined the company.

So, pretend like your code might be capable of having errors and test through it before you tell the interviewer that you are done.

Really, I can’t believe how many software engineers, who would normally test every line of code they write, completely forget to do this in an interview or think it’s not important.

Write a unit test to test it if you can, but if you can’t, at least paper test it. (That means walk through the code with possible inputs, line-by-line.)

#8 Name things clearly

Another thing that seems to go out the window during the coding interview.

If you want a chance at cracking the coding interview, you need to come up with better names than “banana.”

YOU SHOULD NEVER NAME YOUR VARIABLES AFTER FRUIT…

Yes, someone I worked with–I won’t name names–once named all the variables in their C++ application after names of fruits.

It was exactly as amusing as it sounds.

If you are in a coding interview and you write code with one-letter variable names–like I so often see in coding interviews–the interviewer is going to assume that is how you normally write the code that you put into production in real-world applications.

I know that you really name your variables wonderfully.

You know you do.

But, guess what? The interviewer doesn’t.

It takes you like 2 extra seconds to think of and write out a clear and meaningful variable name, so do it.

I’m serious. Do not make me pull out another irreverent Vince Vaughn quote. I’ve already got Wedding Crashers loaded up on IMDB.com and I am ready to go.

#9 Ask for feedback

You write perfect code. We’ve already established that.

Your variable names are perfect and make angels cry. You don’t have to try and convince me, I know it.

But, even with all that perfection floating around, it doesn’t hurt to ask the interviewer their opinion on your code and your solution to the problem.

Yes, I know they are going to say some irrelevant bull-crap, but remember what I said about making them feel important? You know that unobtainable standard of perfection that you don’t want to project?

Ask them for feedback. Especially if you don’t know the answer to a problem and they’ve timed you out.

Show that you are interested in learning and that you don’t just want to get the answer right, but you want to understand it.

I guarantee it won’t make you look stupid.

#10 Don’t rush

It's not a race

#11 Practice mock interviews and take notes

#12 Ask questions