Phase 0 — Interview Execution Baseline

Target level: Beginner → Easy Expected duration: 1 week (12-week track) / 1–2 weeks (6-month) / 2 weeks (12-month) Weekly cadence: 7 labs + 25 Easy problems applying the framework rigorously

Why This Phase Exists

Most candidates fail interviews not because they lack algorithms knowledge, but because of execution failures: they jump to coding before understanding the problem, panic when stuck, miss obvious edge cases, or communicate so poorly that the interviewer can’t tell whether they actually solved it.

Phase 0 fixes execution. It does not teach algorithms. It teaches you how to use what you already know.

Concepts To Master

1. How Coding Interviews Are Evaluated

Every modern coding interview at Big Tech uses a multi-dimensional rubric. The dimensions are roughly:

• Problem understanding — did you grasp what was asked?
• Approach quality — did you find a reasonable solution?
• Optimality — did you reach the optimal complexity?
• Implementation correctness — does your code actually work?
• Code quality — would your code pass code review?
• Testing — did you verify your solution?
• Communication — could the interviewer follow your thinking?
• Tradeoff awareness — do you understand what you chose and why?

Each is scored ~independently. A “hire” decision typically requires strong scores on most dimensions, not perfect on one. Code that works but is uncommunicated is often a no-hire.

2. How To Communicate While Solving

See ../COMMUNICATION.md in full. The summary: narrate your intent, not your typing. Pause at decision points. Ask before assuming.

3. How To Ask Clarifying Questions

Good questions:

• “Can the input be empty?”
• “Are there duplicates allowed?”
• “What’s the expected size of N — is 10^5 reasonable?”
• “Does the order of output matter?”
• “What should happen on invalid input?”
• “If multiple valid answers exist, can I return any one?”

Bad questions:

• Re-asking what’s already in the problem statement (signals poor reading)
• “What’s the optimal complexity?” (this is your job to derive)
• 15 questions in a row (drip them as relevant)

4. How To Derive Constraints

Constraints dictate the algorithm. Memorize this table:

Rule of thumb: in modern judges, 10^8 simple operations per second is safe; 10^9 is risky.

5. How To Create Examples

The given examples are minimum-coverage. You should construct:

• Trivial: size 0, size 1.
• Boundary: all duplicates, all negatives, all sorted, all reversed.
• Adversarial: max-constraint values, edge of integer range.
• Multi-answer: if multiple valid outputs exist, pick a specific one.

Working through your own examples often reveals the pattern faster than reading the problem 5 more times.

6. How To Identify Edge Cases

Universal checklist (run through this every problem):

• Empty input
• Null input (where applicable)
• Single element
• Two elements
• Duplicates
• Negative numbers
• Maximum constraint values (overflow risk)
• Sorted input
• Reversed input
• Disconnected graph
• Cycle in graph
• Multiple valid answers
• All identical values
• Off-by-one at boundaries

7. How To Start With Brute Force

The brute force is mandatory. Even when you “see” the optimal:

• It anchors correctness — you have a working oracle.
• It’s a starting point to optimize from.
• It’s a fallback if optimization fails.
• It demonstrates you understand the problem at all.

State the brute force in pseudocode within the first 3 minutes.

8. How To Optimize

Optimization checklist:

• Pattern recognition — does this match a known pattern? See Phase 2.
• Repeated work — what does the brute force recompute? That’s your DP / memo target.
• Sortedness — would sorting help? Two pointers, binary search, sweep line.
• Monotonicity — is the answer monotonic in some parameter? Binary search on answer.
• State compression — can the state space be made smaller? Bitmask, prefix sum.
• Math — closed form, modular arithmetic, combinatorics.
• Data structure — would a heap / BST / segment tree change the complexity?

9. How To Prove Correctness

• Greedy: exchange argument — show that any optimal solution can be modified to use the greedy choice without losing optimality.
• DP: state definition, transition, base cases, evaluation order.
• Two-pointer / sliding window: loop invariant.
• Graph algorithms: cite the algorithm’s correctness theorem and verify preconditions hold.
• Math: induction or direct calculation.

10. How To Explain Complexity

State time and space. Mention:

• Whether the bound is tight.
• Amortized vs worst case (e.g., dynamic array push is O(1) amortized, O(N) worst case).
• Assumptions (hash table O(1) average requires non-adversarial input).
• Constants when they matter (e.g., bitset gives 64× speedup over bool array).

11. How To Write Clean Code Under Time Pressure

See ../CODE_QUALITY.md. Quick rules:

• Meaningful names.
• Helper functions for distinct units.
• Validate at the boundary, not in hot loops.
• No globals.
• Standard library used idiomatically.

12. How To Test Manually

1. Walk through given example by hand. Record intermediate state.
2. Walk through one trivial case (empty / size 1).
3. Walk through one adversarial case.
4. Find at least one bug before submitting.

13. How To Recover When Stuck

Use the stuck protocol. Restate, brute force, examine constraints, try smaller examples, look for repeated work, look for monotonicity, look for graph modeling, ask for a hint.

14. How To Use Hints Without Failing The Interview

A hint is not a failure. Frozen silence is. Sample phrasing:

“I’ve explored two pointers and sliding window, but I’m having trouble seeing how to handle duplicates without O(N^2). Could you nudge me toward the right family of approach?”

Receive the hint, restate it, commit out loud, resume.

Why These Concepts Matter In Interviews

Algorithms are necessary but not sufficient. Of all rejected candidates with strong algorithm knowledge, the most common failure modes are:

• “Could not communicate clearly” (60%+)
• “Did not test their code” (40%+)
• “Could not articulate complexity” (30%+)
• “Got stuck and couldn’t recover” (30%+)
• “Misunderstood the problem” (20%+)

(Percentages are approximate, based on common interviewer feedback patterns.)

Phase 0 fixes all of these.

Required Problem Categories

Phase 0 problems are not algorithmically hard. The challenge is execution. Use only Easy problems:

• Two Sum
• Reverse String
• Valid Palindrome
• Maximum Subarray (Kadane’s)
• Best Time To Buy And Sell Stock
• Single Number
• Merge Two Sorted Lists
• Linked List Cycle
• Binary Tree Inorder Traversal
• Symmetric Tree
• Maximum Depth Of Binary Tree
• Climbing Stairs
• Move Zeros
• Contains Duplicate
• Intersection Of Two Arrays
• Reverse Linked List
• Valid Parentheses
• Implement Stack Using Queues
• First Bad Version
• Squares Of A Sorted Array

Solve each one applying the full framework. The point is not the answer; it’s the execution discipline.

Recommended Resources

• This curriculum’s FRAMEWORK.md, COMMUNICATION.md, CODE_QUALITY.md
• LeetCode Easy tier (filter by Easy)
• “Cracking the Coding Interview” (Gayle Laakmann McDowell) — chapters 1, 2, 6, 7 (the soft-skills chapters; skip the rest until later)

Hands-On Labs

Complete in order. Each lab uses the strict lab format from the curriculum spec.

1. Lab 01 — Problem Statement Reading
2. Lab 02 — Constraints Extraction
3. Lab 03 — Brute Force First
4. Lab 04 — Optimization Pathway
5. Lab 05 — Manual Testing
6. Lab 06 — Communication
7. Lab 07 — Stuck Recovery

Common Mistakes In Phase 0

• Skipping Phase 0 thinking “I already know this stuff” — execution skills are different from knowledge
• Solving Easy problems silently — the whole point is communication practice
• Skipping the brute force because the optimal is obvious
• Skipping the testing step because the code “looks right”
• Not timing yourself — you don’t know your real solving speed until you measure
• Treating clarifying questions as a checklist — they should feel natural and motivated, not robotic

Mastery Checklist

• Solve any LeetCode Easy in 12 minutes including brute force, optimization, testing, complexity
• Restate every problem in your own words without re-reading the prompt
• Ask 3+ relevant clarifying questions on every problem
• Always state the brute force first (even if 10 seconds long)
• Walk through at least one example by hand before submitting
• Explain complexity correctly on every problem
• Find at least one bug pre-submission on at least 30% of problems (this is good!)
• Never go silent for >60 seconds when working a problem
• Recover from being stuck using the stuck protocol within 3 minutes

Exit Criteria

Move to Phase 1 only when:

1. Mastery checklist 100% checked
2. Completed all 7 labs
3. Solved 25 Easy problems applying the full framework
4. Recorded yourself solving 3 problems and reviewed the playback for communication quality
5. Run a self-mock with one Easy problem you’ve never seen — pass with full framework execution

If any item fails, repeat Phase 0 with another 25 problems. Do not move forward with a weak baseline.