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