Problem-Solving Roadmap

You can be handed a sentence — "build an online store", "make search better" — and produce, in an hour, a page a non-engineer would recognise: who uses it, what they do, which single workflow means it works, what must be true, and what can be ignored for now. You can tell a goal from an implementation someone has already smuggled into the request, restate the problem in your own words and get it corrected, and turn "how do payments work?" into a question with a verb in it that somebody could actually answer. Most importantly, you can notice the technology-first reflex in yourself — the repository that exists while the problem has not moved — and you know what the next question is instead.

You can take a problem you cannot yet see the shape of and make it concrete: three units in stock, Alice buys two, Bob buys two at the same moment — and read the edge cases and the counterexamples off the example instead of imagining them. You can break a problem into pieces small enough that each has an observation that would show it works, and tell a decomposition that is about the problem from one that is only "frontend, backend, database". You can write the inputs, outputs, state and branches of a function before its syntax, test the smallest case first, and when it breaks, reproduce it, halve the search space and read the error message before changing anything. You can do all of this without an assistant, and you know what the hint ladder is for when you get stuck.

You can run requirement discovery on a real request: the functional list, the non-functional questions nobody asked (how many users, how fast, what happens at 3 a.m.), the requirements that only surface once code exists, and the order in which to take them — happy path first, failure path second, and you can say where that order flips. You can surface the constraints that shape the architecture before any diagram — time, users, data, the technology you know against the technology you must use, budget, legal — and write the invariants that must never break as tests. You keep an assumption register ("one warehouse in V1") so that when the requirement changes you know why the design must, and you keep an unknowns board where every unknown is a specific question with a tiny experiment attached, because you no longer treat not knowing something as a reason to stop.

You can read "a customer places an order containing products" and see Customer, Order, OrderItem and Product, say which of them must persist and which price is a snapshot rather than a reference. You can find the boundaries of your system — the payment provider, the email sender, the object store — name the interfaces those boundaries need, and say which external dependency has to answer before the user can be told anything. You can draw the order lifecycle as a state machine and name the illegal states. You build in vertical slices — product page through API through database — rather than a week of database then a week of backend, you can say what a passing slice proves and what it does not, and you can draw the line between what an MVP may simplify and what it may never ignore. And once the happy path works, you go looking for the failures: payment fails, the request repeats, the database is down, the browser closes — and you inject them on purpose.

You can be dropped into a codebase you have never seen and find the entry point, follow the data, locate the state and the side effects, and understand the boundary — without trying to read all of it. You can pick up an unfamiliar technology by asking what problem it solves, what it guarantees, how it fails and what the alternatives are, and you can run the smallest experiment that tells you whether it fits, before it is on the critical path. You read the documentation for the concept you need rather than the tutorial that happens to exist, and you know what tutorial dependency looks like from the inside. You can design a spike with a question, a time box and a prediction, and you can tell a prototype that answered something from one that merely got built. And when someone says "we need Kafka", you can walk the why ladder to the real requirement, name the simpler thing, and also name the case where Kafka was right.

You can trace how a change propagates through a connected system — change a price and it reaches the cart, the checkout, order history and refunds — and decide where the price should be captured and who owns that state. You can move between abstraction levels on purpose: "checkout is slow" from the architecture down to the query plan down to the disk, stopping at the highest level that explains the observation. You can order an implementation by dependency, risk, value and learning, defend the order, and say the other valid order and when you would choose it. You can estimate by decomposition and communicate the range instead of a number, and you let architecture emerge from measured requirements: every new component answers the complexity ledger — what problem, what complexity, what if it fails, what bottleneck was measured — or it does not go in. You use an AI assistant as a reviewer and a debugging partner, and you can run the dependency check on yourself: what would be left if it went away tomorrow.

You can take a decision nobody on the team has made before and lay it out across simplicity, performance, reliability, cost, security, time and maintainability without inventing precision the evidence does not have. You can tell a reversible decision from an irreversible one and spend your deliberation accordingly; you can decide with incomplete information and write down what evidence would make you revisit. You can answer "should we build this or buy it?" with the questions that actually decide it — is this our differentiation, what does integrating cost, what does operating it cost, what happens the day the provider is down — and you keep a decision journal so the reasons survive the people. And you can carry the loop into any neighbouring domain: you know which question, asked of a DSA, database, backend, frontend, system design, ML or agentic problem, leads to the lesson that teaches it.

You can start from one sentence you have never built before — a chat app, a URL shortener, a file-upload service, product search, an analytics dashboard, an AI assistant over company documentation — and take it through the whole loop: framing, requirements, constraints, invariants, unknowns, decomposition, the first slice, the failures, and the evidence that would justify each later component. You can say, for each case, which of its requirements is the one that changes the architecture (the chat app's ordering, the shortener's read-heavy hot path, the upload service's large bodies, the assistant's "why is one deterministic workflow insufficient?"), and you can let the architecture grow from a single server and a database only as far as the readings justify, in a system several teams touch. The capstone is the marketplace nobody has built before, and the evidence that you have this level is that you do not need a template to begin.