Coding Skills That Matter in the Age of AI

A program runs its commands in order, and a later command can use what earlier ones produced.

A program executes its commands from top to bottom, and each command finishes before the next one starts. Because a later command can read a value an earlier one stored, changing the order of the commands can change the result.

A variable holds a value.

A variable is a name bound to a value, so writing the name anywhere in the program stands in for that value. This gives a single place to keep a piece of data and refer to it again without repeating the data itself.

A variable’s value can be updated, including by using its current value. It holds the value most recently assigned to it.

Assigning to a variable replaces whatever it held, and the new value can be computed from its current one. At any moment the variable holds only its most recent assignment, so earlier values are gone unless saved elsewhere.

Expressions use variables, operators, and numbers to compute new values. The result of an expression can be stored in a variable.

An expression combines variables, operators, and literal numbers, and the program evaluates it down to a single value. That value can be stored in a variable, so a computed result becomes available to later commands.

A value has a type, like a number or text, and its type decides what operations apply to it.

Every value carries a type, such as number or text, and the type determines which operations are valid on it. Adding two numbers means arithmetic, while the same operator on two pieces of text joins them, so the type changes what an operation does.

A program can take in a value from outside and store it in a variable.

A program can read a value supplied from outside, such as typed input or a file, and bind it to a variable. This lets the same code operate on different data each time it runs, instead of only the values written into it.

An incorrect value is traced back to the command that produced it.

Following an incorrect value backward through the commands leads to the assignment that last set it. Inspecting that command’s inputs and operation reveals whether a bad input or a faulty step produced the value.

An if statement runs a block only when its condition is true, and skips it otherwise.

An if statement evaluates its condition once, then runs the guarded block only if that condition is true. When the condition is false the block is skipped entirely, so the code inside runs conditionally rather than always.

An if-else statement picks one of two blocks: one when the condition is true, the other when it is false.

An if-else statement evaluates its condition once and runs exactly one of two blocks depending on the outcome. One block covers the true case and the other covers the false case, so one of them always runs.

A conditional statement can have more than two branches, checking each condition in turn and running the first that is true.

A conditional statement can list several conditions, and the program tests them from top to bottom. The first condition that is true selects its branch, and the remaining conditions go unchecked.

A conditional statement runs exactly one of its branches, so a case handled by an earlier branch never falls through to a later one.

A conditional statement selects a single branch and skips the rest once one condition matches. An input caught by an earlier branch is therefore never handled again by a later branch, even when it would also satisfy that later condition.

A conditional statement should cover every case its input can fall into.

A conditional statement’s branches should together account for every value its input might take, often with a final catch-all branch. An input that matches no branch slips through with nothing done, a common source of missed cases.

When a conditional statement takes the incorrect branch, checking its condition on that input shows which test is off.

Evaluating each condition by hand on the specific input reveals which one gave an unexpected true or false. That mismatch points to the comparison or Boolean logic that steered the input into the incorrect branch.

A condition is either true or false.

A condition evaluates to one of exactly two Boolean values, true or false, with no third option. A program branches on that outcome, so every test a program makes reduces to true or false.

A condition compares values or tests a property of one, like whether two are equal or a number is positive.

A condition is formed by comparing two values or testing a property of a single value, and it yields true or false. Comparisons like equal, less than, or greater than, along with property tests like whether a number is positive, are the basic building blocks of conditions.

Conditions combine with and, or, and not to form bigger conditions.

Smaller conditions combine with and, or, and not into a larger condition that is still just true or false. And requires both parts, or requires at least one, and not flips a condition’s value, so complex tests are built from simple ones.

A condition can be stored in a variable and used later.

The true-or-false result of a condition can be assigned to a Boolean variable and referenced later by name. This names a test once and reuses its outcome, instead of writing the same comparison in several places.

A condition can decide what a program does.

A condition placed in an if statement or loop controls which commands run and how often. By selecting between paths based on true or false, a single program can behave differently on different inputs.

A combined condition can be rewritten in alternative, equivalent forms.

A combined condition can be rephrased into a different but logically equivalent condition that is true for exactly the same inputs. Rewrites like turning not (a and b) into (not a) or (not b) can make a condition simpler to read without changing its behavior.

When a combined condition behaves incorrectly, checking each part on its own isolates the mistake.

Evaluating each sub-condition separately on the failing input shows which part returned an unexpected true or false. Comparing those parts against how and, or, and not combine them narrows the fault to a single comparison or connective.

A loop repeats a block of commands instead of writing it out each time.

A loop states a block of commands once and runs it repeatedly, rather than copying the same commands many times. This keeps the program short and means a change to the repeated work is made in exactly one place.

A loop can repeat a set number of times.

A count-controlled loop repeats its block a fixed number of times, tracked by a counter that advances each iteration. This suits work whose length is known in advance, such as processing a set quantity of items.

A while loop repeats as long as a condition stays true, and never stops if that condition never becomes false.

A while loop rechecks its condition before every iteration and runs the block only while that condition is true. If nothing inside the loop ever makes the condition false, the loop repeats forever, so the body must move the state toward stopping.

A loop can go through each item in a list or other collection, one per iteration.

A for-each loop visits every item in a collection in turn, binding the current item to a variable for one iteration. This covers the whole collection without tracking positions by hand, so no item is skipped or counted twice.

A loop can be stopped early according to some condition.

A while loop runs only as long as its condition stays true, so it stops the moment that condition becomes false. A loop can also be cut short with a break the instant its goal is reached, so the remaining iterations never run.

A result can be built up across iterations, like a running total, in a variable that lives outside the loop.

A variable declared before the loop persists across iterations, and each iteration updates it toward the final result. Because it lives outside the loop, its value survives from one iteration to the next instead of resetting each time.

The program’s state can change each iteration of a loop.

Each iteration of a loop can modify variables, so the values the block works with differ from one iteration to the next. Tracking how the state evolves across iterations is essential to predicting what a loop finally produces.

An assumption that is true at the start of an iteration should still be true at its end, so each iteration sets up the next.

A property that holds at the start of an iteration should be reestablished by the end, so the next iteration begins on the same footing. When every iteration preserves this assumption, the loop’s final result can be trusted.

When a loop gives an incorrect result, checking the state on each iteration shows where it goes off.

Recording the loop’s variables at each iteration reveals the first iteration where a value departs from what was expected. That iteration localizes the fault to the update or condition running at that point.

A loop can be nested inside another loop, and the inner loop runs in full on each iteration of the outer.

A loop placed inside another runs its entire cycle once for every single iteration of the outer loop. The total number of inner iterations is therefore the outer count multiplied by the inner count.

A conditional statement can be nested inside another conditional statement.

A conditional statement can appear inside a branch of another, so the inner test is reached only when the outer condition already selected that branch. This expresses a decision that depends on a prior decision.

A nested conditional statement is sometimes better rewritten as a single conditional statement with multiple branches.

Nested conditional statements that test related quantities can often be flattened into one conditional statement with several branches. The flatter form lays the mutually exclusive cases side by side, usually easier to read than conditions buried inside conditions.

Deep nesting gets hard to follow, so naming a condition or pulling an inner part out keeps it clear.

As conditional statements and loops nest several layers deep, the logic gets hard to trace because each line depends on many enclosing tests. Storing a condition in a well-named Boolean variable, or moving an inner block into its own function, flattens the structure and restores clarity.

A fault in nested logic is isolated by checking the inner part on a single iteration of the outer.

Fixing the outer loop or condition to one specific case narrows attention to just the inner logic running under it. Inspecting the inner part in that single setting separates an inner mistake from one in how the layers interact.

A list stores items in some order, each accessed by its position.

A list keeps its items in a definite order, and each item sits at a numbered position. Any item is accessed directly by giving its position, so both order and location are preserved.

A dictionary is a collection of named values, where each name (a key) maps to one value.

A dictionary pairs each key with a value, and looking up a key returns the value bound to it. Keys stand in for positions, so a value is found by a meaningful name rather than a numeric index.

A loop can go through every item in a list, or every name in a dictionary.

A loop can iterate over a list to visit each item in order, or over a dictionary to visit each key. This applies the same block of work to every element of a collection, whatever its size.

Whether to use a list or a dictionary depends on the use case. Lists are better for keeping items in a definite order, and dictionaries are better for accessing values by name.

A list maintains a definite order and addresses items by numeric position, while a dictionary addresses values by a meaningful key with no inherent order. Choosing between them comes down to whether order or lookup-by-name matters more for the data.

Lists and dictionaries can grow, shrink, or be modified.

Lists and dictionaries are mutable, so items can be added, removed, or replaced after the collection is created. This lets a single collection track data that changes over a program’s run, rather than being fixed at its initial contents.

A value accessed or updated incorrectly is traced to the position or name used to access it.

An access that reads or writes the incorrect element is traced back to the index or key supplied for it. Checking that position or name against the collection’s contents reveals an off-by-one index or a mistyped key.

A function is a named piece of a program that takes inputs, called parameters, and produces an output.

Parameters are named slots the caller fills with values, the body works with those values, and an output comes back under the function’s name. Naming and packaging a computation this way means it can be invoked by name from anywhere rather than rewritten each place it is needed.

A function should do one clear job, and its name should say what that job is.

When a function is limited to a single responsibility, its behavior can be understood from its name alone and tested without untangling unrelated work. A name that describes that one job lets a reader predict what a call does without reading the body.

Calling a function runs its body on its inputs, and the result is returned in place of the call.

A call passes the given inputs into the function, the body runs to completion, and the value returned takes the place of the call. The surrounding code sees only that returned value, not the steps that produced it.

A function can return early, as soon as it has its answer, without running the rest of its body. A function with no value to return runs for its effect instead.

A return hands control back to the caller the instant it executes, so any statements after it in the body never run. Some functions return no value at all and are called only to change something or produce output, their work being the effect rather than a result.

A function’s contract is the promise it makes: for the inputs it expects, what it returns or does.

A contract states which inputs a function accepts and what it guarantees in return, whether a value or an effect, without describing the internal steps. Agreeing on this promise means callers and the function can be written and checked independently.

A variable made inside a function is local: it exists only while the function runs.

A local variable is created when the function starts running and discarded when it returns, so no other part of the program can see or change it. This isolation means the same name can be reused across functions without their values colliding.

A function that only uses its inputs and changes nothing outside itself is easier to reuse and to reason about.

A function that draws only on its parameters and leaves everything outside untouched produces the same output for the same input every time. That predictability means it can be dropped into a new setting without dragging hidden dependencies along.

Once a function exists, it can be called wherever its job comes up instead of repeating its code.

A single definition can be invoked from many places, so the logic lives in one spot rather than being copied. Correcting or improving that one definition updates every use at once.

A function is checked by running it on an input and comparing what it returns to what its contract says it should be.

Running the function on a chosen input yields an actual result, which is then held up against the result its contract promises for that input. A mismatch signals a defect, and a match builds confidence that the function honors its promise.

Turning a fixed value inside a function into a parameter lets the same function handle a whole family of cases instead of one.

Replacing a hard-coded constant with a parameter moves that choice to the caller, so one definition covers every value the parameter can take. The function grows from solving a single instance to solving an entire class of related problems.

A function can take several inputs. The order the arguments are passed in decides which parameter each one fills.

Each argument in a call is matched to a parameter by its position, the first argument filling the first parameter and so on. Passing arguments in the incorrect order sends values to the wrong parameters even when the call is otherwise valid.

A function can hand back several values at once, bundled together.

Rather than returning a single value, a function can package multiple results together and return them as one bundle the caller unpacks. This keeps related outputs that belong together from requiring separate calls.

A good set of inputs represents the whole job with the fewest, clearest parameters. Fewer, clearer parameters make a function easier to use correctly.

A well-chosen parameter list captures everything the job needs and nothing it does not, with each parameter carrying a distinct, understandable role. When there are fewer parameters to supply and each is clearly named, callers are less likely to mix them up or leave one out.

A precondition is what has to be true of the inputs for a function to work. Meeting it is the caller’s job.

A precondition names the assumption a function relies on about its inputs, such as a list being non-empty or a number being positive. The function is free to behave unpredictably when the assumption is broken, so satisfying it falls to the caller before the call is made.

One function depends on another when it uses that function’s result or behavior.

A dependency forms when one function calls another and relies on the value or effect it produces to do its own work. The calling function’s correctness then rests partly on the called function keeping its promise.

Reading the chain of calls shows how a program’s functions fit together.

Following which function calls which, from an entry point down through the functions it invokes, traces the structure of the program. Seeing that chain reveals how work is delegated and where a given result originates.

A change to one function can affect every function that relies on it.

When a function’s behavior or output changes, each function that calls it may see different results and behave differently in turn. A single edit can therefore ripple outward to callers that were never touched directly.

A helper function does a small, repeated part of the work so the functions that call it stay clear.

A helper captures a small piece of logic that several functions need, so each caller invokes the helper instead of spelling out that logic inline. The calling functions stay focused on their main task while the shared detail lives in one place.

A bug that shows up only when two functions run together usually means they disagree about something they share, like a format or an assumption.

When each function works alone but they fail in combination, the fault often lies in a shared expectation one produces and the other consumes, such as a date format or a unit. The mismatch surfaces only at the point where one function’s output meets the other’s input.

Two functions are composed by feeding the output of one straight into the other.

Composition passes the result returned by the first function directly as the input to the second, chaining them into a single combined operation. The two steps run in sequence with the intermediate value flowing between them untouched.

A pipeline chains several functions in a row, each one’s output feeding the next.

A pipeline lines up multiple functions so each stage transforms the value and passes it to the next, from raw input at one end to finished result at the other. Data moves through the stages in order, each doing one transformation.

The order functions are composed in changes the result, so running A then B need not match B then A.

Because each function transforms the value it receives, swapping which runs first changes what the second one operates on and thus the final result. Only in special cases do the two orderings happen to agree.

The same function can be applied across many inputs by calling it repeatedly, often inside a loop.

Applying one function to each item of a collection, typically by calling it once per item inside a loop, transforms the whole collection using logic written a single time. Each call is independent and handles just its own input.

When a composed result is incorrect, checking the value handed off at each step finds the first one that is off.

Inspecting the intermediate value produced at each stage of a composition, in order, reveals the earliest stage whose output is not as intended. That first bad handoff localizes the defect to a single function rather than the whole chain.

If each function is correct on its own but the composition is still incorrect, the order they run in is the likely cause.

When every function passes its own tests yet the combined result is not as intended, the fault often lies in how they are arranged rather than inside any one of them. Reordering the stages so each operates on the value it expects can resolve the mismatch.

A test runs a function on a chosen input and checks the result against what is expected.

A test names a specific input alongside the result the function should return for it, then runs the function and compares the two. Agreement passes the test, and a difference flags a defect at that input.

Testing the typical, expected inputs, the happy path, confirms a function works in the normal case.

Happy-path testing exercises the ordinary inputs a function is built to handle, confirming it behaves correctly under normal conditions. Passing these establishes the baseline before unusual inputs are considered.

Testing the edge cases, like an empty list, a zero, or the largest input, catches bugs that ordinary inputs slip past.

Edge-case testing probes the boundaries of what a function accepts, such as an empty collection, a zero, or the largest allowed value, where off-by-one and division errors tend to hide. These inputs expose faults that typical values never trigger.

Testing the special cases, the odd inputs a function has to treat differently, makes sure none are missed.

Special-case testing covers inputs that fall under a rule of their own and need distinct handling, separate from the general logic. Checking each one confirms the function branches correctly instead of quietly mishandling it.

A failing test pins a bug to a specific input and expected output, so it can be reproduced and fixed.

A failing test records the exact input and the result that was expected, giving a precise recipe to trigger the bug on demand. That reproducibility means the defect can be studied, corrected, and confirmed fixed against the same case.

When a function returns the incorrect result for a given input, walking through its steps on that input finds where it first goes wrong.

Following the function line by line with the failing input, and checking the values it computes along the way, locates the earliest point where a value departs from what it should be. That first divergence marks the statement responsible for the incorrect result.

A class is a template for a kind of object: it says what data (attributes) and what operations (methods) those objects have.

A class defines, once, the attributes every object of its kind will hold and the methods they can perform. Individual objects are then produced from that single template, each following the same structure.

An object is one instance of a class, with its own values for the attributes the class defines.

An object is a single concrete item built from a class, holding its own copy of the attribute values the class describes. Many objects can share one class yet differ because each stores its own values.

A method is a function that belongs to an object. It can take inputs and return outputs, and it can read and change the object’s own data.

A method is a function attached to an object that, beyond taking inputs and returning outputs like any function, has direct access to that object’s attributes. It can both read the object’s current values and modify them as part of its work.

An object keeps its state between method calls, so each call can build on what earlier ones left behind.

An object’s attributes persist from one method call to the next rather than resetting, so the object remembers the effects of past calls. Each new call sees the accumulated state and can extend it.

A helper method does an internal piece of work that the object’s other methods reuse.

A helper method holds a small piece of logic several of an object’s other methods need, kept internal to the object rather than exposed for outside use. Those methods call the helper instead of repeating the logic, and the shared step lives in one place.

Objects can work together: one object’s method can use another object to do part of the job.

A method on one object can call methods on another object, delegating a portion of its task to that collaborator. Splitting responsibilities across objects means each handles the part it is suited for.

The object-level version of a function contract is planning a class: naming its data and operations before writing it.

Planning a class means deciding, in advance, which attributes it will hold and which methods it will offer, before any of the code is written. Settling this outline first gives the same clarity a function contract gives, but for a whole object.

An object that misbehaves is debugged by checking its attributes after each method call to see which one left them incorrect.

Inspecting an object’s stored attributes after each method call, in sequence, reveals the call after which a value first became not as intended. That call is the one that corrupted the object’s state.

A module groups related functions and data together behind one boundary.

A module gathers functions and data that serve a common purpose into a single unit with a defined boundary. Related code stays together, and the rest of the program interacts with the group as a whole rather than its scattered parts.

An interface is the set of operations a module offers. It says what can be done, not how.

An interface lists the operations a module makes available to callers, describing what each does without exposing the code behind it. Callers work from this list alone, unaware of the implementation.

Code that relies only on a module’s interface keeps working even when the details behind it change.

When calling code depends solely on the operations an interface promises, the module’s internals can be rewritten without breaking that code. As long as the interface keeps its promises, changes behind it stay invisible to callers.

Abstraction means using something by what it does, without tracking how it works. Large programs are only manageable because of it.

Abstraction lets a part of a program be used through what it accomplishes while its inner workings stay out of view. Working at that level keeps the amount a programmer must hold in mind small enough to handle even as a program grows large.

Refactoring is reorganizing code into clearer functions or modules without changing what it does.

Refactoring restructures existing code, splitting or regrouping it into cleaner functions or modules, while preserving its observable behavior. The program does the same thing before and after, but the code becomes easier to read and change.

A bug that spans modules is narrowed down by checking each module against its interface, one at a time.

Testing each module in isolation against what its interface promises, one module at a time, reveals which one fails to keep its promise. That check separates the module at fault from the ones merely passing bad data along.

A problem is recursive when solving it means solving a smaller version of the same problem.

When a problem is recursive, the work of solving it reappears inside itself on fewer inputs, so an answer to a smaller instance feeds directly into the answer for the full one. Spotting this shape means a single method can handle inputs of any size, rather than needing a separate strategy for each size.

Some data structures can be seen as being built from smaller versions of itself. For example, a tree is made of smaller trees.

A data structure of this kind is defined in terms of itself, where each part has the same form as the whole but holds less. Seeing a structure this way means a method that handles the whole can be applied unchanged to each smaller part.

A self-similar shape, in a problem or in its data, is the cue to solve it by recursion.

When the parts of a problem or its data repeat the form of the whole on smaller inputs, that repetition points toward a recursive solution assembled from answers on those smaller parts. Noticing self-similarity early saves the effort of inventing a fresh strategy for each size of input.

A recursive solution assumes a smaller version of the problem is already solved, and builds its answer from that.

A recursive solution does not solve the whole problem in one go, but trusts that the same method already works on a smaller input and only combines that smaller answer into the full one. This means writing a recursive method that calls itself on smaller inputs and assumes those calls have returned the correct answer.

The base case is the smallest case, small enough to answer directly without recurring.

The base case is an input small enough that its answer is known outright, with no further breaking-down needed. Without one, a recursive method would keep calling itself endlessly, so the base case is where the descent into smaller problems stops.

The recursive step reduces the problem toward the base case, then builds the full answer from the smaller problem’s answer.

The recursive step turns a larger input into one or more strictly smaller inputs, solves those by calling the same method, and combines what comes back into the answer for the original. Each application moves the input closer to the base case, so the chain of calls is guaranteed to end.

A recursion can have more than one base case, when the smallest inputs come in different forms.

When the smallest inputs are not all alike, each distinct smallest form needs its own directly-given answer, so a recursion may stop at several different base cases. Handling every smallest form explicitly keeps the recursive step from ever being handed an input it cannot break down.

The recursive step can depend on the input, choosing which smaller problem to solve, or how far to reduce.

The recursive step can inspect its input and, based on what it finds, decide which smaller instance to recurse on or how far to shrink the input. With this, one recursive method follows different paths through the data instead of always reducing in the same fixed way.

A recursive step can make more than one recursive call, combining their answers into the final result.

A single recursive step can break its input into several smaller parts, solve each with its own recursive call, and merge those answers into one. This branching matches data or problems that split into multiple independent pieces rather than a single smaller remainder.

A recursive program that gives the wrong answer is checked at its base case and its recursive step separately, since either can be at fault.

A recursive program has two parts that can independently be at fault, the base case that answers the smallest input and the recursive step that combines smaller answers. Testing each in isolation, the base case on a smallest input and the step under the assumption that its smaller calls are correct, narrows down where an incorrect result comes from.

Tracing a recursive program means following each call down until it reaches the base case, then back up as each call returns its answer to the one that made it.

Tracing a recursive program follows the outward calls as they descend to smaller inputs, then follows the returns as each finished call hands its answer back to the call that made it. Working through both directions shows exactly how partial answers combine, making the program’s behavior concrete rather than assumed.

The call stack records the order in which recursive function calls are made.

The call stack holds the chain of function calls still waiting to finish, with the most recent call on top and the original call at the bottom. Because each recursive call is added before its smaller calls and removed only once they return, the stack captures how deep the recursion has gone at any moment.

A recursive program halts only if every possible path reaches a base case in a finite number of steps. A recursive step that never moves toward the base case runs forever.

For a recursive program to finish, every sequence of recursive calls has to shrink its input until it lands on a base case after finitely many steps. If some path never reduces toward a base case, the calls continue without end and the program never returns.

A program stuck in infinite recursion is debugged by checking that its recursive steps reach the base case.

Infinite recursion means some recursive step keeps producing inputs that never satisfy a base case, so debugging traces the sequence of inputs to find where the reduction stops. Confirming that every recursive call moves strictly toward a base case pinpoints the step that fails to shrink its input.

Induction shows that a statement holds for every case by showing it holds for the smallest case, and that whenever it holds for one case it holds for the next.

An inductive proof establishes a claim for the smallest case directly, then shows that assuming the claim for an arbitrary case forces it for the next larger one. Together these two parts cover every case at once, without checking each of the infinitely many cases separately.

A recursive program is proved correct by induction: its base case is right, and each recursive step is right whenever the smaller answer it builds on is right.

Proving a recursive program correct by induction checks that the base case returns the right answer, then checks that the recursive step returns the right answer under the assumption that its smaller calls already did. Since every input reduces to the base case through such steps, these two checks together guarantee correctness on all inputs.

A recurrence relation expresses a recursive quantity, an answer or a running time, in terms of the same quantity on smaller inputs.

A recurrence relation writes a quantity for an input as a formula involving that same quantity on smaller inputs, mirroring how a recursive method calls itself. Expressing an answer or a running time this way turns a recursive process into an equation that can be solved or bounded.

A recursive program can be rewritten as an iterative loop, and both are justified by induction.

The same computation can be arranged either as a recursive method that calls itself or as a loop that repeats over the same sequence of smaller cases. Whichever form is used, induction justifies it, over the depth of recursion in the one case and over the number of iterations in the other.

A problem is understood by pinning down its inputs, its expected output, and the constraints they need to satisfy.

Naming what data comes in, what result is demanded of it, and the limits both must respect fixes the target before any method is attempted. An unstated constraint or a vague notion of the output can leave a working solution answering the wrong problem.

A problem in general is different from any one instance of it. A solution needs to solve every instance of a problem.

An instance is one filled-in case, while the problem is the whole family of cases that share its form. A method that answers only the case in front of it, without covering the rest of the family, is not a solution to the problem.

Working a few small instances of a problem by hand can build intuition for what the solution to the problem needs to do.

Carrying out the task on tiny inputs where every step is visible exposes the operations a general method will need to repeat. Patterns and boundary behaviors surface on small cases long before they can be seen in finished code.

Solving an easy special case can reveal the structure of the general solution to a problem.

A restricted version strips away complications so the core idea stands out, and that idea can then be extended toward the full problem. Often the special case turns out to be the general solution with some parameter fixed.

A solution is correct when there is a reason it gives the right output on every allowed input.

Correctness is not passing a handful of sample runs but having an argument that covers the entire space of allowed inputs. Without a reason that spans every allowed input, an untested input can still produce an incorrect result.

A precondition states what is assumed true before a step runs, and a postcondition states what is guaranteed true after.

A precondition records the situation a step relies on in order to work, and a postcondition records what the step leaves guaranteed once it has run. Naming both makes explicit what each step demands going in and delivers coming out.

One way to prove correctness is to show that each step’s postcondition follows from its precondition, so the steps chain together to guarantee the desired final output.

When the guarantee one step leaves behind is exactly the assumption the next step needs, the guarantees link together end to end. The final postcondition then follows from the first precondition with no gap left unaccounted for.

A counterexample is a single input on which a proposed solution fails. One counterexample is enough to show the proposed solution is not correct.

Correctness is a claim about every allowed input, so a single input that produces a wrong answer breaks the claim outright. Any number of inputs that happen to work cannot rescue a solution that fails on even one.

Searching for a counterexample is a fast way to test a proposed solution before trusting it.

Deliberately hunting for an input that breaks a proposed method, especially an extreme or unusual one, exposes flaws far faster than constructing a full proof. Finding one bad input settles the matter at once, and finding none after real effort builds confidence cheaply.

Proving that a solution is correct includes proving that it terminates on every input.

A method that computes the right answer only once it finishes is not correct if some input sends it into an endless loop. A proof of correctness therefore needs to show the process reaches an end on every allowed input, not only that its result would be right if it stopped.

An invariant is a condition that stays true every time a process returns to the same point, such as the start of each iteration of a loop.

An invariant pins down something that stays true each time execution passes a chosen point, no matter how much the surrounding values have shifted between visits. A fact that holds steady amid changing state gives a fixed handle for reasoning about the process.

A loop invariant is a statement that holds at the start of every iteration. If it holds before the loop starts and each iteration keeps it true, it still holds once the loop ends.

Establishing the statement before the first iteration and showing that each iteration preserves it means the statement survives all the way to the moment the loop exits. Combined with the reason the loop stopped, it then describes the loop’s result.

A loop invariant can be used to prove that an algorithm with a loop is correct.

Pairing the invariant that survives the loop with the condition that caused the loop to exit yields a precise statement about the state when the loop finishes. That combined statement is frequently the exact correctness guarantee being sought.

Related problems share structure, so a solution to one can be a starting point for the others.

When two problems rest on the same underlying form, a method that solves one already handles the parts they hold in common. Adapting that existing method is usually quicker than designing a fresh one from nothing.

Changing a problem’s constraints often forces the solution to change with them.

A solution is shaped to the constraints it was designed under, so loosening or tightening those constraints can void the assumptions it relied on. A method that was correct before may need genuine rework rather than simple reuse.

Breaking a problem into the separate cases its input can fall into lets each case be handled on its own.

Partitioning the inputs into distinct kinds lets each kind be solved with the approach that fits it, instead of one tangled method straining to cover them all. Handling the cases separately keeps each piece simpler and easier to get right.

A new problem can be solved by transforming it into one whose solution is already known.

Reshaping a problem’s inputs into the inputs of an already-solved problem, then translating that problem’s answer back, reuses its solution whole. As long as a reliable translation exists in both directions, no new algorithm has to be invented.

Recognizing a problem as a disguised version of a familiar one is often most of the work.

Much of the difficulty lies in seeing past the surface details to the familiar problem underneath, after which a known solution simply applies. The insight that reveals the disguise, rather than the coding that follows, is usually the hard part.

Mapping a problem onto a given structure, like a graph or a set, makes the tools built for that structure available when designing the solution.

Casting a problem’s objects and their relationships as the elements of a known structure brings that structure’s ready-made operations and algorithms within reach. The design can then draw on established tools instead of building them from scratch.

The cost of an algorithm is estimated by counting the basic operations it runs, like comparisons or swaps.

Rather than measuring an algorithm as a whole, one kind of step it repeats is chosen as the unit of work and tallied over a full run. That tally gives a concrete number to set against other algorithms solving the same problem.

Operations are counted rather than the program timed directly, because timing depends on the speed of the computer while an operation count does not.

A stopwatch reading blends the algorithm together with the machine it ran on, its programming language, and whatever else the processor was busy with. Counting the operations themselves strips those away, leaving a measure that describes the algorithm alone and stays the same across every computer.

When several kinds of operations run, an algorithm’s cost is dominated by whichever kind runs the most, so that is the one worth counting.

When an algorithm mixes several kinds of steps, they usually run different numbers of times, and as the input grows the most frequent kind outpaces all the others. Tracking only that dominant kind captures how the total cost behaves without the bookkeeping of tallying every operation separately.

The same algorithm can do different amounts of work on different inputs of the same size.

Two inputs can share a size yet be arranged so differently that an algorithm halts early on one and grinds through the whole of the other. Because of this, a single number rarely captures an algorithm’s cost, and its behavior has to be described across the range of inputs it might receive.

The best case is the least work an algorithm does on any input of a given size, the worst case is the most, and the average case is the typical amount.

Fixing the input size still leaves many possible inputs, and an algorithm can race through some while laboring over others. Reporting the least, the most, and the typical amount of work over those inputs gives three separate answers to how expensive the algorithm is, each suited to a different question.

Worst-case cost is used most often, since it guarantees the maximum cost of an algorithm regardless of input.

The worst case fixes an upper limit that no input of a given size can exceed, however unfavorably it is arranged. Planning depends on that guarantee, since a system built to survive its heaviest case will handle every lighter one too.

Amortized cost spreads the price of an occasional expensive operation over the many cheap ones around it.

Some operations run cheaply almost every time but occasionally trigger one costly step, and charging that rare step’s full price to every operation would overstate the real expense. Averaging the total cost of a long run of operations across all of them gives a fairer per-operation figure.

What matters is not the exact operation count an algorithm requires, but how the cost of running the algorithm grows as the size of its input grows.

The precise tally at one input size says little on its own, what counts is the trend as the input gets larger and larger. Two algorithms with similar counts on small inputs can diverge enormously at scale, so the shape of that growth decides which one stays usable.

An algorithm whose cost grows slowly with respect to input size is usable at scale, while a fast-growing algorithm becomes impractical.

When cost climbs gently with input size, even an enormous input keeps the work within reach, but when cost climbs steeply, a modest increase in input can push the work past what any machine can finish in reasonable time. Which category an algorithm falls into decides whether it survives contact with real, large datasets.

An algorithm’s cost can depend on the shape of the input data, in addition to its size.

Beyond how many elements an input holds, the way those elements are arranged or related can raise or lower the work an algorithm does. Two inputs of identical size can therefore cost very differently depending on whether the data is already ordered, evenly distributed, or clustered together.

Big-O notation can express how an algorithm’s cost grows with respect to its input (its growth rate), while ignoring constant factors and lower-order terms.

Big-O notation keeps only the fastest-growing term in a cost formula and discards constant multipliers and smaller terms that fade at scale. What remains is the growth rate, expressed compactly so two algorithms can be compared by how steeply their cost climbs rather than by exact step counts.

An algorithm’s Big-O cost can be read from its structure. For example, the cost of a loop is the number of iterations times the cost of the statements inside.

The growth rate often follows directly from how loops and calls are nested, with each loop multiplying its iteration count by the cost of the work inside it. Reading the structure this way yields the Big-O cost by inspection, without ever running the algorithm.

The most common growth rates are constant, logarithmic, linear, quadratic, and exponential. They scale very differently as the input grows.

A small family of growth shapes covers most algorithms, running from constant cost that never changes, through logarithmic, linear, and quadratic, up to exponential cost that explodes. Placing an algorithm into one of these categories predicts how it will behave long before the input gets large.

Logarithmic cost stays cheap even for enormous inputs.

When each step discards a constant fraction of what remains, often half, the number of steps grows by only one every time the input doubles. That gentle climb keeps the total work tiny even as the input reaches into the billions.

Exponential cost becomes impractical even for fairly small inputs.

When each additional input element multiplies the total work, often doubling it, the cost races past what any computer can finish after only a few dozen elements. Algorithms with this growth are usable only on the smallest inputs, or once reworked into a cheaper approach.

A single line of code can hide a non-constant cost: looking up a value is quick in a set but scans the whole of a list, and slicing a list copies every element in the slice.

An operation that reads as a single step can loop internally, its true cost set by the data structure it touches and how much of that structure is involved. Treating such a line as one cheap step throws off a cost analysis, so what actually happens beneath it has to be accounted for.

An algorithm’s memory cost is measured the same way as its time cost, by how it grows with input size.

The extra storage an algorithm claims is tracked as a function of input size and summarized by its growth rate, exactly as running time is. This matters because memory can run out before time does, making space the deciding constraint on whether an algorithm is usable at all.

There are often multiple solutions to a problem, presenting a tradeoff between time and memory costs. Spending more memory can buy less time, and spending less memory can cost more time.

Storing results that would otherwise be recomputed trades memory away to save time, while recomputing on demand trades time away to save memory. Which direction to lean depends on which resource is scarce, so the same problem can have a fast-and-large solution and a slow-and-lean one.

The Word RAM model of computation pictures memory as a long row of numbered slots. Every value a program uses lives in one or more of those slots.

The model gives every slot its own number, called an address, and treats reading or writing any one slot as a single basic step no matter where it sits. With this picture fixed, the cost of a data structure can be reasoned about by counting how many slots its operations touch.

How data is laid out across memory decides how fast it can be accessed and changed.

The arrangement of values across slots decides whether an item can be found by a direct calculation or only by following a chain of steps from somewhere else. Because access and modification costs both flow from that arrangement, choosing a layout sets the speed of every operation before any logic is written.

Accessing a memory slot by its number takes constant time, so a data structure that records where an item sits can reach it in one step.

Because the number of a slot leads straight to its contents without any scanning, computing an item’s slot number and reading it costs the same regardless of how large the structure has grown. A structure that stores each item’s slot number alongside it can therefore access any item without searching for it.

An interface, or abstract data type, is the set of operations required of a data structure, like adding, removing, or looking up an item.

An interface names what a structure must be able to do without saying how those operations are carried out inside it. Separating the required behavior from its mechanism allows code to depend on the promised operations while the details underneath stay free to change.

A data structure is one way of implementing an interface. Each operation the interface requires has its own cost in that structure.

Choosing a concrete structure fixes how every required operation is actually performed, and each performance carries its own number of steps. Knowing those per-operation costs allows a structure to be judged against the operations a program leans on most.

A single interface can be implemented with different data structures. Each one makes different operations cheap or costly.

The same set of required operations can be fulfilled by structures that arrange their items in completely different ways, and those arrangements trade one operation’s speed against another’s. Recognizing this allows a structure to be matched to a program instead of accepting whichever one comes to hand first.

Code written to use only the interface keeps working when the data structure behind it is swapped for another.

When code calls only the operations the interface names and never depends on internal layout, replacing the structure underneath leaves every one of those calls valid. This separation allows a slow structure to be swapped for a faster one late in a project without rewriting the code that uses it.

An array stores its items in a run of neighboring memory slots, so any item is accessible instantly from its position.

Because the items sit in consecutive slots, the slot holding the item at a given position is found by adding that position to the address of the first item. That single calculation makes every item equally quick to access, no matter where it falls in the array.

Inserting or removing an item in the middle of an array means shifting every item after it, because the items are packed together.

Since the items occupy an unbroken run of slots with no gaps, making or filling a hole in the middle forces every later item to move one slot so the run stays contiguous. That shifting takes a number of steps proportional to how many items follow the change, so edits near the front are the most expensive.

A dynamic array grows by allocating a bigger block and copying its items over. Since that copy happens only once every many additions, each addition stays cheap on average.

When a dynamic array runs out of room, it reserves a new block of typically double the size, copies the existing items into it, and then keeps adding into the free space until that fills as well. Because each expensive copy is followed by many cheap additions into the roomy block, the cost spread across all the additions stays constant on average.

A pointer is a value that holds the location of another value in memory.

A pointer stores where a value lives, not the value itself, so accessing that data value means following the pointer to its location. Because it is only a location, a pointer can be copied or redirected to a different value without disturbing the value it currently points to.

A linked list stores each item together with a pointer to the next, so the items do not need to sit next to each other in memory.

Each item is bundled with the address of the following item, forming a chain that can be traced from one item to the next. Because the chain holds together through these stored addresses rather than through physical adjacency, items can live anywhere in memory and a new one can be linked in without moving any others.

Accessing the nth item of a linked list, or searching for a particular value in it, means following the pointers from the start, so both take time proportional to its length.

Since only the first item’s address is known outright, arriving at any later item requires reading each item’s stored pointer and jumping forward one item at a time. This step-by-step traversal makes the work grow with the number of items visited, so accessing the last item costs as much as scanning the whole list.

Inserting or removing an item at a known position in a linked list only repoints its neighbors. The operation is still costly due to the linear time required to find the item in the first place.

Once the surrounding items are in hand, adding or deleting an item changes just a couple of stored pointers, with no other item shifted. That saving is undercut because locating the position at all means following the chain from the start, which grows with the list’s length.

A tree links its items so each parent item points to its children items, branching out from a single root.

Every item holds pointers down to the items directly beneath it, and following those pointers from the single top item visits every other item. This branching arrangement lets a structure fan out widely while keeping any item only a short chain of pointers away from the root.

A binary search tree keeps every item larger than those in its left branch and smaller than those in its right, so a search can discard half the tree at each step.

At every item, the smaller values sit entirely in the left branch and the larger ones entirely in the right, so comparing a target against an item reveals which single branch could hold it. Following only that branch throws away the other one unexamined, cutting the remaining items down again and again until the target is found or ruled out.

Search, insertion, and removal in a search tree take a number of steps proportional to the tree’s height.

Each of these operations walks a single path from the root downward, comparing at each item and descending one level, so the work done equals the number of levels crossed. Because that path can be no longer than the tree is tall, the height of the tree sets the ceiling on how slow any of these operations can be.

Keeping a search tree balanced keeps its height small, which keeps search, insertion, and removal fast.

A balanced tree spreads its items so the two branches at each item hold roughly equal numbers, which keeps the number of levels close to the logarithm of the item count. Since the tree’s operations cost as much as its height, holding that height near the logarithm keeps them fast even as the tree grows large.

A data-structure invariant, like a binary search tree’s ordering, is the condition the structure’s operations preserve to maintain correctness and cost guarantees.

An invariant is a property every operation must leave intact when it finishes, so the next operation can rely on it already holding when it starts. Preserving that condition on each change keeps the structure’s guarantees applying without them being rechecked from scratch.

A hash function turns a key into a position in a table, so the item for that key can be stored and found in constant time.

The hash function computes a table position straight from the key itself, so storing or retrieving an item goes directly to its computed slot with no scanning. Because that computation and slot access take the same time regardless of table size, lookups by key stay fast as the table grows.

When two keys hash to the same position, the collision needs to be handled so both items can still be stored and found.

Because many keys map into a limited number of slots, different keys sometimes compute the same position, and a scheme such as keeping a small list of items at each slot resolves the clash. Handling collisions keeps every item retrievable, since without it a second item would overwrite or hide the first.

A hash table gives fast lookup by key on average, at the cost of keeping its items in no useful order.

The hash function scatters items across slots by their keys rather than by any ranking, so retrieval by key is quick but the physical order carries no meaning. Listing items in sorted order or finding the smallest one therefore gains nothing from the table and needs separate sorting work.

A hash table is one of the fastest ways to implement a set interface.

A set only needs to add items, remove them, and test membership, and a hash table performs each by computing one slot and touching it, giving constant time on average. Since a set never asks for its items in order, the table’s lack of ordering costs nothing here and leaves its speed as pure gain.

A stack removes its items in the reverse of the order they were added: last in, first out.

Items are both added and removed only at the same end, so the most recently added item is always the first one available to remove. This reversal suits any task that has to unwind actions in the opposite order they were carried out.

A queue removes its items in the order they were added: first in, first out.

Items enter at one end and leave from the other, so the item that has waited longest is always the next to be removed. This ordering fits any task that has to serve requests fairly in their order of arrival.

A priority queue removes the most important item next, whatever order the items arrived in.

Each item carries a priority, and removal always takes the highest-priority item currently held rather than the oldest or the newest. This lets urgent items jump ahead of items that were added earlier but matter less.

A heap is a tree kept in a partial order that implements a priority queue, with fast insertion and fast removal of the most important item.

A heap arranges items in a tree where every parent outranks its children, an order looser than a full sort but strict enough to keep the most important item at the root. Adding an item and removing the top one each restore this partial order in a number of steps proportional to the tree’s height, keeping both operations fast.

For a given interface, different data structures make different operations cheap or costly.

Two structures fulfilling the same interface can differ sharply in which operations they speed up, since one may hold its items in order while another scatters them for direct access. No single structure wins on every operation, so the trade-offs across structures have to be weighed rather than a best one assumed.

Two data structures are compared by the cost of each operation, weighted by how often a given problem performs it.

Comparing structures fairly means multiplying each operation’s per-use cost by how many times the problem actually calls it, then adding those weighted costs together. An operation that is slow on its own barely matters when it runs rarely, while a fast operation run constantly dominates the total.

The right data structure is found by identifying a problem’s most frequent operations and picking the one that makes those cheap.

The choice starts by counting which operations a problem runs most, then picking the structure that keeps exactly those operations fast even if it slows the rarer ones. Optimizing for the common operations rather than every operation equally keeps the overall running time low where it counts.

Recognizing that a problem fits a pattern already solved is often most of solving it.

Matching a new problem to the shape of one whose solution is already known turns invention into recognition. Once the fit is spotted, the existing method can be applied almost directly, so effort shifts from designing an approach to noticing the correspondence.

Many hard problems are solved by breaking them into subproblems and combining the answers.

Instead of attacking the whole problem at once, it is split into smaller pieces that are each solved separately, and their answers are stitched together into the full answer. Decomposition matters because a piece is usually far easier to reason about than the whole, and the same split can often be repeated on each piece.

Recasting a problem into the form a known technique expects, a graph for a graph algorithm or a set of states to search, is what lets that technique be applied to it.

Before a known technique can run, the problem is described in the vocabulary that technique operates on, such as nodes and edges or a space of states. This reframing matters because the technique’s guarantees carry over only once the problem genuinely matches its expected form.

A search problem looks for any solution that fits the requirements, while an optimization problem looks for the best one under some measure.

A search problem is satisfied by any candidate that meets every requirement, while an optimization problem ranks candidates by a measure and demands the top-ranked one. Naming which of the two is being solved matters because it decides when the work is allowed to stop.

Many problems are solved by systematically exploring the possible solutions.

The candidate solutions are enumerated in some deliberate order so that none is missed and none is examined twice. Working through them methodically matters because an ad hoc scan can silently skip the very candidate that works.

Brute force tries every possibility. It always works but is usually prohibitively slow.

Every candidate is examined in turn, with no shortcuts, which guarantees the answer is found whenever one exists. The catch is that the number of candidates usually grows so fast with input size that the approach becomes unusable on anything large.

Searching a sorted collection can halve the remaining possibilities at each step instead of checking them one by one.

Comparing the target against the middle element of a sorted collection reveals which half it must lie in, so the other half is discarded outright. Halving the range each step reduces the work from proportional to the collection’s size down to its logarithm.

A smarter search skips possibilities that cannot lead to a solution, or cannot beat the best one found so far.

By reasoning about a partial candidate, whole groups of possibilities are ruled out before being examined, either because they already violate a requirement or because a bound shows they cannot improve on the best answer so far. Discarding them early matters because it can shrink an enormous search into a manageable one.

The constraints a solution needs to satisfy shape which strategy can find it.

The requirements a valid solution must meet determine whether a fast approach exists or an exhaustive one is forced. Reading the constraints first matters because a small change in them can move a problem from easy to intractable.

Solving the search version of a problem can sometimes help with solving the optimization version of the same problem.

A procedure that merely decides whether a solution of a given quality exists can be invoked repeatedly, tightening the target quality until the best achievable value is pinned down. This connection matters because a plain yes-or-no test is often far easier to build than a direct optimizer.

A decision tree lays out the choices a search can make, and its depth is how many choices a solution takes.

Each node of a decision tree is a point where the search picks among options, each branch is one option, and a path from the root to a leaf spells out a complete sequence of choices. The tree’s depth counts the choices in a full solution, which sets how far any single path must be followed.

Backtracking builds a solution one choice at a time and undoes the last choice when it reaches a dead end.

A partial solution is extended one decision at a time, and when no extension can succeed, the most recent decision is reversed and a different option is tried in its place. This undo-and-retry loop matters because it explores the whole space of choices while only ever holding one partial solution at a time.

Pruning skips whole branches of the search once they are known to contain no solution.

When a branch of the search is shown to contain no valid solution, the entire branch is discarded rather than explored choice by choice. Cutting it matters because a single early elimination can remove an exponential number of dead-end candidates at once.

A greedy algorithm builds a solution by always taking the choice that looks best at the moment.

At each step, a greedy algorithm commits to whatever option looks best right then and never revisits an earlier choice. That makes it quick and simple, but the final solution is only as good as the bet that the best local choices add up to the best overall one.

A greedy algorithm is fast, but it is correct only when the problem has optimal substructure: the best-looking choice at each step can always be completed into a correct overall solution.

Optimal substructure means that whatever looks best locally at each step can always be extended into a correct final solution, and only when it holds does the greedy approach reach the right answer. Checking for this property matters because a greedy algorithm keeps its speed but earns its correctness only when the property is present.

That each greedy choice leads to a correct solution needs to be proved, not assumed.

Because a greedy choice is made on local information alone, its leading to a correct final answer has to be established by a proof, often an exchange argument showing any other first choice can be swapped for the greedy one without loss. Demanding a proof matters because a strategy that looks obviously right can fail on inputs never tried.

To show that a greedy algorithm fails, construct a counterexample showing that an early choice that looked best ended up blocking the correct answer.

A greedy algorithm is disproved by exhibiting one input where its locally best first choice forces a worse overall result than some alternative first choice. A single such counterexample settles the matter, since correctness would have required success on every input.

Divide and conquer splits a problem into smaller independent subproblems, solves each, and combines their results.

The problem is cut into smaller subproblems that share no work, each is solved on its own, and their results are merged into the answer for the whole. Independence matters because the pieces can be solved without coordinating, and the same cut can be reapplied to each piece.

Divide and conquer pays off when each subproblem is a fraction of the size of the original problem and combining the results of solving subproblems is cheap.

The gain rests on two conditions, each subproblem being a proper fraction of the original size, and the step that stitches subresults together being cheap relative to the whole. When both hold, the shrinking sizes compound into a large speedup, but an expensive combine step can erase it.

A recurrence relation captures the cost of a divide-and-conquer algorithm by expressing the work done on an input in terms of the work done on smaller pieces of the input.

A recurrence relation states the running time on an input of a given size in terms of the running time on the smaller pieces the input is split into, plus the cost of combining their results. Writing it down matters because solving the recurrence yields the algorithm’s total cost without tracing every step.

Dynamic programming applies when a problem’s subproblems overlap, so the solution to the same smaller problem is needed many times.

Dynamic programming fits problems whose subproblems recur, meaning the answer to one and the same smaller instance is demanded repeatedly across the computation. Spotting this overlap matters because a plain recursive solution would redo that identical work an exploding number of times.

In dynamic programming, each subproblem is solved once and its answer is stored, so later uses look it up instead of recomputing it.

Each distinct subproblem is computed a single time and its result is kept in a table, so any later need for that result is met by a lookup rather than a fresh computation. Storing answers matters because it collapses repeated, ballooning work down to one pass over the distinct subproblems.

Dynamic programming works for solving optimization problems when the best solution is built from the best solutions to its subproblems.

Dynamic programming solves an optimization problem only when its optimal answer is assembled from the optimal answers to its subproblems. This property matters because the best small answers can then be locked in and reused, instead of every combination being reconsidered.

Storing the subproblem answers trades memory for time, and that memory can sometimes be pared back.

Keeping every subproblem’s answer in memory buys speed at the price of the space those answers occupy. Sometimes that space can be reduced, because only the most recently computed answers are still needed while the earlier ones can be dropped.

When the exact best answer costs too much to compute, a heuristic aims for a good-enough one quickly.

A heuristic follows a sensible rule of thumb to reach a solution fast, accepting that it may not be the very best one. This tradeoff matters when the exact optimum would take impractically long to compute, so a close answer obtained quickly is worth more than a perfect answer obtained too late.

A heuristic gives up the guarantee of the best answer in exchange for speed, so it is judged by how close its answers come to the best possible one, and how often they reach it.

A heuristic surrenders any promise of optimality to gain speed, so its worth is measured by how near its solutions land to the best possible and how often they hit it exactly. Judging it on those two counts matters because speed alone says nothing about whether the answers can be trusted.