THN Interview Prep

Pattern Template

Use this as the target shape for pattern pages. Pattern pages may include extra Step-by-step Visual sections when a worked visual makes recognition or invariants clearer. The current repo check validates frontmatter and internal links; section-shape validation is a future quality gate.


# NN. <Pattern Name>

## TL;DR
One paragraph: what the pattern is and the kind of problem it cracks.

## Core Basics

- **Object:** the abstract thing you manipulate (interval, bitmask, trie node …) and why it earns better than brute force.
- **Winning structure / invariant:** the property you preserve each step—monotonicity, optimal subproblem, greedy exchange, etc.
- **Staff-level bar:** the correctness story you owe before you optimize (ordering argument, discard-half proof, amortized progress).

## Recognition Cues
- Phrases in problem statement that scream this pattern.
- Input/output shapes (sorted array, contiguous subarray, "kth", etc.).

## Use-case Lens
- **Best when:** what real problem shape this pattern solves.
- **Not for:** a tempting but wrong use case.
- **Main invariant:** the sentence you must be able to say while coding.
- **Interview move:** how to explain the optimization over brute force.

## Diagram
One colorful Mermaid diagram: usual control flow, pointer movement, or decision tree for when to pick this pattern. Use `classDef` colors and **camelCase** node IDs.

```mermaid
flowchart LR
  cueNode[Recognition cue] --> patternNode[Pattern applies]
  patternNode --> recipeNode[Run generic recipe]
  classDef cue fill:#dbeafe,stroke:#2563eb,color:#111827
  classDef work fill:#dcfce7,stroke:#16a34a,color:#111827
  class cueNode cue
  class patternNode,recipeNode work
```

## Step-by-step Visual
Optional visual enrichment for patterns that benefit from a worked trace, state table, pointer movement, queue evolution, recursion tree, heap snapshot, or DP table. Keep it focused on one canonical example.

## Understanding
Picture / deep model. Same intent as earlier "mental model": why each move is safe once you've matched cues.

## Generic Recipe
Numbered steps you'd code without thinking once you've matched the pattern.
1. Initialize ...
2. Loop while ...
3. Update ...
4. Return ...

## Complexity
- Time: typical and worst case.
- Space: typical.

## Memory Hooks

- Operational mantra plus one anti-forgetting handle (cue → invariant → complexity).
- Optional: acronym / shape you chant under interview pressure.

## Study Pattern (SDE3+)

- **Recognition drill:** predict pattern + complexity from constraints only—before peeking notes.
- **Implementation sprint:** code from skeleton on a timer; enforce edge-case checklist verbally first.
- **Staff follow-up:** rehearse breaking one assumption (immutable input, stream, memory cap, parallel readers) without rewriting from scratch.

## Generic Code Template

### Go
```go
func patternTemplate(input []int) int {
    // skeleton
}
```

### JavaScript
```js
function patternTemplate(input) {
    // skeleton;
}
```

## Variants
- Variant A — when to switch (e.g., "shrink-only" window vs "fixed-size" window).
- Variant B — common twists.

## Representative Problems
At least 3 — link to real files under `topics/<topic>/problems/NNN-kebab-name.md`:
- Problem A (vanilla) — `../topics/<topic>/problems/NNN-kebab-name.md`
- Problem B (variant) — same pattern, different constraint
- Problem C (hard) — stretch application

## Anti-patterns
- When this pattern looks tempting but isn't right.
- Common bugs (off-by-one, missed shrink condition, etc.).

Mark this page when you finish learning it.

Last updated on

Spotted something unclear or wrong on this page?

On this page