Computational Problem-Solving Before Coding: A Worked University Exercise

I would ask a student to explain who receives the next available piece of equipment before asking them to write the allocation code. A programme can run successfully while implementing a rule nobody intended. The explanation, the trace and the changed case give the tutor something useful to inspect.

Computational problem-solving before coding means making the problem, rules, state changes and expected results explicit before implementing a solution. Here is an original exercise a university tutor can adapt for an introductory computing class. It requires no particular programming language. It is a teaching example, not a validated test of readiness for university or employment.

Start with a task a person can explain

The final CS2023 competency framework describes a task through a role and context, and separates the task from the knowledge, skills and dispositions needed to attempt it. Its task-design framework includes components, activities and constraints. That is a useful discipline for designing this exercise. It does not validate the exercise or prescribe it for every course. [1]

There is also an accessible Saudi starting point: the Saudi Bebras activity book contains short computational-thinking tasks that do not require prior computer-science knowledge. It is a school-oriented resource. Its availability is not evidence that this university exercise improves attainment. [2]

The equipment-loan problem

Everything in this case is fictional. You are designing a small university equipment-loan service. Explain its allocation rule to a colleague who must implement it. Use the following specification:

• Two identical kits are available at 09:00.
• All requests in the starting case are eligible. Eligible requests wait in arrival order. Ties are resolved by request ID, lowest first.
• A loan lasts 30 minutes from allocation. In the starting case, every kit returns on time.
• At a shared timestamp, process returns first, add that timestamp's arrivals to the queue, then allocate available kits from the front of the queue.
• Never allocate more kits than are available. A request remains in the queue until allocated or explicitly withdrawn.

Requests R1 and R2 arrive at 09:00. R3 arrives at 09:10. R4 arrives at 09:30. Ask the student to predict the allocation, then show the intermediate state. Do not accept a final list without the reasoning that produced it.

Work through the state changes

The important explanation at 09:30 is that R3 remains ahead of R4. Because two kits return, both requests start together. That happy result can hide an ordering defect.

A flawed rule might allocate to the newest arrival before checking the waiting queue. It can produce the same start times in this first case. Passing this example alone therefore does not establish that the rule respects arrival order.

Change one condition to expose the defect

Now change one fact: only one of the two kits is physically returned at 09:30. The other arrives at 09:40. Keep every other rule unchanged.

At 09:30, R3 receives the available kit and R4 waits. At 09:40, R4 receives the returned kit. Their loans end at 10:00 and 10:10 respectively. An implementation that gives R4 the 09:30 kit because R4 has just arrived violates the stated queue rule.

I would ask the learner to identify the first point at which the faulty solution differs from the specification. “The output is wrong” is less informative than “at 09:30 the algorithm removes R4 before the older eligible request R3.”

This is also an opportunity to distinguish scheduled availability from observed availability. A kit due back is not a kit actually available. That distinction should be visible in the state representation.

Write the rule before choosing the code

1. Record actual returns and update the free-kit count.
2. Add arrivals, ordered by request ID within the same timestamp.
3. While a kit is free and the queue is non-empty, allocate to the oldest waiting eligible request.
4. Remove the allocated request, reduce the free-kit count and record its expected return time.
5. Retain the remaining queue for the next event.

This is a plain-language algorithm for the stated exercise. A real service would need further decisions about eligibility checks, overdue items, cancellations and equipment condition. If the tutor introduces an ineligible request without defining how it is handled, asking for clarification is a sensible response. Do not quietly reward learners for guessing an unstated policy.

Use an observation sheet with room for uncertainty

• Specification: Which facts and ordering rules did the student use? Which assumptions did they ask to clarify?
• Representation: Can another person reconstruct the queue, free capacity and loans from the record?
• Tracing: Where does the student show each state change, including waiting?
• Testing: Does the late-return case distinguish the intended rule from the faulty one?
• Revision: Can the student explain what changes in the algorithm and what remains unchanged?

Record the evidence beside each observation. “Not demonstrated in this attempt” is an appropriate entry. A short attempt may leave a criterion unobserved; it does not justify a broad judgement about the learner's ability.

For English and Arabic groups, keep the timestamps, identifiers, event order and clarification rights equivalent. Translate “available” carefully so that neither version implies that an expected return has already happened. Language support and reasoning support should be recorded separately.

Use the exercise to choose the next teaching step

If a student cannot explain the queue, I would work on the representation before adding syntax. If the reasoning is clear but the implementation fails, the next task can focus on code and debugging. After teaching, use a different case with the same underlying rule to investigate whether the reasoning carries over. Repeating a remembered answer is weaker evidence.

Practice-Native Learning is what we build at Altaius: learning through realistic situations, decisions, consequences and feedback. This example applies that design approach to computational work. It is not an announcement of a deployed university product or evidence of a learning outcome.

For a course team exploring a bounded exercise, I would start with one learning objective, the existing assessment and a task that exposes the reasoning you currently cannot see. The custom simulation brief offers a starting structure for the context, decisions and evidence, adapted to your discipline. The methodology article explains the broader approach.

Sources and scope

1. ACM, IEEE-CS and AAAI, CS2023 final report, Introduction to Competency Framework, pages 1 to 5. Read on 1 November 2026. Supports task, context and constraint framing, not this exercise's effectiveness.
2. Saudi Bebras team, Computational-thinking activity book, introduction and skills pages. Read on 1 November 2026. School-level context; no university outcome claim.

The loan service, rules, trace, counterexample and observation sheet are original illustrative teaching material.