Difficulty: Beginner | Prerequisites: CS 124 Course Overview notes.
Before you can write a program, you need to solve the problem on paper. CS 124 treats problem-solving as a structured, repeatable process: read, plan, express, test, revise. This is the intellectual core of the course and the skill that separates "knowing a programming language" from "being a computer scientist." The concepts here underpin every homework problem, every quiz, and every checkpoint of the machine project.
Solving a programming problem is a cycle of understanding, planning, coding, and debugging. The course trains each step deliberately. Algorithms can be iterative or recursive, and learning to reason about their correctness and efficiency is just as important as getting them to run.
Problem decomposition
Breaking a large problem into smaller, manageable sub-problems that can be solved independently. Think of it as turning one hard question into several easier questions.
Pseudocode
An informal, human-readable description of an algorithm that uses the structure of code (loops, conditionals) without the strict syntax of a real programming language. In simple terms, it is a rough draft of your program written in plain English with some code-like structure.
Edge case
An input or scenario at the boundary of what a program is expected to handle, often where bugs hide (e.g. an empty list, a negative number, a string of length zero). Think of it as the weird corner of the problem that is easy to forget but likely to appear on a quiz.
Debugging
The process of finding and fixing errors in code. It involves reading error messages, tracing execution, isolating the faulty section, and verifying the fix.
Correctness
An algorithm is correct if it produces the right output for every valid input, including edge cases. Partial correctness (works for some inputs) is not sufficient.
Efficiency
How economically an algorithm uses time and memory. Two correct solutions to the same problem can differ by orders of magnitude in efficiency, which matters when inputs grow large.
Read and understand. Before writing any code, make sure you know exactly what the problem is asking. Identify the inputs, the expected outputs, and any constraints. Misreading the problem is the most common source of wasted time.
Plan. Sketch a solution in pseudocode or on paper. Decide which approach to use (loop through the data? break it into sub-problems? build up from a base case?). Identify edge cases and how your plan handles them.
Express. Translate your plan into Java or Kotlin. This step should be relatively mechanical if the plan is solid.
Test. Run your code against the expected outputs. Try normal cases first, then edge cases. If something fails, move to debugging.
Revise. Read the error, trace the logic, find the mismatch between your plan and your code (or between your plan and the problem). Fix and re-test.
Use a loop to process data step by step.
Typical pattern: initialise a result, loop through the input updating the result, return the result.
Well suited to problems where you process a collection from start to finish (summing an array, searching for a value, filtering items).
Define the solution in terms of a smaller instance of the same problem.
Every recursive solution needs a base case (the smallest instance you can solve directly) and a recursive step (how to reduce the current problem toward the base case).
Well suited to problems with a naturally hierarchical or self-similar structure (tree traversal, divide-and-conquer sorting, computing factorials).
Common mistake: forgetting the base case, which causes infinite recursion and a stack overflow.
Correctness: Does the algorithm handle all valid inputs? Does it terminate? Does it produce the right answer every time?
Computational requirements (time): How many operations does the algorithm perform as a function of input size? Grows linearly? Quadratically? Logarithmically?
Storage requirements (space): How much extra memory does the algorithm need beyond the input itself?
These questions are central to the conceptual side of CS 124 and appear directly in quizzes.
Problem statements in CS are precise and literal. Every word matters.
A common failure mode: skimming the problem, assuming you know what it asks, and solving a slightly different problem.
The course trains this deliberately. Homework and quiz problems are written to reward careful reading.
The plan-then-code approach is how professional developers work. Writing code without a plan is like building a house without blueprints: you end up tearing things down and starting over.
Reasoning about efficiency is what lets engineers build systems that handle millions of users. A poorly chosen algorithm on a small dataset might finish in milliseconds, but the same algorithm on production data could take hours.
Students often jump straight to coding without planning, assuming they will "figure it out as they go." This works for trivial problems but fails on anything non-trivial, and it wastes time on quizzes where minutes matter.
Students sometimes think recursive solutions are always better (or always worse) than iterative ones. Neither is universally superior; the right choice depends on the problem structure.
Students often treat debugging as random guessing ("let me change this line and see what happens"). Effective debugging is systematic: read the error, form a hypothesis, test it, repeat.
Students sometimes confuse a program that runs without errors with a correct program. A program can execute without crashing and still produce wrong output for certain inputs.
⚠️ Quizzes include both writing code and debugging challenges. You will need to trace through code mentally and identify where it goes wrong.
⚠️ Quiz programming questions are similar to homework problems, so completing the homework is direct exam preparation.
⚠️ You have unlimited attempts on quiz programming and debugging challenges without losing credit, but time is limited. Having a plan before you start typing is the fastest way to finish.
⚠️ Reasoning about computational and storage requirements is a stated conceptual objective and will be tested.
True or false: The first step in solving a programming problem should be writing code.
Fill in the blank: Every recursive algorithm needs a ________ to prevent infinite recursion.
True or false: A program that runs without error messages is always correct.
Fill in the blank: ________ is the process of finding and fixing errors in code.
True or false: Efficiency only matters when working with very large datasets.
Answers: 1. False (the first step is reading and understanding the problem). 2. Base case. 3. False (it can produce incorrect output without crashing). 4. Debugging. 5. False (efficiency matters at any scale, and poor choices compound as data grows).
Q: Outline the five steps of the problem-solving cycle as taught in CS 124.
A: Read and understand the problem, plan a solution (pseudocode or sketch), express the plan in code, test against expected outputs and edge cases, revise by debugging any failures.
Q: What two components must every recursive solution include, and what happens if one is missing?
A: A base case (the simplest instance solved directly) and a recursive step (reducing the problem toward the base case). Without a base case, the function calls itself indefinitely, causing a stack overflow.
Q: Why is it important to test edge cases, not just typical inputs?
A: Bugs often hide at the boundaries of expected input (empty collections, zero, negative numbers, single-element lists). A program can appear correct on normal data and fail on edge cases, which quizzes and real-world use will expose.
Q: Explain the difference between computational requirements and storage requirements of an algorithm.
A: Computational requirements (time complexity) describe how the number of operations grows with input size. Storage requirements (space complexity) describe how much additional memory the algorithm needs. An algorithm can be fast but memory-hungry, or slow but memory-efficient.
Q: A student writes a loop that processes an array and gets the right answer for an array of five elements but the wrong answer for an empty array. What kind of error is this?
A: A failure to handle an edge case. The algorithm lacks logic for the boundary condition of an empty input.
The problem-solving cycle (read, plan, express, test, revise) is the same process used in software engineering, systems design, and technical interviews.
Reasoning about time and space complexity connects to the formal analysis you will do in CS 225 (Data Structures) and CS 374 (Algorithms and Models of Computation).
Recursive thinking is foundational for understanding trees, graphs, and divide-and-conquer algorithms in later courses.
CS 124, UIUC, problem-solving, algorithmic thinking, iterative, recursive, pseudocode, edge case, debugging, correctness, efficiency, computational complexity, space complexity, time complexity, base case, stack overflow, problem decomposition, CS 124 study guide, CS 124 quiz prep, intro to algorithms, beginner programming