ROPITA Framework
A repeatable problem-solving process for technical interviews
ROPITA Framework
// FRAMEWORK
The ROPITA framework is not an algorithm—it's a repeatable problem-solving process you can apply to any coding interview. It ensures you understand the problem fully before coding, and it gives the interviewer visibility into your thinking at every step.
The six steps are: Read, Observe, Pseudocode, Implement, Test, Analyze.
Table of Contents
READ
Question: What exactly is this problem asking me to return?
Focus: Inputs, outputs, constraints, and assumptions. Read the problem statement word by word. Clarify ambiguities aloud.
What the Interviewer is Evaluating: Can you understand requirements? Do you ask clarifying questions rather than assume? Do you catch edge cases early?
Common Mistake: Starting to code before you fully understand what "correct" means. You might solve the wrong problem perfectly.
Example:
You're given: "Find two numbers in an array that sum to a target."
Clarify: "Can the array have duplicates? Can I use the same element twice? Should I return indices or values? What if no pair exists?"
OBSERVE
Question: What patterns do I notice in the inputs and expected outputs?
Focus: Work through examples (especially small and edge cases). Look for structure: is the data sorted? Repeated elements? Any transformations happening?
What the Interviewer is Evaluating: Do you work through concrete examples before jumping to code? Do you spot patterns that hint at the right approach?
Common Mistake: Skipping examples and jumping straight to the algorithm. Examples are where you find the key insight.
Example:
For Two Sum, observe:
- Small example:
[2, 7, 11, 15], target 9 → output[0, 1](indices of 2 and 7) - Notice: if you've seen 2, and you need 9 − 2 = 7, a hash map helps
- Edge case:
[1, 1], target 2 → both indices needed, no reuse within one iteration
PSEUDOCODE
Question: What's my step-by-step plan in plain language?
Focus: Write out logic in readable steps—no syntax, no implementation details. This is your "algorithm outline."
What the Interviewer is Evaluating: Do you think before you code? Can you explain your approach clearly? Is your plan sound?
Common Mistake: Pseudocode that's too vague ("loop through and find it") or too detailed (it's almost code—why not just code?). Aim for the middle ground.
Example:
For Two Sum:
- Create an empty hash map
- For each number in the array:
- Calculate complement = target − current number
- If complement exists in the map, return the two indices
- Otherwise, store current number and its index in the map
- If no pair found, return null or an empty result
IMPLEMENT
Question: How do I translate my pseudocode into working code?
Focus: Write clean, readable code. Handle edge cases as you go. Choose a language you're fluent in.
What the Interviewer is Evaluating: Can you code without syntax errors? Do you follow language idioms? How do you handle null or empty inputs?
Common Mistake: Writing slow code that works, or correct code that's unreadable. Aim for both correctness and clarity.
Example:
def two_sum(nums, target):
seen = {}
for i, num in enumerate(nums):
complement = target - num
if complement in seen:
return [seen[complement], i]
seen[num] = i
return []
TEST
Question: Does my code work on all test cases—typical, edge, and tricky?
Focus: Walk through your code with test cases. Trace variables step by step. Test edge cases (empty input, single element, all duplicates, etc.).
What the Interviewer is Evaluating: Do you verify your work? Can you catch bugs before being told about them? Do you think about edge cases?
Common Mistake: Testing only the "happy path" and missing edge cases that break your code.
Example for Two Sum:
[2, 7, 11, 15], target 9 → expect[0, 1]✓[1, 1], target 2 → expect[0, 1]✓[], target 5 → expect[]✓[5], target 10 → expect[](can't reuse) ✓- Negative numbers:
[-1, 0, 1, 2], target 1 → expect[0, 3]✓
ANALYZE
Question: What's the time and space complexity? Can I optimize further?
Focus: Count operations (loops, recursion depth, hash operations). Identify dominant terms. Discuss trade-offs: is there a faster solution that uses more memory?
What the Interviewer is Evaluating: Do you understand complexity? Can you optimize? Do you know your solution's limits?
Common Mistake: Stating complexity without justifying it, or claiming O(n) when it's actually O(n²).
Example for Two Sum:
- Time: O(n) — one pass through the array, hash operations are O(1) on average
- Space: O(n) — hash map stores up to n elements
- Trade-off: This is faster than a nested loop O(n²) with O(1) space
Complete Worked Example: Two Sum
Let's apply ROPITA end-to-end on the classic Two Sum problem.
Problem: Given an array of integers and an integer target, return the indices of the two numbers that add up to the target. You may not use the same element twice. Assume exactly one solution exists.
READ
- Input: array of integers, a target integer
- Output: array of two indices (or empty if no solution)
- Constraint: each element can be used at most once
- Assumption: exactly one solution exists
OBSERVE
nums = [2, 7, 11, 15], target = 9
→ We need 2 + 7 = 9, so return [0, 1]
nums = [3, 3], target = 6
→ Both elements, different indices: [0, 1]
PSEUDOCODE
- Create a hash map to store value → index
- Iterate through the array
- For each number, check if (target − number) is in the map
- If yes, return [map[complement], current_index]
- If no, add the number to the map
- If loop completes, no pair found (but problem guarantees one exists)
IMPLEMENT
def two_sum(nums, target):
seen = {}
for i, num in enumerate(nums):
complement = target - num
if complement in seen:
return [seen[complement], i]
seen[num] = i
return []
TEST
[2, 7, 11, 15], target 9 →[0, 1]✓[3, 3], target 6 →[0, 1]✓[3, 2, 4], target 6 →[1, 2](2 + 4) ✓
ANALYZE
- Time: O(n) — single pass, hash operations are O(1)
- Space: O(n) — hash map in worst case
- Why it works: Hash map gives O(1) lookup, avoiding a nested O(n²) loop
Key Takeaways
- Read first. Understand the problem completely before coding.
- Observe patterns. Examples guide your algorithm choice.
- Plan (pseudocode). Show your thinking before implementation.
- Implement cleanly. Write readable, correct code.
- Test thoroughly. Catch bugs before the interviewer does.
- Analyze honestly. Know your solution's time and space costs.
ROPITA turns a blank screen into a structured conversation. Use it every time.