1.3 Algorithmic thinking & flowchart/decision logic

Thinking like an algorithm

Algorithmic-reasoning items hand you a small block of pseudocode or a flowchart and ask what it outputs, how many times a loop runs, or which branch executes. There is no shortcut and no trick: you become the computer and execute the steps exactly, in order, tracking every variable as it changes. Cyber roles depend on this because analysts constantly read scripts, reason about how malware branches, and predict how an automated defense will respond to a given input. The test rewards disciplined, step-by-step execution over intuition.

Flowchart building blocks

Flowcharts use a small fixed set of symbols, and knowing them lets you follow any diagram:

A decision diamond always has exactly one entry arrow and two exit arrows, one for true/yes and one for false/no. Evaluate the condition, then follow the matching arrow — never both.

Trace tables: the core technique

The most reliable way to solve these items is a trace table: one column per variable, one row per step, updating only the values that change and carrying the others down. Consider this loop:

x = 2
y = 5
while x < y:
    x = x + 2
    y = y - 1
output x, y

Tracing it:

After the first pass x becomes 4 and y becomes 4; now x < y is false, so the loop ends and the output is x = 4, y = 4. The classic error is running the loop one extra time out of momentum.

Loops: count the iterations carefully

A for loop runs a fixed number of times. for i in 1..4 executes for i = 1, 2, 3, and 4 — four passes. A while loop runs until its condition becomes false; if the condition can never become false, it is an infinite loop. Always re-check the exit condition after each pass rather than assuming.

A summing example:

total = 0
for i in 1..4:
    total = total + i

Here total accumulates 0 + 1 + 2 + 3 + 4 = 10. Build the trace table if you are unsure: total goes 0, then 1, then 3, then 6, then 10 across the four passes.

Swaps and the order of statements

Order inside a block matters just as much as loop counts. To swap two variables you must use a temporary holder, or you overwrite a value before you can use it. Given a = 3 and b = 7, the sequence temp = a; a = b; b = temp correctly ends with a = 7 and b = 3. But the naive a = b; b = a fails: after the first line a is already 7, so the second line sets b = 7 as well, and the original 3 is lost. When you trace, execute assignments strictly top to bottom and never reuse a value you have already overwritten.

Decision branches and nested logic

Branches choose one path based on a condition:

if score >= 90:
    grade = A
else if score >= 80:
    grade = B
else:
    grade = C

For score = 85, the first test (>= 90) is false, the second test (>= 80) is true, so grade becomes B and the final else is skipped entirely. Only the first matching branch runs, so the order of the tests matters. Nested conditions often combine tests with AND and OR: "if the user is an admin AND the session is active" requires both parts to be true before the branch runs.

Reading logic gates

The same Boolean logic that governs branches also appears as gates. AND is true only when both inputs are true; OR is true when at least one input is true; NOT inverts a value.

Common traps

• Off-by-one errors: running a loop one time too many or too few — count the passes explicitly.
• Checking the loop condition at the wrong moment instead of after each update.
• Assuming multiple else-if branches run; only the first true one executes.
• Forgetting that AND requires both operands true, while OR needs only one.
• Losing track of a variable — when in doubt, always write the trace table rather than holding values in your head.