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.”

-vince vaughn, swingers (1996)

ok, i didn’t really need to put that long quote in there, but i’ve been waiting to use it, but i think you get the point.

you are a big boy–or girl. don’t be a f****** baby!

seriously. if you don’t know the answer to the interview question, don’t be all like “you didn’t ask me it right!”

don’t blame your computer science professor for not using deodorant, so you couldn’t pay attention in class.

don’t make excuses like you aren’t feeling well or your mommy forgot to pack your lunch today.

man up, or put on your big girl panties–whatever the case may be. (no judgments.)

take responsibility for your own actions and if you don’t know the answer, simple, say “i don’t know the answer.”

or even better, say “i don’t know the answer but i’ll find out. you s****brain a**hole!”

ah! just seeing if you are still paying attention.

#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.

cracking the coding interview isn’t about being super fast and not giving a crap if you get everything wrong.

it’s about being thoughtful, analytical, careful and accurate. (dammit chrome, analytical is too a word. i’m leaving it. you can put that little squiggly under the word all you want!)

anyway, here is the deal: no one is going to be super impressed if you whip out code super fast, but do it carelessly–even if your code is flawless.

i know it seems super impressive. i know you see presenters at conferences do it–but, let me let you in on a little secret there, they use a macro.

but, the big problem is, it looks careless. it looks like you just don’t care and you are all about showing off instead of writing good code.

i don’t know about you, but i want to work with someone who is deliberate and takes their time to make sure things are right, not some hot-shot code-jockey that slams out code and lets me deal with the bugs.

so, don’t be that guy.

be the guy who takes his time, tests his code and makes sure it works, before he throws it over to the interviewer and says he’s done.

be that guy. i like that guy.

#11 practice mock interviews and take notes

again, another basic, duh, thing that seems so obvious, yet so many programmers fail to do.

your code is abysmal

before going into a coding interview, practice being interviewed. you can even set up real interviews, but i like to have interviews with my imaginary friends or long-dead historical figures.

one time abraham lincoln told me to write an algorithm to reverse all the words in a string while singing the national anthem.

benjamin franklin often extols the role that virtues play in the proper naming of variables when i mock interview with him.

in all seriousness though, go out and practice some mock interviews with your friends or your family. get comfortable answering the questions an interviewer is likely to ask you.

and, when you do go to an actual interview, regardless of the outcome, take notes afterward, when the interview is still fresh in your mind.

i constantly hear developers whining about how they keep getting rejected, interview after interview.

well, guess what they say when i ask them if they did any mock interviews?

no.

and, when i ask about taking notes, so they’ll know what they need to work on next time and improve?

nada.

do you know what whining without doing anything about your problem is?

it’s annoying!

stop it!

#12 ask questions

alright, we’ve reached the end.

i’m tired of writing, you are tired of reading what i am writing, but i’ve got one more point and then you can load blast this blog post all over your twitter feed, submit it to hacker news and buy my book.

my last tip, is one that isn’t so obvious, because a coding interview doesn’t really feel like a real work environment, but once you make the connection, i’m sure you’ll see how important it is.

let me give you a bit of an example that will illustrate what i’m about to tell you.

suppose you are at your job gathering some requirements from a customer about what you are supposed to build. let’s pretend like they are sane and you’re sane. we’re all sane in this example. (even though we know this is far from the truth in real life.)

anyway, do you ask the customer one question about what you are supposed to build and then go off to your desk to code it up?

smacks your hand with a ruler

no! no, you don’t.

what you do is, you ask a bunch of questions.

how tall do you want the box?

what is supposed to happen when the customer enters their name?

do we need just the last name and the first name or do we need the middle name and their grandma’s name as well?

what color underwear are you wearing?

you ask a lot of questions. you drill deeper to find out more information.

so, why don’t you do that in an interview.

don’t just start coding the solution to a problem. even if you think you understand it.

ask the interviewer some questions to confirm.

the point isn’t to run off and code the right answer, the point is to simulate how you’d behave in a real-world environment.

just like naming things, if you don’t ask clarifying questions about your assignment in a coding interview, the interviewer is likely to assume that you wouldn’t ask questions in a real-world situation either.

so, take your time, ask questions–make sure you understand what kind of code you are supposed to write, before you write it.

#bonus: want to avoid a lot of this and get the job anyway?

look, here’s the deal. all of this is useful for cracking the coding interview.

i sincerely hope it helps you, but i’d be doing you a big disservice if i gave you all these tips, slapped you on the back and said, “good luck kid.” i’ll tell you why.

the reason is because while cracking the coding interview can be an important part of landing your dream job, it’s not the only component, nor is it the most important.

in fact–and you are going to find this hard to believe–you can sometimes… sometimes… avoid the coding interview completely if you have a good grasp of the kind of soft skills that can let you slip in the back door.

many times in my career i was offered a job, not because i was a crackerjack coder ( that means good, i looked it up ), but rather because i had figured out ways to build connections with interviewers at the company ahead of time and had built up a reputation online that allowed me to sometimes even bypass the interview completely.

anyway, i wrote a book called “soft skills: the software developer’s life manual,” that is full of all kinds of advice on how to improve your career, get a better job, become more productive and even improve your health and finances. and it’s all written specifically for software engineers, programmers, software developers, whatever you want to call yourself.

if you liked this blog post– if you found it funny or at all entertaining, i’m pretty sure you’ll enjoy my book.

so, go check it out.

seriously, do it.

look, it’s way better than cracking the coding interview, (sorry gayle), just check out the reviews on amazon.

ok, that’s all i have to say…

peace!