Overview

Don’t get stuck in the coding interview. The book Cracking the Coding Interview is a popular resource that assists in preparing for the technical interview process. As a senior engineer, I have observed that like many aspects of the industry we are constantly iterating and improving including interviewing. The big companies all provide materials to ensure that the interviewee is prepared for this process technically. But the following steps help you structure your thought process for the interview.

The following steps are outlined in the book to use during the interview.

1. Listen & Clarify

Why? Demonstrates to the interviewer that you understand the problem. Ensure the problem is well defined.

Pay very close attention to any info in the problem description. You need it all for an optimal algorithm.

• Listen to the specifics of the interviewers question

• Ask clarifying questions and state assumptions

• Communicate back your understanding of the problem

• Document these assumptions

• What Design Would You Do At Work

2. Example

Why? Developing an example that covers important bounds conditions and cases helps you formulate a deeper undeerstanding of the problem.

Common Mistake Most examples are too small or are special cases. Debug your example Is there are anyway it’s a special case? Is it big enough?

• Develop the example to help you understand the constraints of the problem

• Spend time to debug your example

• Look for solution options (eg. Think how you would solve this problem real-world, what techniques can be used such as hashing, mathematical, grouping)

3. Brute Force

Why? The brute force solution shows that you undersand a non-optimal solution to the problem.

Get a brute-force solution as soon as possible. Don’t focus on efficiency initally. State that it is a simple solution and state the runtime complexity. Don’t code it unless your interviewer asks you too.

• State the first solution that might be naive and slow. eg Compare all elements of two arrays, etc..

4. Optimize

Why? The brute force solution is often workable for small data sets but not workable in real world applications

Walk through a brute force with BUD optimization or try some of these ideas

Bottlenecks Unnecessary work Duplicated work

• Look for any unused information. You usually need all the information in a problem
• Solve it manually on an example and then reverse engineer the process. How did you solve it?
• Solve it “incorrectly” and think about why the algorithm fails. Can you fix those issues?
• Make a time vs space tradeoff. Hashtables are especially useful.

5 Approaches Now What? If you are stuck the following approaches can be used to break down the problem and define a solution.

• BUD
• DIY: Do it Yourself
• Simplify & Generalize: Solve a simpler version of the problem
• Base Case & Build: Solve from the base cases and build from there
• Data Structure Brainstorm: eg. Arrays, LinkedList, HashMap, Tree, Trie, etc..

5. Walkthrough

Why? Demonstrates to the interviewer your algorithm works and helps you find potential bugs and or missed cases.

Now that you have an optimal solution, walk through your approach in detail. Make sure you undersatnd each detail before you start coding.

• Walkthrough you solution and explain as you go
• Think about required data structures, edge cases, etc..

6. Implement

Why? Interviewer needs to see how you code and your thought process.

Your goal is to write beautiful code Modularize your code from the beginning and refactor to clean up anything that is not beautiful.

7. Test

Why? Demonstrates that you know what a good test case for this problem looks like. Bounds conditions, error cases, etc..

Test in this order

1. Conceptual test. Walk through your code like you would for detailed code review.
2. Unusual or nonstandard code
3. Hot spots, like arithmetic and null nodes. Array size, bounds condiions
4. Small test case. It’s much faster than a big test case and just as effective. Also take less time to demonstrate
5. Special case and edge cases.

And when you find bugs, fix them carefully!

Resources

Cracking the Coding Interview