Cracking The Coding Interview reading notes 1

At the Interview | Handling Behavioral Questions

Structure Answers Using Situation (Scenario) - Action - Result

Ex: in operating system project a guy struggled and discuss few in emails, then the actor communicated with him and that guy performed better.

General Advice for Technical Questions

Interviews are supposed to be difficult. If you don't get every -or any-answer immediately, that's ok! According to author's experience, 10 of 120 people finished right instantly.

So when you get a hard question, don't panic. Just start talking aloud about how you would solve it.

You're not done until the interviewer says that you're done!

Five Steps to a Technical Question


1. Ask your interviewer questions to resolve ambiguity.
2. Design an algorithm.
3. Write pseudo-code first, but make sure to tell your interviewer that you're writing pseudo-code!
4. Write your code, not too slow and not too fast.
5. Test your code and carefully fix any mistakes.

Step 1: Ask Questions

Good questions might be like: What are the data types? How much data is there? What assumptions do you need to solve the problem? Who is the user?

Step 2: Design an Algorithm

1. What are the space and time complexities?
2. What happens if there is a lot of data?
3. Does your design cause other issue? (i.e., if you are creating a modified version of a binary search tree, did you design impact the time for insert/ find/ delete?)
4. If there are other issues, did you make the right trade-offs?
5. If they gave you specific data(e.g., mentioned that the data is ages, or in sorted order), have you leveraged that information? There's probably a reason that you're given it.

Step 3: Pseudo-Code

Writing pseudo-code first can help you outline your thoughts clearly and reduce the number of mistakes you commit.

Step 4: Code

You don't need to rush through your code; in fact, it will most likely hurt you. Just go at a nice, slow methodical pace.

1. Use Data Structures Generously: Where relevant, use a good data structure or define your own.

(i.e., what structure used to represent a person, which shows caring about object oriented design)

2. Don't Crowd Your Coding.

Step 5: Test

1. Extreme case: 0, negative, null, maximum, etc.
2. User error: What happens if the user passes in null or a negative value?
3. General cases: Test the normal case.

If the algorithm is complicated or highly numerical(bit shifting, arithmetic, etc.), consider testing while you're writing the code rather than at the end.

Also, when you find mistakes(which you will), carefully think through why the bug is occurring. Don't try to make "random" changes to fix the error.

When you notice problems in your code, really think deeply about why your code failed before fixing the mistake.

Before the Interview | Technical Preparation

Data Structures

Linked Lists
Binary Trees
Tries
Stacks
Queues
Vectors / ArrayLists
Hash Tables

Algorithms

Breadth First Search
Depth First Search
Binary Search
Merge Sort
Quick Sort
Tree Insert / Find /etc

Concepts

Big Manipulation
Singleton Design Pattern
Factory Design Pattern
Memory (Stack vs Heap)
Recursion
Big-O Time