Problem Solving & Engineering Thinking
How do I solve an engineering problem when I do not yet know the solution — or even where to begin? Not productivity advice, not motivational quotes, not interview riddles, not a template. The skill that connects every other domain.
From “I have no idea how to build this” to “I know the next question I need to answer.”
Every other domain teaches how things work. This one teaches how to figure out which knowledge you need and how to use it: how to turn a vague goal into an explicit problem, find what must be true and what can wait, separate what you know from what you do not, decompose the rest into pieces small enough to test, pick the smallest useful step, run it, observe, and iterate. A learner who finishes this hears “build an e-commerce platform” and no longer thinks which framework? They think: who uses it, what are the core workflows, what data exists, what must never break, what do I not know, what can I test first.
The order is the argument. You cannot decompose what you have not understood; you cannot choose a smallest step without a decomposition; you cannot learn from an experiment you did not predict. Start in the middle — pick a stack, draw an architecture, follow a tutorial — and you get motion that looks like progress and leaves the problem untouched.
This domain sits above all the others
Problem solving does not own any layer. It owns the questions that lead you to each one — and hands off by name rather than re-teaching it.
How things work. Database Engineering teaches how to model and reach data; Backend teaches the request lifecycle; Distributed Systems teaches partial failure; Software Engineering & Design teaches how to shape code that stays safe to change.
How to figure out which knowledge you need and how to use it. That there is a data model to discover, from the sentence “customer places an order containing products”. That “what if the request repeats?” is a question worth asking before the word idempotency has been learned. That “we need Kafka” is a claim with a why underneath it. Which question leads you into which domain.
Flagship experiences
The parts of this domain that are not reading. Every verdict on these pages comes from a real computation — a topological sort actually run, a capacity model actually evaluated, an estimate actually aggregated — never a table pretending to be a result.
Enter "I want to build X". Atlas does not answer. It asks nine questions in order — who uses it, what the core action is, what data exists, what must persist, what is outside, what is the smallest version, what you do not understand, what to build first — and only then generates a roadmap.
Ten stages, from "build an online store" to a measured bottleneck, with feedback only: you write the actors, the data, the first slice and the unknowns before seeing what a strong answer contains. Then the final capstone: a marketplace you have never built.
Expand "Build a chat app" into authentication, conversations, messages, realtime delivery, history and read state. Add, rename, move and mark leaves testable — and see a decomposition that is only Frontend / Backend / Database get flagged for what it hides.
Known, unknown, assumed, need to verify. Paste a question and see whether it is vague, researchable or decisive — and why "how do payments work?" scores differently from "which system is authoritative for whether an order has been paid?".
"We need Kafka." Why? "We need async events." Why? "Checkout should not wait for email." The real requirement, the simpler thing that meets it — and the case where Kafka was the right answer after all.
Create Order through frontend, API, business logic, database and response — independently testable — with what the slice proves and, as prominently, what it does not. Includes the walking skeleton.
Features with dependencies, risk, user value, learning value and effort. A real ordering is computed, the first slice named, and the risky thing to prototype early called out — and the order changes when the weights do.
One server and one database at a hundred daily users. Raise traffic; see the actual bottleneck from a capacity model; add an index, a cache, a replica, a queue — each one justified or not by the readings. At low traffic, nothing you add is justified.
"Frontend says Payment failed." Gather evidence across UI, network, backend, provider and database; watch which causes stay consistent; ask which probe would split the remaining candidates — and press the button that changes something at random.
Decompose "two weeks" into pieces with best, likely and worst. See the aggregated range, what unfamiliar pieces do to the tail, and which percentile the flat number secretly was.
"Checkout is slow" from the architecture level down through the backend, the query, the index, the pages, the OS cache and the SSD — each level linking into the domain that teaches it, and each level saying why you would go deeper or stop.
Goal, actors, core actions, data, constraints, external systems, failures, unknowns, first milestone — the online store filled in beside a blank canvas of your own that persists locally.
Pick Redis, Kafka, PostgreSQL, MongoDB, Kubernetes or a multi-agent system. Atlas asks which problem you are solving. Every leaf names why, the trade-off, the simpler thing to try first and how the recommendation itself fails.
"I want to build Spotify." Requirements are decomposed and mapped to Engineer Atlas domains — streaming to Networking, storage to Cloud, metadata to Database, recommendations to ML, scale to Distributed Systems — as a personal roadmap.
A project, your understanding, your decomposition, your pseudocode, your attempt. Then hints one rung at a time — conceptual direction, relevant abstraction, pseudocode, partial implementation — then review, then the reference.
Current goal, assumptions, unknowns, decisions, experiments, findings, next step — and a decision journal with evidence, alternatives and when to revisit. Persists locally; builds independent reasoning.
Four tracks. Zero guidance, a missing requirement, an over-engineered todo app, an under-engineered payment platform, a research task, a debugging session, an architecture that grows only when a bottleneck appears. Every one carries the trap: the move that looks like progress and is not.
Problem, clarifying questions, assumptions, decomposition, trade-offs, implementation path, failure cases — what each question tests, what a strong answer sounds like, and the green and red flags of a problem solver.
Learning modules
Thirty-three modules, from the first hour with a sentence you do not know how to build to using AI without losing the understanding that lets you own the result.
"I have no idea where to begin." The loop that turns that sentence into a next question, and the technology-first reflex it replaces.
Turning a vague goal into an explicit problem: what is actually being asked, what must be true, what can be ignored for now, and goal against implementation.
Functional and non-functional requirements, the ones that only appear during implementation, and the order: happy path first, failure path second.
Time, users, data, the technologies you know and the ones you must use, budget and legal — the questions whose answers shape the architecture before any diagram.
Properties that must always remain true — an order total is never negative, a payment never happens twice — found from examples and turned into tests.
Making assumptions explicit — one warehouse in V1 — so that when the requirement changes you know why the architecture has to.
An unknown is not a blocker. "I don't understand payments" becomes a specific question, a tiny experiment, and a return to the main problem.
The deepest module. Breaking a store into catalog, cart, checkout, orders and payments — then checkout into its steps — and telling a good decomposition from a technical one.
Removing implementation assumptions to find the fundamental requirement. "We need Redis" → why? → repeated reads are slow. Now evaluate options.
Changes propagate through connected components. Change a price and it reaches cart, checkout, order history and refunds — so where should price be captured, and who owns it?
From "user clicks Buy" to the SSD in seven levels. Solve at the highest useful level first; zoom in when necessary; know that the framework is syntax over the mechanism.
Product page through API through database to a visible product, instead of a week of database then a week of backend. A slice is independently testable; a skeleton proves the pieces connect.
The smallest version that proves the core idea — products, cart, order, payment — and the line between what can be simplified and what cannot be ignored.
From "customer places an order containing products" to Customer, Order, OrderItem, Product. Entities from plain English, what must persist, and snapshots against references.
Which components must communicate, where the boundary of our system is, and which external dependency has to answer before the user can be told anything.
What changes over time — order status, cart contents, inventory, payment status — and the state machines that fall out of asking.
After the happy path works: what if payment fails, the request repeats, the database is down, the browser closes. Failure injected on purpose.
Inputs, outputs, state, branches and failures written down before any framework syntax — pseudocode as a thinking tool, not a coding step.
When the abstract problem is hard, construct a concrete case: three units, Alice buys two, Bob buys two at the same time. Edge cases, counterexamples and thought experiments.
A prototype answers a question. Spikes, experiment design, predicting before running, and the feedback loop that beats three weeks of design.
Symptom, observation, hypothesis, experiment, evidence — and the anti-pattern of changing random things. Reproduction, minimal reproduction, binary search, logs as evidence.
An unfamiliar codebase: entry point, follow the data, find the state, find the side effects, understand the boundary. Not "read every file".
Goal, relevant concept, minimal section, try the example, modify it, apply. Documentation before tutorials, tutorial dependency, and search as a skill.
"What is Redis?" Do not read everything. What problem does it solve, what does it guarantee, what is the simplest example, how does it fail, what are the alternatives.
From "how do payments work?" to "which system should be authoritative for whether an order has been paid?" — questions that reduce uncertainty, and how to ask people.
Simplicity, performance, reliability, cost, security, time, maintainability. Matrices without fake precision, reversible against irreversible, deciding under uncertainty.
Estimation as decomposition, uncertainty communicated instead of hidden, the riskiest unknown first, and what to build first.
Is this core differentiation, can a provider solve it, what does integration cost, what does operating it cost, what happens when the provider fails.
Implementation order, dependency-first and value-first, architecture that emerges from requirements, and the complexity ledger every new component must answer.
Your understanding, your decomposition, your pseudocode, your attempt — then hints one rung at a time. Explain it back, build from memory, find where you hesitate.
Think, form the question, use the tool, understand the answer, verify. AI as reviewer and debugging partner, the dependency check, and what you still own.
How the loop enters DSA, databases, backend, frontend, system design, ML and agentic engineering — the same questions, different next lessons.
An online store, a chat app, a URL shortener, file upload, search, an analytics dashboard, an AI assistant — each started from one sentence, each grown only as far as its requirements justify.
Reference
For when you already know roughly what you are looking for.
Beginner, intermediate, advanced and expert tracks, each unlocking a kind of problem you can now face.
The searchable index: how being stuck sounds, and the move that gets you unstuck.
The pairs people confuse — goal and implementation, assumption and requirement, MVP and prototype, spike and prototype, vertical and horizontal, reversible and irreversible — with the confusion named.
Don't delegate understanding
The Engineer Atlas principle, as a working practice rather than a slogan.
Use documentation, search, AI, books, examples, libraries and frameworks. They accelerate understanding. The line is that they must not replace it — because when the generated checkout fails at two in the morning, the person who has to explain why is you. The manifesto states the principle; Build Without AI and the AI module practise it.