AP CSA 2026 Exam-Day Pacing and Checklist

What You Need to Know

This is your do-this-in-real-time plan for the AP CSA exam: how to budget time, when to skip/return, and what to check so you don’t lose points to avoidable mistakes.

The core rule

Your goal is maximum points per minute:

Don’t let one tough multiple-choice question (MCQ) or one stubborn free-response bug eat time that could earn you several easier points elsewhere.
Write code that is correct and complete first; polish only if time remains.

Exam structure you must pace for (non-negotiable)

Part	What you see	Time	What pacing means
Section I	MCQ	$40\,\text{questions}$	$90\,\text{min}$ total → average $2.25\,\text{min/question}$ , but you should finish faster on easy ones to buy time for harder ones
Section II	Free Response (FRQ)	$4\,\text{questions}$	$90\,\text{min}$ total → average $22.5\,\text{min/question}$ , but allocate based on difficulty and your strengths

Critical reminder: You can earn a lot of points with “mostly right” FRQ solutions (correct signatures + correct core logic) even if you don’t perfectly optimize or handle every edge case. Don’t chase perfection early.

Step-by-Step Breakdown

A. MCQ pacing method (fast passes)

Goal: bank easy points quickly, then spend remaining time strategically.

Set checkpoints on scratch paper
- Plan to reach roughly:
  - around one-third done by the first third of time,
  - two-thirds done by the second third,
  - finish a first pass with time left.
First pass = answer or skip fast
- If you can solve in under about a minute: answer now.
- If you’re still unsure after about two minutes: circle/mark it and move on.
- If it requires long tracing and you’re not immediately set up: skip and return.
Second pass = do the medium ones
- Revisit marked questions in order.
- For tracing questions, rewrite key state only (index, accumulator, current element). Don’t recopy full code.
Third pass = hard/time-sink questions
- Eliminate choices aggressively.
- Use quick “sanity checks”:
  - off-by-one loop bounds,
  - integer division,
  - String equality,
  - ArrayList indexing,
  - object aliasing.
Endgame: bubble/selection verification sweep
- Ensure every question has an answer.
- If truly stuck, guess using elimination.

Worked micro-example (MCQ decision)

You hit a question with nested loops and you can’t quickly tell the output.

Do: mark it, move on, come back when you have a clean head and more time.
Don’t: spend five minutes tracing when three other questions could be answered in that time.

B. FRQ pacing method (build points in layers)

Goal: get all required parts attempted, with correct method headers and core logic.

Initial scan (fast triage)
- In the first couple minutes, glance at all four prompts.
- Decide an order that fits you (many students start with the one that feels most familiar).
Time-box each FRQ
Use an “all four get time” rule:
- Allocate about one quarter of the time to each, then adjust slightly:
  - Give yourself a little extra for the one you expect is longest (often the later questions).
For each FRQ, use the same execution sequence
1) Read requirements (what methods/classes you must write)
- Underline: method names, parameter types, return types, and described behavior.
2) Write the skeleton first
- Class header (if needed)
- Instance variables (if needed)
- Required method headers exactly as specified
3) Implement core logic next (the “points engine”)
- Get loops/conditionals correct.
- Use helper methods if allowed and it saves time/clarity.
4) Do a quick dry run
- Trace a tiny example by hand (one or two iterations) to confirm:
  - correct initialization,
  - correct updates,
  - correct return.
5) Add edge-case handling only if it’s clearly required
- Respect stated preconditions. Don’t invent constraints.
If you get stuck: pivot to partial credit
- Move to the next part (FRQs often have multiple parts).
- Leave comments that show intent (briefly) if code is incomplete.
Final FRQ sweep
- Check: signatures, returns, braces, and index bounds.

Worked micro-example (FRQ salvage plan)

You can’t finish the most complex part of a method.

Do:
- keep the correct method header,
- implement the simplest correct version you can,
- return something of the right type,
- move on.
Don’t: delete everything and restart repeatedly.

Key Formulas, Rules & Facts

Pacing numbers (know these cold)

Item	Value	When to use	Notes
MCQ count	$40$	planning MCQ checkpoints	All single-select
MCQ time	$90\,\text{min}$	MCQ pacing	Budget per question conceptually
Avg MCQ time	$2.25\,\text{min/question}$	deciding when to skip	Don’t actually spend this long on easy ones
FRQ count	$4$	planning FRQ allocation	Attempt all
FRQ time	$90\,\text{min}$	FRQ pacing	Roughly one quarter each
Avg FRQ time	$22.5\,\text{min/question}$	time-boxing	Adjust by difficulty

High-yield “exam-day code correctness” rules

Rule	What it prevents	Fast check
Use `.equals(...)` for Strings	wrong equality comparisons	If you see `==` with Strings, pause
Array/ArrayList indices run $0$ to `length-1` / `size()-1`	out-of-bounds	Check loop conditions: `<` is safer than `<=`
`list.size()` is a method, not a field	compile-time errors	Always include parentheses
Integer division truncates	wrong arithmetic results	If both operands are `int`, result is `int`
Watch aliasing with object references	unintended side effects	If two variables reference same object, mutations affect both
Enhanced for-loop can’t directly remove items safely	logic errors / skipped elements	Use indexed loop if removing
Return type must match on every path	missing-return errors	For non-`void`, ensure all branches return

Warning: Even if you can’t run code, graders can see signature/type mistakes instantly. Correct headers and types are “free points” compared to debugging logic.

Examples & Applications

Example 1: MCQ skip threshold in practice

You’re on an MCQ with a tricky recursion trace. After about two minutes you’re still setting up the call stack.

Best move: mark it and continue.
Why: recursion traces are high-variance time sinks; your time is better spent collecting guaranteed points first.

Example 2: FRQ order choice

You preview the FRQs and one is a straightforward class with constructors/getters, while another is a dense $2\,\text{D}$ array traversal.

Best move for pacing: start with the class/design one if it’s your strength.
Why: quick confidence points reduce panic and protect later timing.

Example 3: FRQ “layered correctness” build

Prompt asks for a method that scans an ArrayList and returns a count meeting a condition.

Layer 1 (must have): correct method header + initialize a counter.
Layer 2 (core points): loop over valid indices and update counter when condition holds.
Layer 3 (polish): handle edge cases only if specified; keep code clean.

Example 4: End-of-section sweep

With a few minutes left in FRQ:

Verify every method:
- has the required name/signature,
- compiles (types line up),
- returns on all paths.
This can save more points than trying to “improve” one algorithm.

Common Mistakes & Traps

Over-investing in one MCQ
- What happens: you spend too long tracing one question.
- Why it’s wrong: opportunity cost; you lose multiple easier questions.
- Fix: set a hard internal limit (about two minutes) then skip.
Not attempting all FRQs
- What happens: you leave a whole question blank.
- Why it’s wrong: even partial structure earns points.
- Fix: time-box each FRQ; move on when the box ends.
Writing perfect logic with the wrong method header
- What happens: parameter order/types don’t match prompt.
- Why it’s wrong: graders can’t award full credit if the required method isn’t present as specified.
- Fix: copy the signature first, then code.
Off-by-one loop bounds under time pressure
- What happens: <= instead of <, or wrong start/end index.
- Why it’s wrong: incorrect counts, missed elements, or out-of-bounds.
- Fix: always sanity-check bounds against length / size().
Forgetting returns (or returning the wrong thing)
- What happens: missing return on some branch, or returns an accumulator that wasn’t updated correctly.
- Why it’s wrong: compile/logic errors.
- Fix: before leaving a method, point to the exact line that returns the final value.
String comparison slip (== instead of .equals)
- What happens: MCQ traps you; FRQ logic fails subtly.
- Why it’s wrong: == compares references, not content.
- Fix: if comparing text content, use .equals(...).
ArrayList method slips under stress
- What happens: list.size (missing parentheses) or confusing add(index, value) vs set(index, value).
- Why it’s wrong: compile errors or wrong behavior.
- Fix: quick recall: add can insert/append; set replaces; size() is a method.
Messy last-minute edits causing brace/indent bugs
- What happens: you “optimize” and break scope.
- Why it’s wrong: one missing brace can trash a whole method.
- Fix: only edit if you can re-check braces and logic afterward.

Memory Aids & Quick Tricks

Trick / mnemonic	What it helps you remember	When to use
A.S.A.P. (Answer, Skip, Answer, Pass-back)	MCQ flow: answer easy, skip hard, then return	MCQ first pass
H.T.R. (Header, Then Run)	FRQ: write correct method header first, then implement and dry-run	Start of every FRQ part
L.I.S.T. = `length` (arrays), `isEmpty()`, `size()`, `toString()`	Common container checks	Any array/ArrayList work
“Dot means method/field belongs to the left”	Prevents calling methods on wrong object	When you see chained calls
“Start, Stop, Step”	Loop sanity: init, condition, update	Before leaving any loop-based solution

Quick Review Checklist

Use this as your final two-minute scan.

MCQ pacing checklist

[ ] Do a fast first pass: answer easy ones immediately.
[ ] Skip anything that’s still unclear after about two minutes.
[ ] Return for a second/third pass with elimination.
[ ] Confirm every question has a marked answer.

FRQ pacing checklist

[ ] Preview all $4$ prompts; pick an order you can execute.
[ ] Time-box each question; don’t let one FRQ steal the whole section.
[ ] For every required method:
- [ ] signature matches prompt exactly,
- [ ] variables initialized,
- [ ] loop bounds safe,
- [ ] return present on all paths (if non-void).
[ ] Quick bug traps check: .equals for Strings, size() parentheses, integer division, off-by-one.
[ ] Attempt every part: partial credit beats blank.

You don’t need perfect code—you need disciplined pacing and clean, checkable correctness. You’ve got this.