Mock Coding Interviews

# CHAPTER 18

Mock Coding Interviews #

1. Chapter Introduction #

2. The 45-Minute Timeline #

• Minutes 0-5: Understand and Clarify. (Ask questions, define edge cases).

• Minutes 5-10: Brainstorm and Plan. (State the Brute Force, propose the optimal approach).

• Minutes 10-30: Implementation. (Write the code cleanly, talking out loud).

• Minutes 30-40: Testing and Review. (Dry-run the code with a test case, find bugs).

• Minutes 40-45: Complexity Analysis & Questions. (State Big-O, ask them about the company).

3. Step 1: Clarification (The Defensive Opening) #

1. 1. "Are the numbers sorted?" (Dictates Two Pointers vs Hash Map).

1. 2. "Can there be negative numbers?"

1. 3. "Will there always be exactly one valid answer?"

1. 4. "Can I use the exact same element twice?"

1. 5. "What should I return if the array is empty?"

4. Step 2: Brainstorming (The Brute Force Rule) #

5. Step 3: Implementation (Thinking Out Loud) #

• Narrate your typing: "I'm initializing a Hash Set here to keep track of the visited nodes so we don't hit an infinite loop."

• Modularize: If a piece of logic is messy (like checking if a coordinate is valid on a grid), don't write 5 lines of messy if statements. Write: if isValid(row, col): and tell the interviewer, "I will implement this helper function later to keep the main logic clean."

6. Handling Hints Gracefully #

7. Step 4: The Dry Run (Self-Debugging) #

# Code:
# for num in nums:
#     count += num

# Trace: 
# nums = [2, 4]
# Iter 1: num = 2, count becomes 2
# Iter 2: num = 4, count becomes 6

Catching your own bug during a dry-run shows extreme engineering maturity. If the interviewer points out the bug before you do, you lose points.

8. Whiteboard vs. Shared Editor #

• Whiteboard (In-person): Start writing on the far left edge of the board. Leave massive spaces between lines of code so you can insert lines later without erasing everything.

• Shared Editor (CoderPad/HackerRank): Rely heavily on your IDE structure. Write a comprehensive comment block at the top outlining your algorithm before typing syntax.

9. Common Mistakes #

• The Silent Panic: You freeze. You stare at the board for 3 minutes in silence. *The Fix:* Talk. Say, "I am trying to decide between a BFS and a DFS. BFS would guarantee the shortest path, but..." The interviewer will often gently guide you if you think out loud.

• Premature Optimization: Trying to write the perfect, one-line, clever O(1) space solution, getting confused, and writing nothing. A working Brute Force is better than a broken optimal solution.

10. Best Practices #

• Define Big-O Unprompted: At the end of the dry-run, do not wait to be asked. "So, this algorithm iterates through the array once, giving us O(N) Time complexity, and uses a Hash Map storing at most N elements, giving us O(N) Space."

11. Exercises #

1. 1. Perform a Solo Mock Interview. Write down the prompt for "Two Sum". Record yourself on video for 20 minutes solving it on a piece of paper while speaking out loud. Watch the video. Did you explain the Time Complexity clearly?

1. 2. Write down 3 clarifying questions you would ask for the prompt: "Find the longest substring."

12. MCQs #

14. Interview Questions #

• Q: "You have 5 minutes left. Your code works, but the interviewer asks: 'Can you do this in O(1) Space instead of O(N)?' You don't have time to rewrite it. How do you respond?"

15. FAQs #

• Q: Should I ask the interviewer how the code will be tested?

16. Summary #

17. Next Chapter Recommendation #