Skip to content

Quiz: Computational Thinking and Debugging for Physical Computing

Test your understanding of computational thinking and debugging for physical computing with these review questions.

1. What is the definition of computational thinking?

  1. A method for writing flowcharts using standardized shapes
  2. The process of testing a circuit for electrical faults
  3. A way of breaking a problem apart and describing a solution precisely enough for a machine to carry it out
  4. A programming language used to control microcontrollers
Show Answer

The correct answer is C. Computational thinking is a way of breaking a problem apart and describing a solution so precisely that a machine can carry it out without a human filling in the gaps. It does not require writing code (option A describes flowcharts specifically, not the broader mindset), it is not circuit testing (B), and it is not itself a programming language (D) — it is the thinking process that comes before code.

Concept Tested: Computational Thinking

2. Which term describes an input device that measures a physical quantity, such as light level or distance, and converts it into a signal a program can read?

  1. Sensor
  2. Actuator
  3. Output device
  4. State machine
Show Answer

The correct answer is A. A sensor is an input device that measures a physical quantity, like light level, distance, or temperature, and converts it into a signal a program can read. An actuator (B) does the opposite — it converts a program's decision into physical motion, light, or sound. An output device (C) is the broader category actuators belong to, not input. A state machine (D) models behavior, not measurement.

Concept Tested: Sensor

3. What is an algorithm?

  1. A diagram made of ovals, rectangles, and diamonds
  2. Any electronic component that senses the physical world
  3. A style of programming where code runs only in response to events
  4. A finite, unambiguous sequence of instructions that takes input and produces a specific output
Show Answer

The correct answer is D. An algorithm is a finite, unambiguous sequence of instructions that takes some input and produces a specific output, similar to how a recipe takes ingredients and reliably produces a cake. Option A describes a flowchart, which is one way to represent an algorithm, not the algorithm itself. Option B describes a sensor, and option C describes event-driven programming, a different concept entirely.

Concept Tested: Algorithm

4. What is a flowchart?

  1. A style of programming that reacts to hardware signals
  2. A diagram that represents an algorithm using standardized shapes such as ovals, rectangles, and diamonds
  3. A written description of a bug's root cause
  4. A short plain-language version of code that skips exact punctuation
Show Answer

The correct answer is B. A flowchart is a diagram that represents an algorithm using standardized shapes: an oval for start and end points, a rectangle for a processing step, and a diamond for a yes/no decision. Option D describes pseudocode, a related but different tool for writing down algorithms. Option A describes event-driven programming, and option C describes a step in root cause analysis, not a flowchart.

Concept Tested: Flowchart

5. Which statement best describes the difference between polling and using an interrupt to detect a sensor event?

  1. Polling uses less CPU time than an interrupt because it only checks occasionally
  2. An interrupt requires the program to repeatedly check the sensor in a loop, while polling reacts instantly
  3. Polling repeatedly checks a sensor on a schedule, while an interrupt is a hardware signal that reacts immediately when the event occurs
  4. Polling and interrupts are two different names for the exact same detection technique
Show Answer

The correct answer is C. Polling means the program repeatedly checks a sensor's value on a fixed schedule, while an interrupt is a hardware signal that pauses the processor and jumps to a response the instant an event occurs. Option A reverses the CPU usage comparison — polling generally uses more CPU while waiting, not less. Option B swaps the two definitions, and option D incorrectly claims they are identical techniques.

Concept Tested: Polling

6. In the sense-think-act cycle, what makes a system's behavior a feedback loop?

  1. The system has more than one sensor connected to it
  2. The program uses interrupts instead of polling
  3. The system includes both an input device and an output device
  4. The output of one cycle changes something that a later "sense" step will detect
Show Answer

The correct answer is D. A feedback loop exists when the "act" step of one cycle changes something that a later "sense" step will detect — for example, a robot's motor moving it closer to a wall, which its distance sensor then reads as a smaller number. Having multiple sensors (A), choosing interrupts over polling (B), or simply having both input and output devices (C) does not by itself create a feedback loop.

Concept Tested: Feedback Loop

7. How does root cause analysis differ from rubber duck debugging?

  1. Root cause analysis traces backward through a system to find the single original cause of multiple symptoms, while rubber duck debugging involves explaining code aloud to surface an overlooked gap
  2. Root cause analysis requires a physical rubber duck, while rubber duck debugging does not
  3. Root cause analysis is only used for hardware problems, while rubber duck debugging is only used for software problems
  4. Root cause analysis and rubber duck debugging both describe the same technique of testing edge cases
Show Answer

The correct answer is A. Root cause analysis means tracing backward through a system, step by step, until you find the single original cause that all the symptoms trace back to. Rubber duck debugging means explaining your code or circuit out loud to surface a gap in your own logic. Option B has the techniques' names reversed in meaning, option C invents a hardware/software split that does not exist, and option D confuses both techniques with edge case testing.

Concept Tested: Root Cause Analysis

8. Which pillar of computational thinking is being used when a student notices that a robot's "stop before hitting a wall" problem follows the same logic as a thermostat reacting to temperature?

  1. Decomposition
  2. Pattern recognition
  3. Abstraction
  4. Algorithm design
Show Answer

The correct answer is B. Pattern recognition means noticing similarities between the current problem and problems already solved — here, recognizing that "if a number crosses a threshold, do something" is the same underlying logic in both the robot and the thermostat. Decomposition (A) would instead split the wall-stopping problem into smaller pieces, abstraction (C) would involve ignoring irrelevant details, and algorithm design (D) would order the steps into a sequence.

Concept Tested: Pattern Recognition

9. A student is designing a program for a robot that must stop before hitting a wall. She decides to ignore the exact voltage curve of the distance sensor and instead work only with "distance in centimeters." Which pillar of computational thinking is she applying?

  1. Decomposition
  2. Pattern recognition
  3. Algorithm design
  4. Abstraction
Show Answer

The correct answer is D. Abstraction means deciding which details matter for the problem at hand and ignoring the rest, so you can work with a simpler model of reality — exactly what the student does by working with "distance in centimeters" instead of the sensor's raw voltage curve. Decomposition (A) would instead break the overall goal into smaller jobs, pattern recognition (B) would connect it to a previously solved problem, and algorithm design (C) would order the steps.

Concept Tested: Abstraction

10. A STEM robot sometimes stops driving for no obvious reason. Possible suspects include a loose wire, a bad sensor, an incorrect threshold value, a low battery, and a timing bug. Which debugging approach is best suited to tracing these symptoms back to the single underlying cause instead of just patching the first thing noticed?

  1. Rubber duck debugging
  2. Trial and error testing performed without first narrowing down the suspects
  3. Root cause analysis
  4. Iterative design
Show Answer

The correct answer is C. Root cause analysis is the discipline of tracing backward through a system, testing suspects one at a time, until the single original cause behind multiple possible symptoms is found — exactly the situation described, where five different suspects could each explain the robot's behavior. Rubber duck debugging (A) is better suited to surfacing overlooked logic gaps, unfocused trial and error (B) wastes effort without narrowing suspects, and iterative design (D) describes the broader build-test-refine cycle, not fault isolation.

Concept Tested: Root Cause Analysis