Time Management & Edge Cases

You have 45 minutes. That is not a suggestion — it is a hard constraint. Candidates who run out of time with an incomplete solution fail the interview regardless of how elegant their partial approach was. Time management is a skill, and handling edge cases is what separates a working solution from a correct one.

The 45-Minute Breakdown

Every coding interview follows roughly the same structure. If you do not impose time discipline, the problem will eat all your time in the first two phases and leave nothing for testing.

Minutes 0-5:    Understand the problem
Minutes 5-10:   Discuss approach and trade-offs
Minutes 10-35:  Write the code
Minutes 35-45:  Test with examples and fix bugs

This is not rigid. Some problems need more understanding time, some need less coding time. But if you are 20 minutes in and have not started coding, you are in trouble. If you are 40 minutes in and have not tested, you are in trouble.

Phase 1: Understand the Problem (5 Minutes)

Read the problem statement carefully. Restate it in your own words. Identify the input type, output type, and any constraints.

What to establish in the first 5 minutes:
  - What exactly are the inputs and outputs?
  - What are the size constraints? (n up to 10^5 means O(n log n) or better)
  - Are there any special conditions? (sorted input, unique elements, etc.)
  - What should happen with invalid or empty input?
  - Is there a required time or space complexity?

Do not start coding during this phase. You are building a mental model. Rushing past this phase is the single most common time management mistake because misunderstanding the problem wastes far more time than the 5 minutes you saved.

Phase 2: Discuss Approach (5 Minutes)

Propose your approach before writing code. Start with brute force if you are unsure, then optimize. The interviewer may redirect you if you are heading in a bad direction — better to find out now than after 20 minutes of coding.

Approach discussion template:
  "The brute force would be [X], which is O(n^2).
   I think we can do better with [Y], bringing it to O(n log n).
   The trade-off is [Z] extra space.
   Let me outline the steps before I code:
     1. [First step]
     2. [Second step]
     3. [Third step]
   Does that sound reasonable?"

Getting a nod from the interviewer before coding is like getting requirements sign-off before building. It prevents wasted effort.

Phase 3: Write the Code (25 Minutes)

This is the longest phase. Write clean, readable code. Use meaningful variable names. Do not try to be clever — clever code takes longer to write, longer to debug, and longer for the interviewer to read.

Coding priorities:
  1. Get the core logic right first
  2. Handle the happy path end to end
  3. Add edge case handling
  4. Clean up variable names and structure

Do NOT:
  - Write pseudocode first and then rewrite as real code (double work)
  - Optimize prematurely (get it working, then optimize if time permits)
  - Write helper functions you might not need

If you realize your approach is wrong at minute 20, do not panic. You have two options: fix the approach if the change is small, or restart with a simpler approach if the current one is fundamentally broken. Restarting at minute 20 with a clear plan is better than spending 15 more minutes patching a broken approach.

Phase 4: Test (10 Minutes)

Never say "I think I'm done" without testing. Walk through your code with a concrete example, tracking variable values on paper or verbally.

Testing process:
  1. Trace through a small normal-case example
  2. Trace through one edge case (empty input or single element)
  3. Check boundary conditions (off-by-one errors)
  4. Verify the return value is correct type and format

Edge Cases That Break Solutions

Edge cases are the inputs that most candidates forget. Interviewers include them deliberately because they test whether you think like a production engineer or a homework submitter.

Empty Input

The most common edge case. Every function that takes a collection should handle an empty one.

Empty input scenarios:
  - Empty string: ""
  - Empty array: []
  - Empty tree: null/None root
  - Empty graph: no nodes
  - Zero: n = 0

What usually goes wrong:
  - Array index out of bounds on first access
  - Null pointer dereference
  - Division by zero when computing averages
  - Returning undefined instead of a defined empty result

Single Element

The next most common. Many algorithms have special behavior with one element.

Single element scenarios:
  - Array with one element: [5]
  - String with one character: "a"
  - Tree with only root
  - Linked list with one node

What usually goes wrong:
  - Two-pointer approaches where left == right
  - Sliding window with window size > array length
  - "Previous element" references when there is no previous

Duplicates

If the problem does not explicitly say elements are unique, assume duplicates exist.

Duplicate scenarios:
  - All elements identical: [3, 3, 3, 3]
  - Two elements swapped: [1, 3, 2, 4]
  - Duplicates at boundaries: [1, 1, 2, 3, 3]

What usually goes wrong:
  - Binary search finding wrong occurrence
  - Hash maps overwriting previous entries
  - Counting algorithms double-counting
  - Sort stability assumptions

Negative Numbers

If the problem involves integers and does not specify positive-only, test with negatives.

Negative number scenarios:
  - All negative: [-5, -3, -1]
  - Mix of positive and negative: [-2, 0, 3, -1, 4]
  - Maximum sum subarray with all negatives

What usually goes wrong:
  - Initializing max to 0 instead of negative infinity
  - Absolute value assumptions in comparisons
  - Modulo operator behaving differently with negatives
  - Bit manipulation with sign bit

Integer Overflow

Especially relevant in languages with fixed-width integers (Java, C++), but also matters in Python when converting to other formats.

Overflow scenarios:
  - Summing large arrays: sum of 10^5 elements each up to 10^9
  - Multiplying large numbers: n * (n-1) when n is close to MAX_INT
  - Intermediate calculations exceeding bounds

What usually goes wrong:
  - mid = (left + right) / 2 overflows; use left + (right - left) / 2
  - Factorial computations for combinatorics
  - Accumulator variables using int instead of long

Sorted & Reverse Sorted Input

Many algorithms behave differently on sorted vs. unsorted input. Quicksort with a naive pivot degrades to O(n^2) on sorted input.

Sorted input scenarios:
  - Already sorted ascending: [1, 2, 3, 4, 5]
  - Already sorted descending: [5, 4, 3, 2, 1]
  - Nearly sorted: [1, 2, 4, 3, 5]

What usually goes wrong:
  - BST insertion creating a linked list
  - Quicksort hitting worst-case performance
  - Algorithms that assume random distribution

Large Input

Even if you cannot test with large input during the interview, mention it. It shows you think about production.

Large input considerations:
  - n = 10^5 means O(n^2) will time out
  - n = 10^6 means O(n log n) is borderline
  - String concatenation in a loop is O(n^2) in many languages
  - Recursive solutions may hit stack overflow

Time Management Under Pressure

The 20-Minute Checkpoint

At the 20-minute mark, assess where you are. If you have not started coding, you need to start immediately, even if your approach is not fully formed. A working brute-force solution that passes basic cases is worth more than an elegant but incomplete optimal solution.

20-minute checkpoint:
  If you have working code:
    - You are on track. Continue to optimize and test.
  If you have partial code:
    - Focus on getting a working solution first.
    - Optimize only if you finish early.
  If you have no code:
    - Start coding immediately.
    - Use brute force if you must.
    - Talk through your approach as you code.

The 35-Minute Checkpoint

At the 35-minute mark, stop coding new features. Whatever you have, start testing it. A solution with a known bug that you can identify is better than a solution you never verified.

35-minute checkpoint:
  If your solution works:
    - Test edge cases. Mention optimizations you would make.
  If your solution has bugs:
    - Fix the most critical bug. Mention others verbally.
  If your solution is incomplete:
    - Explain what remains. Write pseudocode for missing parts.
    - Test what you have.

When You Are Behind

If you are running out of time, switch from writing perfect code to communicating your knowledge.

Behind-schedule recovery:
  "I'm running low on time, so let me describe my approach for
  the remaining part. I would use a priority queue here to
  maintain the top-k elements, which gives O(n log k) instead
  of sorting the entire array. The implementation would be
  about 10 more lines. Let me test what I have so far."

This tells the interviewer you know the solution even if you could not finish typing it. Partial credit for demonstrated understanding is better than zero credit for unfinished code.

Building an Edge Case Checklist

Before every interview, internalize this checklist. Run through it mentally after writing your solution.

Edge case checklist:
  [ ] Empty input (empty string, empty array, null)
  [ ] Single element
  [ ] Two elements
  [ ] All elements identical
  [ ] Duplicates present
  [ ] Negative numbers
  [ ] Zero as input
  [ ] Very large input (performance)
  [ ] Already sorted input
  [ ] Reverse sorted input
  [ ] Input at integer boundaries (MAX_INT, MIN_INT)
  [ ] Odd vs. even length (for problems involving midpoints)

You will not test all of these in every interview. But scanning the list mentally takes 30 seconds and can catch the one edge case that would have sunk your solution.

Common Pitfalls

Spending too long on the perfect approach — a working brute force beats an unfinished optimal solution every time
Not testing at all — saying "I think this is correct" without tracing through an example is a red flag
Testing only the example given in the problem — interviewers design examples to pass even broken solutions; use your own test cases
Forgetting empty input — this single edge case accounts for a huge percentage of interview bugs
Initializing max/min incorrectly — using 0 instead of negative infinity for max, or positive infinity for min
Off-by-one errors in loops — should it be less-than or less-than-or-equal? Test with a two-element case to find out
Not watching the clock — ask the interviewer how much time remains if there is no visible timer

Key Takeaways

Divide 45 minutes into four phases: 5 understanding, 5 planning, 25 coding, 10 testing — and enforce this on yourself
Start coding by minute 10 at the latest, even if your approach is not fully optimized
At minute 20, check your progress and adjust strategy if needed
At minute 35, stop coding new logic and start testing with concrete examples
Maintain a mental edge case checklist: empty, single, duplicates, negatives, overflow, sorted, large
When running out of time, switch from coding to communicating — explain what you would do even if you cannot type it all
A complete, tested, brute-force solution outscores an incomplete optimal solution in almost every scoring rubric