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

Programming Interviews Exposed reading notes 1

Approaches to Programming Problems
 (Secrets to Landing Your Next Job)

Take the time to make your code solid and pretty.

Lesson1: These problems are hard! Some of the questions are designed to see how you handle a problem when you don't immediately see the solution.

Lesson2: Brush up on the languages you expect to use, and write your best code.

Lesson3: Keep talking! Always explain what you are doing.

Lesson4: Many questions involve ridiculous restrictions, use obscure feature of languages, and seem silly and contrived. Play within the rules.

Lesson5: Make sure you understand the problem before you start solving it, then start with an example to solidify your understanding.

Lesson6: Explain what you are doing to your interviewer before and while coding the solution. Keep talking!

Lesson7: Try an example, and check all error and special cases.

Lesson8: When all else fails, return to a specific example. Try to move from the specific example to the general case and from there to the solution.

Lesson9: Sometimes a different data structure or advanced language feature is key to the solution. (advanced feature: bit operators, union types, complex pointer casting and advanced keywords )

p.s.
1. One of the shared traits of almost all interview coding questions is that the correct solutions are short. You rarely need to write more than 15 lines of code and almost never more than 30. If you start writing lots of code, it should be a warning that you may be heading in the wrong direction.
2. You often need to compare a value to NULL or 0.
    if ( elem != NULL ) { or if ( elem ) {

Understanding

In this assignment 1, I keep low efficiency as usual until I asked help for Ben. Thanks, Ben, first.

He pointed out freeing lock in lock_acquire() section, kfree(lock->lk_name) and kfree(lock), which were ignored by myself all the time. In the responding email to him, I said that the only reason I do that is having not understood codes completely. Yes, I have no courage to advise codes written by the professor, I’m afraid of the authority.

Understanding is quite significant. Computer Science and coding are good ways to train my understanding capability. Maybe I have to maintain pursuit for PhD in CS.

Work hard. Think hard. Understand hard. Last long!