Cracking the coding interview

Cracking the Coding Interview is the result of my first-hand experience interviewing at top companies. It is the result of hundreds of conversations with candidates. It is the result of the thousands of candidate- and interviewer- contributed questions. And it’s the result of seeing so many interview questions from so many firms. Enclosed in this book are 150 of the best interview questions, selected from thousands of potential problems.

And plus:

Five proven approaches to solving touch algoritm questions.
Ten mistakes candidates make – and how to avoid them.
Steps to prepare for behavioral and technical questions.
Interviewer war stories: a view from the interviewer’s side.

Navigation:

Foreword

For those of you new to technical interviews, the process can seem overwhelming. Interviewers throw questions at you, expect you to whip up brilliant algorithms on the spot, and then ask you to write beautiful code on a whiteboard. Luckily, everyone else is in the same boat, and you’re already working hard to prepare. Good job!

As you get ready for your interviews, consider these suggestions:

Write Code on Paper: Most interviewers won’t give you a computer and will instead expect you to write code on a whiteboard or on paper. To simulate this environment, try answering interview problems by writing code on paper first, and then typing them into a computer as-is. Whiteboard / paper coding is a special skill, which can be mastered with constant practice.
Know Your Resume: While technical skills are extremely important, that’s no reason to neglect your own resume. Make sure to prepare yourself to give a quick summary of any project or job you were involved with, and to discuss the hardest and most interesting problems you encountered along the day.
Don’t Memorize Solutions: While this book offers a representative sample of interview questions, there are still thousands of interview questions out there. Memorizing solu- tions is not a great use of your time. Rather, use this book to explore approaches to problems, to learn new concepts, and to practice your skills.
Talk Out Loud: Interviewers want to understand how you think and approach problems, so talk out loud while you’re solving problems. Let the interviewer see how you’re tackling the problem, and they just might guide you as well.

And remember – interviews are hard! In my years of interviewing at Google, I saw some interviewers ask “easy” questions while others ask harder questions. But you know what? Getting the easy questions doesn’t make it any easier to get the offer. Receiving an offer is not about solving questions flawlessly (very few candidates do!), but rather, it is about answering questions better than other candidates. So don’t stress out when you get a tricky question - everyone else probably thought it was hard too!

Something’s Wrong

Like many motivated candidates, he had prepared extensively. He had read K&R’s classic C book and he’d reviewed CLRS’s famous algorithms textbook. He could describe in detail the myriad of ways of balancing a tree, and he could do things in C that no sane programmer should ever want to do.

I had to tell him the unfortunate truth: those books aren’t enough. Academic books prepare you for fancy research, but they’re not going to help you much in an interview. Why? I’ll give you a hint: your interviewers haven’t seen Red-Black Trees since they were in school either. To crack the coding interview, you need to prepare with real interview questions. You must practice on real problems, and learn their patterns.

Before the Interviewers

For many candidates, interviewing is a bit of a black box. You walk in, you get pounded with questions from a variety of interviewers, and then somehow or other you return with an offer or not.

Have you ever wondered:

How do decisions get made?
Do your interviewers talk to each other?
What does the company really care about?

Well, wonder no more!

CareerCup sought out interviewing experts from five top companies - Microsoft, Google, Amazon, Yahoo and Apple - to show you what really happens “behind the scenes ”. These experts will walk us through a typical interview day and describe what’s taking place outside of the interviewing room, and what happens after you leave.

Our interviewing experts also told us what’s different about their interview process. From bar raisers (Amazon) to Hiring Committees (Google), each company has its own quirks. Knowing these idiosyncrasies will help you to react better to a super-tough interviewer, or to avoid being intimidated when two interviewers show up at the door (Apple!).

In addition, our specialists offered insight as to what their company stresses in their inter- views. While almost all software firms care about coding and algorithms, some companies focus more than others on specific aspects of the interview. Whether this is because of the company’s technology or its history, now you’ll know what and how to prepare.

So, join us as we take you behind the scenes at Microsoft, Google, Amazon, Yahoo and Apple.

Microsoft

Microsoft wants smart people. Geeks. People who are passionate about technology. You probably won’t be tested on the ins and outs of C++ APIs, but you will be expected to write code on the board.

Definitely Prepare: “Why do you want to work for Microsoft?” In this question, Microsoft wants to see that you’re passionate about technology. A great answer might be, “I’ve been using Microsoft software as long as I can re- member, and I’m really impressed at how Microsoft manages to create a product that is universally excellent. For example, I’ve been using Visual Studio recently to learn game programming, and it’s APIs are excellent.” Note how this shows a passion for technology!

What’s Unique: You’ll only reach the hiring manager if you’ve done well, but if you do, that’s a great sign!

Amazon

Amazon’s “bar raiser” interviewer is charged with keeping the interview bar high. They attend special training and will interview candidates outside their group in order to balance out the group itself. If one interview seems significantly harder and different, that’s most likely the bar raiser. This person has both significant experience with interviews and veto power in the hiring decision. You will meet with your recruiter at the end of the day.

Definitely Prepare: Amazon is a web-based company, and that means they care about scale. Make sure you prepare for questions in “Large Scale.” You don’t need a background in distributed systems to answer these questions. See our recommendations in the System Design and Memory Limits Chapter. Additionally, Amazon tends to ask a lot of questions about object oriented design. Check out the Object Oriented Design chapter for sample questions and suggestions.

What’s Unique: The Bar Raiser, who is brought in from a different team to keep the bar high.

Google

There are many scary stories floating around about Google interviews, but it’s mostly just that: stories. The interview is not terribly different from Microsoft’s or Amazon’s. However, because Google HR can be a little disorganized, we recommend being proactive in com- munication.

Definitely Prepare: As a web-based company, Google cares about how to design a scalable system.So, make sure you prepare for questions from “System Design and Memory Limits”. Additionally, many Google interviewers will ask questions involving Bit Ma- nipulation, so please brush up on these questions.

What’s Different: Your interviewers do not make the hiring decision. Rather, they enter feedback which is passed to a hiring committee. The hiring committee recommends a decision which can be—though rarely is—rejected by Google executives.

Apple

Much like the company itself, Apple’s interview process has minimal beaucracy. The interviewers will be looking for excellent technical skills, but a passion for the position and company is also very important. While it’s not a prerequisite to be a Mac user, you should at least be familiar with the system.

Definitely Prepare: If you know what team you’re interviewing with, make sure you read up on that product. What do you like about it? What would you improve? Offering specific recommendations can show your passion for the job.

What’s Unique: Apple does 2-on-1 interviews often, but don’t get stressed out about them - it’s the same as a 1-on-1 interview! Also, Apple employees are huge Apple fans. You should show this same passion in your interview.

Yahoo

While Yahoo tends to only recruit at the top 10 – 20 schools, other candidates can still get interviewed through Yahoo’s job board (or – better yet – if they can get an internal referral). If you’re one of the lucky ones selected, your interview process will start off with a phone screen. Your phone screen will be with a senior employee (tech lead, manager, etc)

Definitely Prepare: Yahoo, almost as a rule, asks questions about system design, so make sure you prepare for that. They want to know that you can not only write code, but that you can design software. Don’t worry if you don’t have a background in this - you can still reason your way through it!

What’s Unique: Your phone interview will likely be per- formed by someone with more influence, such as a hiring manager. Yahoo is also unusual in that it often gives a decision (if you’re hired) on the same day. Your interviewers will discuss your performance while you meet with a final interviewer.

Interview War Stories

Pop Divas Need Not Apply

However, once we started talking to him, things went south in a hurry. He spent most of the interview criticizing every tool and platform that we questioned him on. We used SQL Server as our database? Puhleease. We were planning to switch to Oracle soon, right? What’s that? Our team used Tool A to do all our coding in? Unacceptable. He used Tool B, and only Tool B, and after he was hired, we’d all have to switch to Tool B. And we’d have to switch to Java, because he really wanted to work with Java, despite the fact that 75 percent of the codebase would have to be rewritten We’d thank him later. And oh, by the way, he wouldn’t be making any meetings before ten o’clock.

Needless to say, we encouraged Leonard to seek opportunities elsewhere. It wasn’t that his ideas were bad – in fact, he was “technically” right about many things, and his (strong) opin- ions were all backed with solid fact and sound reason (except for the ten o’clock thing – we think he may have just been making a “power play” ). But it was obvious that, if hired, Leonard wasn’t going to play well with others – he would have been toxic kryptonite for team chem- istry. He actually managed to offend two of the team members during the forty-five minutes of his interview. Leonard also made the mistake of assuming that Code Purity and Algorithm Beauty were always more important than a business deadline.

In the real world, there are always compromises to be made, and knowing how to work with the business analysts is just as important as knowing how to refactor a blob of code. If Leonard would not have gotten along with other IT people, he definitely wouldn’t have gotten along with the business folks. Maybe you can get away with hiring a Leonard if he’s one of the best ten coders in the world (he wasn’t). But he was the classic failure example for the “Would you have a beer with this guy?” test.

Failure to Communicate

Trisha was a mid-level Java developer with a solid history of middleware and JSP work on her resume. Since she was local, we invited her in for an interview without a phone screen. When we started asking her questions, it quickly became obvious that Trisha was a woman of few words. Her answers were short and often composed of “yes/no” responses, even to questions that were meant to start a dialog. Once she did start opening up, I still wasn’t sure she was actually talking. I saw her lips moving, and heard mumbling sounds coming out, but it wasn’t anything that sounded like English.

I’m not sure if Trisha was nervous or just shy, but either way, I had to ask her numerous times to repeat herself. Now I was the one getting nervous! I didn’t want to be the guy who “ruined” the interview, so I pulled back on my questions. The other folks in the room and I exchanged uneasy glances. We felt like we were on a Seinfeld episode. It was almost impossible to under- stand Trisha, and when she did speak up, her halting, uncertain, confused speech patterns made us feel more like code breakers than interviewers. I am not exaggerating to say that I did not understand a single answer she gave during the interview.

Knowing, alone, isn’t good enough. You’re going to be talking with other technical people, and you’re going to be talking to customers, and sales reps, and Betty from Marketing. You will write something eventually, whether it’s documentation, or a project plan, or a require- ments document. The word processor might correct your spelling, but it won’t correct your lousy writing. The ability to communicate thoughts and ideas, in a clear, concise manner, is an absolutely invaluable skill that employers seek.

You Can(Maybe) Count On Me

Ian was a cheerful, friendly guy who had a gift of natural charisma. He got along fantasti- cally with all of the interviewers, and seemed very intelligent Skill-wise, he was adequate He hadn’t written a single line of computer code outside of his college courses, and didn’t even have his own e-mail address. When we gave Ian the chance to ask us questions at the end of the interview, he asked about flexible work hours, and how soon he could take vacation time. Instead of showing an interest in the career opportunities, or in company’s growth prospects, he asked whether he could take the all-you-could-drink break room soda home with him. The questions grew more bizarre from there.

In any other year, that should have been it for Ian right there. But, in 1999, we were hiring anybody who was even remotely competent. Ian collected paychecks from us for eighteen months, and he was about as productive as a traffic cone. He usually sauntered into the office around ten-thirty with some sort of lame excuse (by my count, he had to wait for the cable guy sixteen times in a six-month period). He usually killed the morning by answering e-mail and playing ping-pong, before breaking for a two-hour lunch. After lunch, it was more ping- pong, and maybe an hour of writing bad code, before bolting the office sometime around three. He was the dictionary definition of unreliable.

Remember, your potential future team members need to know that they can rely on you. And they need to know that you won’t need constant supervision and hand-holding. They need to know that you’re able to figure things out on your own. One of the most important messages that you, as a candidate, can convey in your interview is hiring me will make your lives easier. In fact, this is a large part of the reason for the famously difficult interview questions at places like Amazon and Google; if you can handle that kind of unpredictable pressure in an interview, then you stand a good chance of being useful to them on real projects.

Spider Sences

I can think of lots of interviews that just fell into the general category of weird and uncomfortable:

The Java coder who apparently considered hygiene optional, and had the interview room smelling like week-old blue cheese within ten minutes (my eyes were watering).
The young fresh-out-of-college graduate with a tongue piercing that kept tick-tick-tick- ing against his teeth as he talked (after half an hour, it was like Chinese water torture).
The girl who wore an iPod through her interview, with the volume turned loud enough that she actually had to ask the interviewers to repeat themselves a few times.
The poor, hyper-nervous fellow who was sweating like a marathon runner for half an hour.
The girl who wore a T-shirt with an obscene political slogan to her interview.
The guy who asked (seriously) at the end of his interview, “So, are there any hot chicks in our department?”.

Those are the interviews where we politely thank the people for their time, shake their hand (except for the sweaty guy), then turn to each other after the door closes and ask – did that really just happen?

Nobody is saying that you have to be a bland, boring robot in a Brooks Brothers suit and tie. Remember, the interview team wants you to be “the one”, but they’re also very worried about the possibility that you’re going to be more of a distraction than an asset. Don’t talk or behave in a way that will set off their early warning radar. Whether or not somebody bothers to behave professionally during an interview is often a very good indicator of what kind of teammate they’re going to be.

Rudimentary social skills are part of the answer to “Would I have a beer with this guy?”, or at least, “Will I mind working next to this guy for six months?”. From the interviewer’s point of view, they’re picking a neighbor that they’re going to live and work with 200 hours per month for foreseeable future. Would you really want a neighbor that smelled like a hog ren- dering plant?

Reference

blog comments powered by Disqus

Published

16 September 2013

Github

Rendered

Raw