Cracking the Coding Interview Summary - iamonur.com

Hey everyone, time to time, we all have a pressure on us to find a new job. Job market means interviews. If you’re in coding business, interviews mean coding interviews. And these can go right and wrong. What you can do to achieve more is to prepare them better. Gayle Laakmann McDowell’s book Cracking the Coding Interview may change the tides for you.

However, we programmers are not well known for reading books. So, I’ve read Cracking the Coding Interview for you and prepared a very brief summary with side notes only. It is the non-technical introduction part of the book only for now. By time, I will release other chapters with answers to the interview questions at the end of chapters. Enjoy, and good luck in the job market!

You can get the book here. Check for more of my content in my homepage.

INTRODUCTION

Chapter – 1: The Interview Process

This is the first chapter of the introduction part of Cracking the Coding Interview. The chapter is about how the interview process goes generally.

The interviewer is here for only to evaluateyour ability to solve algorithmic problems that you haven’t seen before.
Oftenly, these interviews take 45 minutes per question.
You need to talk out loud your tought process and accept any help coming from your interviewer when need be.
A numeric evaluation will be done, but these numbers all depend to your interviewer’s gut feeling.
You will be assesssed for: Analytical skills, coding skills, technical knowledge, experience, and communication skills.

False Negatives are Acceptable

False negatives are acceptable by the company. They want a great developer. As long as they got one, the ones they’ve missed is not important to them.

Basic Data Structure and Algorithm Knowledge

Understanding trees, graphs, lists, sorting, etc. is helpful on these interviews. Also, they come up while working, too.
Of course you may learn as you see them, but knowing them at the start and by the heart improves your productivity.
The skills you need to have for passing a coding interviews are not that hard. However, they still are what it takes to be a better programmer.
Also, it is hard to ask a programming question that does not involve data structures or algorithms.

Whiteboard Interviews

In most of whiteboard interviews, you will not be asked to compile, develop whole class definitions… You will need to focus on the interesting parts.
However, don’t just write a pseudocode, try to implement syntax as much as possible.
These interviews are not that scary, by standing up, you will be enabled to speak more and explain your thought process.

How Questions are Selected

Questions mostly depend on the interviewer. Most companies don’t have a pool of questions to ask.
Some companies focus on algorithms, some focus on pure knowledge. However, there is no such thing as a “Google interview question”.

It’s All Relative

Interviewers assess you relative to other applicants that gets the same question.
Your interviewer tries to develop a feeling for your performance with respect to other ones.
It’s not the candidates this week, it’s not the candidates for this positions, it’s the whole interviews this guy get in before you.

I didn’t hear back, am I rejected?

Probably not. Most of the decent companies let you know if you’re rejected. You may want to check politely after a week if you don’t hear back.

Can I re-apply?

Mostly. Typically, you need to wait for 6-12 months, though.

Chapter – 2: Behind the Scenes

This chapter of Cracking the Coding Interview is about how an interview goes with a few examples.

Most interviews are alike. This chapter is about how your recruitment may happen.
Once you’re selected, you usually go through a “Screening” interview, which will probably be on phone. Top school or highly experienced candidates may be exempted from this.
Screening also can be technical. If you’re not sure if your screening will be technical or not, you may check title of your interviewer. If s/he is an engineer, probably some level of technicality is involved.
You may be asked to use online editors, or to read your code from phone. You also may be given a homework at this level.
Typically you will go through one or two screening interviews before an on-site interview.
In an on-site interview, you will need to perform 3 to 6 interviews. One of them will be at lunch time. Lunch interview is probably not technical and not for evaluating you.
You will probably hear from the company after a week after an on-site interview, but delays may happen.

The Microsoft Interview

MS wants smart people that are passionate about technology.
You’ll need to show up in the morning to fill out some papers. After, there will be a preparation interview to warm you up.
You’ll get 4 or 5 interviews, probably with two different teams. You’ll do your interviews in your interviewers’ offices, not a conference room. This is a great opportunity to get a grasp of your future team’s working environment.
After interviews, you may be asked to meet with a hiring manager. That’s great, because it means you did well in at least one interview.
If it takes more than a week to hear back from MS, politely e-mail the HR.

Prepare to: “Why do you want to work for Microsoft?”They want to see if you’re passionate about their technology. Talk about your experience about their products, and how they are universally excellent.
The Unique Thing: If you’re asked to talk with a hiring manager, you most probably get an “OK to hire” from at least one team.

The Amazon Interview

Adventure of Amazon interview starts with a phone screening with a specific team. You can be asked for more screenings. This means either you underperformed expectations, or you’re being considered for multiple teams.
Usually, during the screenings, they ask you to write a simple code from a shared editor.
After a successful screening, they will invite you to an on-site interview. There will be 4 or 5 interviews with 1 or 2 different teams. Most of the interviews includes a whiteboard, your results from independent interviews do not affect others.
There will be a “bar raiser” interviewer. These guys do interviews that are not for their own teams to balance things out, they have special training and also a “veto right”. Please do remember that you don’t need to ace this interview, just overperforming your competition is enough.
After they submitted their feedback about you, your interviewers take a meeting about you to discuss.

Prepare to: Scalability questions. You don’t need to have a distributed systems background, but just work on it.Also, object oriented design.
The unique thing: Bar raiser. You need to impress both this guy, and at least a team.

The Google Interview

A Google engineer will perform your first phone screen. Expect tough questions. It is known that their screen questions and on-site questions are alike.
After, you will get four to six on-site interviews. One of them will be on the lunch. All interviews go independent and your lunch interviewer does not submit feedback. You may ask your tough question to this guy.
Interviewers submit their feedbacks to a hiring committee to make a decision. These feedbacks include fields like analytical ability, coding, experience and communication.
To make an offer, HC wants at least one great score on your interviews.
You don’t need to perform perfect on all your interviews, and the screen matters near none at the end.
Since lots of committees etc. are involved, your offer may delay a while.

Prepare to: Questions about system design and scalability.Regardless of your experience, prepare to the algorithm questions.
The Unique Thing: Your interviewers only submit feedback, they do not make any decisions.

The Apple Interview

Their processes include minimal bureaucracy. They are looking for candidates that have both technical skills and passion for the position.
If not owning one, familiarity to Mac systems needed.
They start with a basic screen, follow with more technical screens.
If you got invited to on-site, your interviewer will greet and inform you about the process. You will have 6-8 interviews with both the team you’re considered in and that team’s business connections.
Some interviews are one on one, but there will be two on ones. There exist whiteboard interviews. At lunch time, you will get interviewed by your future manager.
Before the day ends, interviewers compare notes in a meeting. If you’re still considered as a viable candidate, you will have an interview with the director and the vice president. If you have this interview, you probably got it.

Prepare to: Read the product you will be working on. Offer improvements in the interviews if possible.
The Unique Thing: Almost all Apple employee is an Apple fan. Being one may help you.

The Facebook Interview

You will be asked for one or two phone screens. Screens will be technical and involve coding.
After, you will get a homework. Pay attention to best practices while doing it. Ask for someone to review your code before submission.
At the on-site, each of your interviewer has a specific role. Those are:
- Jedi: Behavioral evaluation. You will be checked if you are a cultural fit. These may also include coding.
- Ninja: Coding and algorithms evaluation. Pretty standard things.
- Pirate: Designing and architecture evaluation. Could include a design of a hypotethical system. Be sure to openly discuss your design decisions and trade-offs.
Typically expect 2 Ninja interviews, and a Jedi. If you’re experienced, also expect at least one Pirate.

Prepare to: Showing entrepreneurial spirirt. Show that you can make things work fast, than improve.Hack together an elegant and scalable solution using any language of choice. For example, Facebook uses PHP, C++, Erlang and Python for their back-end.
The Unique Thing: In Facebook, hirings are made for the whole company, not a specific team. After they hire you, you will go to a six week bootcamp. After, you will get mentorship from senior developers and may choose your own project to work on.

Chapter – 3: Special Situations

This chapter of Cracking the Coding Interview is for you if you’re not a simple programmer or developer only.

Experienced Candidates

Experienced candidates get less algorithm questions. But not zero.
It is considered that you may be out of practice of the knowledge from school. Informing your interviewer that you are out of practice is acceptable.
However, it is also considered that you know better since you are in the field for more years. You are expected to give more complex and accurate answers than a newbie.
The interviewers also go hard on you about system design and architecture.

Testers, and Software Development Engineers in Tests(SDETs)

Prepare yourself for core testing problems.
However, also work on your coding skills.
Career Advice: SDET positions seems like an “easy way in”, but it is hard to change your job title. So, consider twice.

Product Managers

Your skills will be tested on:
- Handling ambiguities: You shouldn’t get overwhelmed.
- Customer Focus(Both in attitude and technicality): Both putting yourself in customer’s shoes and strong technical understanding of product.
- Multi-Level Communication: “Explain TCP/IP to your grandmother.”
- Passion for tech: Companies seek excitement on PMs.
- Teamwork/Leadership: Questions about your past experiences and hypotethical situations.

Developer Leads and Managers

You are expected to ace coding interviews. Also you will be judged on:
- Teamwork/Leadership: Same as PMs.
- Prioritization: Maybe a hypotethical question about a deadline.
- Communication: Same as PMs.
- “Getting things done”: Balancing technology and business.

Startups

Application: There may be a job posting, but mostly a personal refferal is better.
Visa and Work Permit: Typical startup will not sponsor you.
Resume: List not only your technical skills, but also entrepreneurial skills.
Interview Process: They will probably look for a personal fit, skillset and experience.

Acquisitions and Acquihires

Why? Because acquisitions should not be an easy way in to the company.
Importance? These can break acquisitions, or whether you will continue in your position or not.
Who? Probably all of the engineers will go on with this process.

Chapter – 4: Before the Interview

This chapter of Cracking the Coding Interview is for getting ready to interview before it.

Get the Right Experience

You need a great resume before everything. The great resume should include great experiences.

For Students:

Take classes with big projects. Relevant and big projects will look better on your resume.
Try to get an early internship, this will result better internships later, and a better job.
Try to start something. Build your own projects or participate in hackathons.

For Professionals:

Shift your work responsibilites to coding. Try to get “meatier” projects to put on your resume.
Use your nights and weekends to build something just for the fun of it.

Writing a Great Resume

Length: If you don’t have lots of experience, like 10+ years, don’t submit a resume longer than a page. Recruiters usually have nearly 10 seconds per resume.
Employment History: Your resume shouldn’t have all your positions, just put relevant or important ones. You should put your past employments as “Accomplished X by implementing Y, which led to Z.”
Projects: Also, do not add all here. Most important 2-4 ones should be the best.
Programming Languages and Softwares:
- Softwares: Don’t put something insignificant like MS Word. It is not bad to know it, but it takes valuable space.
- PLs: Try to keep your list short. If you want to have a long list, at least put your level of knowledge near them.
Typos: Typos get resumes shredded. So if you’re not a native to language, request a friend to proofread your resume.

Beware of Stigma

Enterprise languages: Putting VB.NET on your resume will look bad since you will be considered as a “Microsoft stack developer”.
Being too language focused: Being a software developer is nice, being a “Javascript Developer” is not nice.
Certifications: Beware of them, some certificates look bad and you may be misunderstood as a poser.
Knowing too few languages: This also looks bad, since it looks like you have a problem with learning new things.

Preparation Map

1+ Years:

Build projects
Learn PLs
Expand your network
Build a portfolio website
Students should find internships
Professionals should focus on meaty projects

3-12 Months:

Continue to work on your projects. Add a recent one.
Create a draft resume and review it.
Make a target list of companies.
Read this book.
Learn and Master Big O.
Implement Data structures and algorithms from scratch.
Form a mock interview group from friends.

1-3 Months:

Do mini projects to solidify key concepts
Do mock interviews
Continue practicing interview questions
List and track your mistakes

4 Weeks:

Create an interview prep grid.
Review and update your resume
Begin applying
Re-read the book
Do a mock interview
Continue to practice, writing code on paper.

1 Week:

Locate headset and camera for screen.
Last mock interview
Rehearse stories from the interview prep grid.
Re-read Algorithm Approaches.
Re-read Big O.
Continue practicing.

Day Before:

Rehearse all stories from interview prep grid.
Work on your mistakes.
Review Powers of 2 table. Print it for your screen.

Day Of:

Wake up early to have a breakfast, be on time.
Be confident.
Talk out loud. Show your process.
Struggling is always normal.

After:

Write a thank you note to the recruiter.
Check in after week.
Ask when you can re-apply if rejected.

Chapter – 5: Behavioral Questions

Cracking the Coding Interview ‘s chapter 5 is for how to answer the behavioral questions in a right way while still being believable.

Interview Preparation Grid

	Project 1	Project 2	..	Project N
Challanges
Mistakes
Enjoyed
Leadership
Conflicts
What you’d do differently

What are your weaknesses?

Be prepared and do not answer with a cocky or pretentious sentence. Include how you’re coping with your weakness?
Ex: “I don’t have a very good attention to detail, so I make sure to always have someone double check my work.”

What questions should you ask the interviewer?

Genuine questions: Questions you wanted to be answered.
- What is the ratio of testers to developers around here?
Insightful Questions: Questions to demonstrate your knowledge.
- I noticed you are using X, how are you handling Y?
Passion Questions: Questions to demonstrate your passion.
- I’m very interested in scalability. What opportunities you have here for me?

Know your technical projects

The project you’ll brought should have real challanges.
You should have played a centrol role in it.
You should be comfortable talking about it’s technical sides.

Responding to behavioral questions

Be specific, but not arrogant. You should sound impressive without surrounding arrogant.
Limit details. Give a rough definition first, then make your point briefly.
Focus on yourself, not your team: Your impact on the project is more important than the project itself.
Give structured answers:
- Nugger First: First, tell the main grasp, than move on with details.
- SAR: Situation – Action – Response

Think what your answer means

Your answer’s main point could be initiative/leadership, empathy, compassion, humility, or teamwork.

Tell me about yourself

Answer should be structured:
- Current role: I’m a X at Y, doing Z.
- College: My background is on X, graduated on Y.
- Post college & onwards: After college, I did X, at Y, worked on Z. I learned T on it.
- Current role: Then X happened and I started on Y as a Z. I’m a part of T team, working on Q.
- Outside of work: I’m participating in hackathons, moderating at X forum, doing a side project on Y.
- Wrap up: Then I was looking to X, then your company caught my eye. You’re doing X, and I want to be a part of it.
Your hobbies:
- If your hobby is unique, it is worth discussing.
- It is technical, it is worth discussing.
- If it demonstrates a positive personality attitude, it is worth discussing.

Chapter – 6: Big O

This chapter of Cracking the Coding Interview is for mastering the Big O notation, which is in the heart of software development.

Mastering the big O is an absolute must for a programming position.

Time Complexity

This is what the concept of asymptotic runtime, or big O time, means.
Most common ones are: O(1), O(n), O(logN), O(N logN), O(N^2), and O(2 ^ N).
Big-O: Upper bound on time.
Big-Omega: Lower bound on time.
Big-Theta: If the algorithm both bound upper and lower at the same function, this is “the bound”.

Best Case, Worst Case and Expected Case

Let’s say you’re analyzing QuickSort. QuickSort is about:
- Check if done
- Choose a pivot
- Put smaller elements before pivot, and largers after pivot
- Repeat until done.
Best case: All elements are equal or sorted. O(1)
Worst case: You always choose the largest or smallest element and cannot divide array. O(N^2)
Expected case: O(N*logN)

Space complexity

Not only time, but the memory is consumed by an algorithm.

Drop the constants

O(2N) = O(N)

Drop the non-dominant terms

O(N^2 + N logN) = O(N^2)

logN runtimes

These happen when an algorithm constantly divides the complexity space to work on, like a binary tree search.

Recursive runtimes

Consider a fibonacci function that calls itself two times. The Big O is O(2^N), space complexity is O(N).

Chapter – 7: Technical Questions

This chapter of Cracking the Coding Interview is for how to get better on technical questions in coding interviews.

How to prepare?

For any problem:
- Try to solve: Even if it looks tough, trying to solve it also will grant you some points.
- Code on paper: You are not able to debug and you don’t have the syntax highlighting.
- Test your code on paper: Run your code line-by-line on your mind to debug it.
- Type your paper code as-is: This will allow you to see both your syntax mistakes, and logic mistakes.

What you need to know?

Core Data Structures: Linked lists, trees, graphs, stacks, queues, heaps, vectors(a.k.a. array lists), and hash tables at least.
Algorithms: Know your tree and graph traversals, searches, and sorts at least.
Concepts: Bit manipulation, stack memory versus heap memory, recursion, dynamic programming, big O notation, Operating Systems, etc.. (The more the better.)

Problem solving flowchart

Listen: Pay attention to the problem you’re given. Get the details well, since those can be your edge cases or cut corners.
Example Cases: Think your program as a black box and check what it should be outputting to specific inputs.
Brute Force: Get a solution as soon as possible, with a naive and flawed algorithm.
Test: Test your code conceptually, check for hot spots, generate yourself a minimal test suite, check for special cases and edge cases…
1. If you find bugs at this point, fix and run yout suite again to check if you broke something while fixing a bug.
Optimize:
1. Check for bottlenecks for performance, unnecessary or duplicated code.
2. Check if there is a bit of information that you do not cover from the question.
3. Make a time versus space trade-off if needed. (Example: Use a hash table if your code seems slow.)
Walkthrough: Check if your optimized algorithm still works perfectly after your last changes.
Implement: Write your code as beautiful and modular as possible.

Optimizing

There are different approaches about it.

BUD:
1. Bottlenecks: Check if a part of your algorithm slows the whole runtime.
2. Unnecessary work: Sometimes algorithms tend to check or fix things that are not needed to be. You need to check if you can delete lines from your algorithm.
3. Duplicated work: Maybe you are re-sorting a sorted array? Keep an eye out for skipping as much as work possible.
DIY: Try to solve the problem with pen&paper only, without implementation of a book algorithm. People have that instinct to develop an algorithm without knowing it.
Simplify & Generalize: Tweak some constraints in the problem to make it easier, maybe change a data type. Solve the problem. Then change your solution to solve the actual target situation.
Base Case and Build: Choose a base case, solve that case. Then check for cases that are not covered with your solution, moving to a general solution. Just beware, this approach have the tendancy to build recursive solutions.
Data Structure Brainstorm: Think of different data structures, and the appliances of them to your problem. This will give you plenty of hints to move on with the solution.

Best Concievable Runtime(BCR)

If you think there exist a BCR solution, use it to improve your solution. Sometimes it is impossible to reach that BCR, still trying is enough.

Incorrect Answers

The tought process and search for optimality counts more than achieving the perfect answer. Other than the easy-peasy questions, the evaluation is not binary.

If You’ve Heard a Question Before

Admit it and ask for another question. You’ll get extra honesty points and also it is hard to fake a thought process on a question that you know the answer for.

The Language of Choice

It should be well known
It should be readable
Beware of the potential issues of the language(Ex: If you’ve chosen C++, beware of the memory management.)
Ease of use(Ex: In Python, it is possible to return multiple values from a function.)

Good Coding

Good code should be:
- Correct
- Efficient
- Simple
- Readable
- Mainatainable
Use data structures generously.
Write modular code.
Use asserts or if statements to check correctness of your input.