coding interview

Behavioral questions are asked for a variety of reasons. They can be asked to get to know your personality, to understand your resume more deeply, or just to ease you into an interview. Either way, these questions are important and can be prepared for. How to Prepare Behavioral questions are usually of the form "Tell me about a time when you...," and may require an example from a specific project or position. I recommend filling in the following "preparation grid"as shown below: Common Questions Most Challenging What You Learned Most Interesting Hardest Bug Enjoyed Most Conflicts with Teammates Project 1 Project 2 Project 3 Project 4

Along the top, as columns, you should list all the major aspects of your resume, including each project, job, or activity. Along the side, as rows, you should list the common questions: what you enjoyed most, what you enjoyed least, what you considered most challenging, what you learned, what the hardest bug was, and so on. In each cell, put the corresponding story. In your interview, when you're asked about a project, you'll be able to come up with an appropriate story effortlessly. Study this grid before your interview. I recommend reducing each story to just a couple of keywords that you can write in each cell. This will make the grid easier to study and remember. If you're doing a phone interview, you should have this grid out in front of you. When each story has just a couple of keywords to trigger your memory, it will be much easier to give a fluid response than if you're trying to re-read a paragraph. It may also be useful to extend this grid to"softer"questions, such as conflicts on a team, failures, or times you had to persuade someone. Questions like these are very common outside of strictly software engineer roles, such as dev lead, PM or even testing role. If you are applying for one of these positions, I would recommend making a second grid covering these softer areas. When answering these questions, you're not just trying to find a story that matches their question. You're telling them about yourself. Think deeply about what each story communicates about you

I am not a recruiter. I am a software engineer. And as such, I know what it's like to be asked to whip up brilliant algorithms on the spot, and then write flawless code on a whiteboard. I know because I've been asked to do the same thing—in interviews at Google, Microsoft, Apple, and Amazon, among other companies. I also know because I've been on the other side of the table, asking candidates to do this. I've combed through stacks of resumes to find the engineers who I thought might be able to actually pass these interviews. And I've debated in Google's Hiring Committee whether or not a candidate did well enough to merit an offer. I understand and have experienced the full hiring circle. And you, reader, are probably preparing for an interview, perhaps tomorrow, next week, or next year. You likely have or are working towards a Computer Science or related degree. I am not here to re-teach you the basics of what a binary search tree is, or how to traverse a linked list. You already know such things, and if not, there are plenty of other resources to learn them. I am here to help you take your understanding of Computer Science fundamentals to the next level, to learn how to apply those fundamentals to crack the coding interview.

The 5th edition of Cracking the Coding Interview updates the 4th edition with over 200 pages of additional questions, revised solutions, new chapter introductions, and other content. Be sure to check out our website, www.careercup.com, to connect with other candidates and discover new resources. I'm excited for you and for the skills you are going to develop.Thorough preparation will give you a wide range of technical and communication skills. It will be well-worth it no matter where the effort takes you! I encourage you to read these introductory chapters carefully. They contain important insight that just might make the difference between a "hire"and a "no hire." 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.

We walked out of the hiring meeting frustrated, again. Of the ten "passable" candidates we reviewed that day, none would receive offers. Were we being too harsh, we wondered? I, in particular, was disappointed. We had rejected one of my candidates. A former student. One who I had referred. He had a 3.73 GPA from the University of Washington, one of the best computer science schools in the world, and had done extensive work on open source projects. He was energetic. He was creative. He worked hard. He was sharp. He was a true geek in all the best ways. But, I had to agree with the rest of the committee: the data wasn't there. Even if my emphatic recommendation would sway them to reconsider, he would surely get rejected in the later stages of the hiring process. There were just too many red flags.

Though the interviewers generally believed that he was quite intelligent, he had struggled to solve the interview problems. Most successful candidates could fly through the first question, which was a twist on a well-known problem, but he had trouble developing an algorithm. When he came up with one, he failed to consider solutions that optimized for other scenarios. Finally, when he began coding, he flew through the code with an initial solution, but it was riddled with mistakes that he then failed to catch. Though he wasn't the worst candidate we'd seen by any measure, he was far from meeting "the bar." Rejected. When he asked for feedback over the phone a couple of weeks later, I struggled with what to tell him. Be smarter? No, I knew he was brilliant. Be a better coder? No, his skills were on-par with some of the best I'd seen. Like many motivated candidates, he had prepared extensively. He had read K&R's classic C book and he'd reviewed CLRS' 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. 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 questions contributed by candidates and interviewers. 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.

Most companies conduct their interviews in very similar ways. We will offer an overview of how companies interview and what they're looking for. This information should guide your interview preparation and your reactions during and after the interview. Once you are selected for an interview, you usually go through a screening interview. This is typically conducted over the phone. College candidates who attend top schools may have these interviews in-person. Don't let the name fool you; the "screening" interview often involves coding and algorithms questions, and the bar can be just as high as it is for in-person interviews. If you're unsure whether or not the interview will be technical, ask your recruiting coordinator what position your interviewer holds. An engineer will usually perform a technical interview. Many companies have taken advantage of online synchronized document editors, but others will expect you to write code on paper and read it back over the phone. Some interviewers may even give you "homework" to solve after you hang up the phone or just ask you to email them the code you wrote.

You typically do one or two screening interviewers before being brought on-site. In an on-site interview round, you usually have 4 to 6 in-person interviews. One of these will be over lunch.The lunch interview is usually not technical, and the interviewer may not even submit feedback. This is a good person to discuss your interests with and to ask about the company culture. Your other interviews will be mostly technical and will involve a combination of coding and algorithm questions. You should also expect some questions about your resume. Afterwards, the interviewers meet to discuss your performance and/or submit written feedback. At most companies, your recruiter should respond to you within a week with an update on your status. If you have waited more than a week, you should follow up with your recruiter. If your recruiter does not respond, this does nof mean that you are rejected (at least not at any major tech company, and almost any other company). Let me repeat that again: not responding indicates nothing about your status. The intention is that all recruiters should tell candidates once a final decision is made. Delays can and do happen. Follow up with your recruiter if you expect a delay, but be respectful when you do. Recruiters are just like you. They get busy and forgetful too.