Computational thinking

Problem statement, objectives and goals, input specification, output specification, constraints and limitations, and evaluation criteria.

You can describe the test that would settle it in one sentence. 'Return results in under five seconds on 10,000 records' can be tried; 'be fast' is an opinion and never can be.

Each input item, its data type, its valid range, and where it comes from — for example 'Member ID: a whole number between 1 and 99999, entered by staff'. The validation rules come straight from this.

What happens when there is nothing to show. Stating 'a message if there are no results' is a cheap and reliable mark.

So the target cannot be moved afterwards. Deciding what counts as success once you already know what you built is not judging the work at all.

Decomposition — breaking a large problem into smaller separate ones. Pattern recognition — finding what repeats. Abstraction — deciding what to leave out. Algorithmic design — writing the steps precisely.

Deciding what to leave out, and why — not being vague. A route-planning app treats a road as a start point, an end point and a travel time, dropping surface, width and street name as irrelevant.

Finding the parts of a problem that are the same, so one solution serves many cases. Every track event needs the same steps, so solving it once covers the 100 m, the 200 m and the relay.

Setting out the steps in order, precisely enough that someone else could follow them without asking a question. It does not require code — plain steps or a flowchart are enough.

No. The guide states it explicitly: it is a toolkit of problem-solving techniques. Planning a sports day, designing a database and diagnosing a fault all use the same four.

What are the pieces (decomposition)? What repeats (pattern recognition)? What can I ignore (abstraction)? What are the steps (algorithmic design)? Then trace the steps on a small example by hand.

Decomposition splits one wide table into several; abstraction decides which attributes each entity actually needs; pattern recognition notices that every many-to-many relationship needs a linking table.

In choosing which features to give the model and which to leave out. It is usually the single most important decision in a machine-learning project.

Because it turns a plausible-looking algorithm into one you know is right, and it finds the error before any code exists to debug. It is also very often exactly what the exam asks for.

To test whether you can take a problem described in words and make it solvable without reaching for a programming language — which is what computational thinking means.

Rounded box for Start/End, slanted box for Input/Output, rectangle for Process, diamond for Decision with two labelled exits, arrow for Flowline, and a small circle for Connector.

There is no loop symbol. A loop is a decision diamond with a flowline going back up to it — follow the arrows and the loop is obvious.

Draw the table first with one column per variable plus output; write a new row for every change; write the comparison out in full at every diamond; and add to the output column only when an output box is reached.

The boundary case. When the test is 'count at most N', the loop still runs when the two values are equal — one more time than most people expect.

Exactly two, labelled Yes and No. A diamond drawn with one exit or with three is drawn incorrectly.