Plan Your Code: A Pre-Coding Strategy

Introduction

Hello! Welcome back to our course. In the last few lessons, we've tackled challenging problems like detecting cycles in linked lists and grouping anagrams by combining data structures for optimal performance. You've learned how to devise efficient solutions, a critical skill for any programmer.

However, in a technical interview, devising the solution is only half the battle. The other, equally important half is communicating your thought process. Interviewers want to understand how you think, how you analyze problems, and how you weigh different options. Simply jumping into code, even if it's the correct code, can leave them guessing about your problem-solving abilities.

Today's lesson is dedicated to mastering this crucial communication skill. Our learning outcome is to practice articulating a problem-solving approach before writing code. We will learn a structured framework that you can use in any technical interview to break down a problem, explore solutions, and explain your reasoning clearly and confidently.

The Power of a Deliberate Pause

The single most common mistake candidates make in technical interviews is starting to code too early. The urge to prove you can solve the problem is strong, but resisting it gives you a significant advantage. By pausing to think and talk, you:

Clarify Ambiguities: Ensure you're solving the right problem.
Showcase Analytical Skills: Demonstrate that you can think critically about trade-offs (like time vs. space complexity).
Create a Dialogue: Turn an interrogation into a collaborative problem-solving session with the interviewer.
Organize Your Thoughts: Prevent yourself from writing messy code or heading down a dead-end path.

To help structure this process, many developers use a mental framework. A popular one is the REACTO method.

Whiteboard Coding Interviews: 6 Steps to Solve Any Problem

Let's start with this video from Fullstack Academy, which introduces a fantastic framework for tackling interview questions called REACTO. It stands for Repeat, Examples, Approach, Code, Test, and Optimize. We'll focus on the first three steps today: R, E, and A.

Watch from 00:54 to 01:27 to get an overview of the REACTO acronym, and then from 11:02 to 11:58 to understand the core philosophy behind why you shouldn't start coding immediately. This sets the stage for our deep dive into the first three steps.

This "don't start writing right away" advice is the foundation of our lesson. Let's break down how to use that time effectively.

Step 1: Repeat, Question, and Clarify (The 'R')

Once the interviewer presents a problem, your first job is to make sure you understand it completely. Interview problems are often intentionally vague to see if you will seek clarification.

Steps Towards Problem Solving in a Technical Interview

This article provides a practical, step-by-step guide to the interview process. Let's focus on its advice for the first step.

Read 'Step 1: Clarify & Ask Questions'. Notice how a seemingly simple prompt ('Write a function to convert a string to a number') has many hidden complexities that need to be explored.

As the article shows, restating the problem in your own words and asking clarifying questions is essential. Here are some key areas to probe:

Inputs: What are the constraints on the input? (e.g., size of a list, range of numbers, empty inputs). Are inputs always valid?
Outputs: What is the expected format of the output? (e.g., a boolean, a list of indices, None for no solution).
Edge Cases: What about empty strings, zero, negative numbers, or duplicate values?

Asking these questions shows the interviewer you're thoughtful and meticulous.

Step 2: Create Examples (The 'E')

Once you've clarified the scope, the next step is to create a few concrete examples. This helps solidify your own understanding and confirms with the interviewer that you're on the same page.

Interview Question: Print Reversed Linked List

This video, which tackles a linked list problem, provides an excellent demonstration of how to generate examples and ask clarifying questions in a real interview context.

Watch from 00:38 to 02:11. Pay attention to the types of questions the presenter asks about the list's length, data types, and output format. These are the kinds of details that shape the solution.

When creating examples, try to include:

A simple, general case: The most straightforward example that illustrates the problem.
An edge case: What happens with an empty input, a single-element input, or other tricky scenarios?
A case that might fail: An example that produces a negative outcome (e.g., a string that is not a palindrome).

Step 3: Articulate Your Approach (The 'A')

This is the heart of today's lesson. Before writing a single line of code, you should talk through your potential solution(s). This is your chance to demonstrate your knowledge of algorithms and data structures.

A great way to structure this is:

Start with a brute-force solution. This shows you can find a working solution, even if it's not the most efficient. Acknowledge its limitations, especially its time complexity (e.g., "This would be $O (n^{2})$ , which might be too slow.").
Propose an optimized solution. Explain how you can improve upon the brute-force method. This often involves using a more suitable data structure, like a hash map, to trade space for time.
Discuss the trade-offs. Explicitly state the time and space complexity of your proposed optimal solution.

Let's watch a masterclass in this process.

Interview Question: Print Reversed Linked List

In the same video, the presenter now compares two different approaches to solving the problem: one iterative and one recursive. This is a perfect example of articulating your 'A' step.

Watch from 02:11 to 07:25. Notice how the presenter lists the pros and cons of each approach (reversing the list vs. using recursion), focusing on space complexity (stack space), time complexity (number of passes), and whether the original data is modified. This is exactly what interviewers want to see.

A Tool for Articulation: Pseudocode

A powerful tool for the "Approach" step is pseudocode. Pseudocode is a way of outlining your algorithm in plain language, using programming conventions like loops and conditionals, but without worrying about the exact syntax of a specific language.

Algorithm Problem-Solving Framework — This diagram shows a six-step problem-solving process. Notice how 'Write Pseudocode' comes *after* understanding the problem and choosing a strategy, but *before* implementation.

Writing pseudocode on the whiteboard or in the shared editor is a fantastic way to structure your thoughts and get feedback from the interviewer before you commit to code.

The Secret to Writing Code From Scratch: Start by Writing Pseudocode

Let's read this article to get a formal understanding of pseudocode and its role in problem-solving, especially in interviews.

Read the sections 'What is Pseudocode?', 'Why Start with Pseudocode?', 'Pseudocode in Problem-Solving and Technical Interviews', 'Teaching and Learning with Pseudocode', and the 'Conclusion'. This will give you a solid foundation in what pseudocode is and why it's so valuable.

Pseudocode: Definition and Best Practices — This image provides a helpful summary of best practices for writing clean and effective pseudocode.

Practice: Putting It All Together

Let's apply this R-E-A framework to a classic interview problem. We will not write the final Python code. Our entire goal is to practice the articulation that comes before coding.

Problem: Given a string s, find the first non-repeating character in it and return its index. If it does not exist, return -1.

Your Turn (Mental Walkthrough): Imagine you're in an interview. How would you proceed?

Click here to see a model walkthrough of the R-E-A steps.

Step 1: Repeat and Clarify (R)

You: "Okay, so I need to find the very first character in a string that appears only once. If all characters repeat, or the string is empty, I should return -1. Is that correct?"
Interviewer: "Yes, that's correct."
You: "A few clarifying questions: Is the string composed of only lowercase English letters, or can it include uppercase, numbers, or symbols? Is it case-sensitive (i.e., is 'a' different from 'A')?"
Interviewer: "Assume it's only lowercase English letters."
You: "Great, thanks."

Step 2: Examples (E)

You: "Let me walk through a few examples to make sure I understand."
- "If s = 'leetcode', the first character 'l' appears only once. So the output should be its index, 0."
- "If s = 'loveleetcode', 'l' repeats, 'o' repeats, 'v' is the first unique character. Its index is 2."
- "If s = 'aabb', all characters repeat. The output should be -1."
- "If s = '' (an empty string), there are no characters, so the output should be -1."
Interviewer: "Those examples are correct."

Step 3: Articulate Approaches (A)

You (Brute-force): "My first thought is a brute-force approach. I could iterate through the string with an outer loop, picking one character at a time. Then, with an inner loop, I could scan the entire string again to see if that character has any duplicates. The first character for which the inner loop finds no other occurrences would be my answer."
You (Analysis): "This would work, but the nested loops mean the time complexity would be $O (n^{2})$ . For a very long string, this might be too slow. The space complexity would be $O (1)$ ."
You (Optimized): "I can optimize this by trading some space for time. A hash map (a dictionary in Python) would be perfect here. I can use it to count the frequency of each character."

You (Pseudocode): "My plan would be a two-pass algorithm:"

// Pass 1: Build a frequency map
FUNCTION find_first_unique_char(s):
  SET frequency_map = an empty hash map
  
  FOR each character c in s:
    INCREMENT frequency_map[c] by 1
    
// Pass 2: Find the first unique character
FOR i from 0 to length(s) - 1:
  SET c = s[i]
  IF frequency_map[c] == 1:
    RETURN i // Found it!
    
// If the loop finishes, no unique character was found
RETURN -1

You (Analysis): "This approach is much more efficient. The first pass to build the map takes $O (n)$ time. The second pass to check for the first character with a count of 1 also takes $O (n)$ time in the worst case. So, the total time complexity is $O (n)$ . The space complexity would be $O (k)$ , where k is the number of unique characters in the string—at most 26 in this case—to store the frequency map. This seems like a very solid approach."

This detailed articulation proves you understand the problem, can analyze trade-offs, and can plan a robust, efficient solution. You've likely already passed the interview before writing a single line of Python.

Conclusion

Today, we took a step back from implementation and focused on the equally important skill of communication in a technical interview. By adopting a structured framework, you can turn a high-pressure test into a thoughtful conversation that showcases your problem-solving prowess.

Key Takeaways:

Don't start coding immediately. Pause to think, clarify, and plan.
Use a framework like REACTO (Repeat, Examples, Approach, Code, Test, Optimize) to guide your session.
Repeat and Clarify: Make sure you understand the problem's scope, inputs, outputs, and edge cases.
Use Examples: Solidify your understanding with simple, edge, and failing cases.
Articulate Your Approach: Discuss brute-force and optimal solutions, analyzing their time/space trade-offs.
Use Pseudocode: Outline your algorithm in plain language to organize your thoughts and communicate your plan effectively.

Preview of the Next Lesson:
In our final lesson, we will put everything together. You'll be given an unfamiliar problem, and you will apply the skills from this entire course—from data structures and algorithms to the communication framework we learned today—to break down the problem, explain your reasoning step-by-step, code the solution, and test it, simulating a complete technical interview from start to finish.

Recommended resources