Skip to content
- Ask relevant follow up questions
- Collect enough details about the problem
- Constraints & special properties often offer hints

- Don’t jump to conclusions and solutions immediately
- Always remember, devils are in the details

- Briefly discuss brute force approach, if required
- Map or break the problem into similar/smaller/known problems
- Do NOT invent a new/fancy data structure or algorithm

- Classify the problem as
- Math
- Sorting
- Searching
- Traversal
- Recursion
- Bit manipulation
- Dynamic programming
- Greedy approach
- Divide and conquer
- Backtracking
- Comparator

- Apply appropriate data structures (or a combination of)
- Arrays
- Stacks
- Queues
- Linked Lists
- Hash Tables
- Balanced BSTs
- MinHeap/MaxHeap
- Disjoint Set Union
- Tries (Prefix/Suffix Trees)
- Each data structure has its own strengths and weaknesses
- Identify the “pain points” in the problem
- Deploy the right (combination of) data structures for each pain point

- Before implementing your algorithm
- Discuss it with the interviewer
- Discuss it’s time and space complexity
- See if it can be improved based on above discussion

- Write test cases (before code!)
- Start small, test immediately
- Write functions that are
- Reusable
- Loosely coupled
- Small and do only one thing!

- Avoid
- Gotos
- Unnecessary variables
- Multiple return statements
- Unnecessary/many/nested if-elses

- Always
- Validate input
- Indent your code
- Use proper names (for functions and variables)
- Check return codes
- Handle corner cases
- Trace your code with test cases before telling the interviewer – done!

- Clearing design and behavioral interviews requires genuine experience
- Build as much (voluntary) stuff as possible using math, data structures and algorithms
- Have enough success and failure stories to talk about