Algorithms and Programming — the one-page version

Tip: On any tracing question, draw a two-column table: variable name, current value. Update one row per line of code. Nearly every wrong answer on these questions comes from doing the update in your head and slipping.

Tip: Index questions are a constant source of lost points. AP pseudocode is 1-indexed. list[0] is an error. If a question shows real-language code (Python-style), it will say so — otherwise assume 1-based.

Tip: Whenever you see MOD, ask "what's the remainder?" and do the long division. For expressions mixing MOD with other operators, put parentheses around the MOD part mentally — MOD has the same precedence as multiplication, so a + b MOD c computes the MOD first.

Tip: When the exam shows string operations, it defines them in the question (e.g., "the procedure SUBSTRING(str, start, end) returns…"). Read that definition carefully — in particular, whether the end index is included — and apply it literally rather than assuming a language you know.

Tip: For "which expression is equivalent" questions, don't reason abstractly — plug in all four combinations of true/false (or a few boundary numbers) and compare outputs. It takes 30 seconds and is essentially error-proof.

Tip: Count the IFs. Independent IFs can each fire; an IF/ELSE chain fires exactly one branch. When a question asks "how many lines are displayed," this distinction is usually the whole question.

Tip: Trace nested conditionals from the outside in. Decide the outer condition, cross out the branch that doesn't run, and only then look at what's inside the surviving branch. Never evaluate an inner condition before you've confirmed its outer branch runs.

Tip: REPEAT UNTIL runs while the condition is false. Students constantly flip this. Read it as "keep going until this becomes true." And always check the initial condition — a loop that's already satisfied runs zero times.

Tip: When asked "what does this algorithm do," don't trace with random values — trace with a tiny list of 3 items and watch what the tracked variable equals at the end. The initialization line usually tells you the pattern before you've read anything else.

Tip: Rewrite the list after every INSERT/REMOVE/APPEND — literally write it out with brackets. Tracking index shifts in your head is where these go wrong. And in a FOR EACH loop, changing the loop variable does not change the list.

Tip: If a question about binary search doesn't say the list is sorted, that's the answer: binary search can't be used. If it asks for the maximum number of checks, find the smallest power of 2 that is greater than the list size and use that exponent: 8 items → 4, 15 → 4, 16 → 5, 64 → 7, 100 → 7, 1000 → 10.

Tip: Track "where am I" during a trace. When you hit a procedure call, write down the line you'll return to, go execute the procedure with the arguments substituted for the parameters, and come back. RETURN means you stop reading the procedure instantly — even if there are lines below it.

Tip: When a question asks why a programmer should turn repeated code into a procedure, the right answer is about reducing duplication and making changes easier. Answers about making the program run faster or use less memory are distractors — procedures don't do that.

Tip: Questions here are usually scenario-based: a developer wants to add a map to an app. The correct reasoning is "use a library to avoid rewriting tested code," and the correct next step is "read its documentation/API." Any option suggesting you must understand the library's internal implementation is wrong.

Tip: Count outcomes as b − a + 1, then count how many satisfy the condition. Students forget that both endpoints are included and get 1/9 instead of 1/10. If a question describes wanting a value "from 1 to 100," the call is RANDOM(1, 100), not RANDOM(0, 100).

Tip: Two answer patterns dominate. "Why use a simulation?" → safety, cost, time, or impossibility of the real thing. "What's a limitation?" → simplifying assumptions mean results may not reflect reality. If an option says a simulation gives "exact" or "guaranteed" real-world results, it's wrong.

Tip: If a question gives a table of input size vs. steps, check the growth: steps doubling when n increases by 1 = exponential = unreasonable. Steps multiplying by 4 when n doubles = n² = reasonable. When the stem says "no efficient algorithm exists" or "the solution doesn't have to be perfect," the answer involves a heuristic.

Tip: Three categories, don't mix them: (1) reasonable time — has a fast algorithm; (2) unreasonable time — has an algorithm, but too slow, so use a heuristic; (3) undecidable — no algorithm can exist for all cases. If the stem says "no algorithm can ever" or mentions determining whether an arbitrary program halts, it's undecidable.