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?