Dynamic Programming

Almost every coding round at Notion borrows a slice of the product for its problem. A page of nested blocks is a tree, so it hands the interviewer a traversal. A set of dependent automations is a directed graph, so it hands them a topological sort. A table view is a group-by, undo and redo are two stacks, tags across pages are hash sets. Dynamic programming is the exception. Nothing in a document platform naturally hands an interviewer a Premium question or a Premium question. So when DP does appear, it appears plain. By weight it is the smallest family on the loop, roughly one problem in twelve, and the problems are canonical mediums: a fewest-coins count, a can-this-string-be-split check, a longest-increasing-run.

That makes DP the one part of the coding section you prepare differently. Everywhere else the work is recognizing a data structure you already know once the interviewer hands it to you inside a Notion feature, then modeling the mutable state cleanly under a live follow-up. Here there is no product surface to read past. You are asked whether you can name a state, derive its transition, and write it up so it runs against the cases. Because it is rare, the plan is simple. Drill enough to recognize the shape on sight and reach the standard variant cleanly, and skip the hardest combinatorial puzzles that a practical, product-minded loop almost never reaches for.

The Notion angle

Dynamic programming is the one coding family Notion poses straight, with none of the block, table or task-graph framing it gives the rest of the section. Treat it as plain fundamentals and skip the product-translation drills that pay off elsewhere. The block tree hands an interviewer a tree walk and a dependency graph hands them a topological order. Undo and redo hand them a pair of stacks, and a Premium question hands them a group-by. None of those is DP. Nothing in a documents-and-databases product hands you a knapsack or a Premium question, so the recurrences stay textbook.