Original worked examples and skill checks
These examples are original teaching exercises, not official specimen-paper questions or licensed software demonstrations. They isolate small decisions for learning; the examination may combine several concepts and demand complete practical files. Practise each example independently and then change the test condition.
Example 1: Binary for decimal 13
Situation and result: Decimal 13 is 8 + 4 + 1, so its binary form is 1101, or 00001101 in an eight-bit field.
Why it works: The sum of powers of two explains the conversion. Leading zeros are useful when the question asks for a fixed width.
Try a fresh condition: Convert 10 to 8-bit binary and check it by adding the weights of set bits.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 2: Two’s complement for negative three
Situation and result: In 8-bit two’s complement, positive 3 is 00000011. Invert to 11111100 and add one to obtain 11111101 for −3.
Why it works: Two’s complement is a signed representation within a specified bit width. Do not confuse this with unsigned value 253.
Try a fresh condition: Represent −1 using the same method and explain why eight bits are required in the example.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 3: XOR versus OR
Situation and result: For inputs A=1 and B=1, OR outputs 1 but XOR outputs 0. When A=1 and B=0, both output 1.
Why it works: The difference is whether exactly one input is true or at least one is true.
Try a fresh condition: Complete the truth tables for all four possible two-input combinations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 4: Python types
Situation and result: In an illustrative Python console, `"5" + "2"` results in `"52"`, while `int("5") + int("2")` results in 7.
Why it works: String concatenation and integer addition are different operations. Input handling must match the requirement.
Try a fresh condition: Test with `"03"` and discuss what is lost or retained after conversion.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 5: A loop trace
Situation and result: Original Python code: `total = 0; for x in [2, 4, 6]: total += x`. The final `total` is 12.
Why it works: The loop iterates over three values, updating the same accumulator each time. A trace table shows totals 2, 6 and 12.
Try a fresh condition: Change the list to [1, 3, 5, 7] and compute the final value without executing code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 6: While-loop boundary
Situation and result: A counter starts at 0. The loop condition is `count < 4` and each iteration adds 1. The loop body executes four times and ends with count 4.
Why it works: The condition is tested before each iteration. The boundary is central to determining the number of repetitions.
Try a fresh condition: Change the comparison to `<= 4` and predict the number of iterations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 7: Search a list
Situation and result: A simple linear search checks [8, 5, 11, 5] for the first occurrence of 5. With zero-based indexing, the answer is index 1.
Why it works: Duplicates mean a search specification should say whether it wants the first, last or all matches. A program cannot be judged correct without that requirement.
Try a fresh condition: Ask for the last occurrence and then for a value not in the list.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 8: A file-processing scenario
Situation and result: A program reads three numeric values from a text file to compute a total. The file may be missing or contain an invalid line.
Why it works: The program must know how to open and read, and the required input format. Testing only a perfect file misses realistic error conditions.
Try a fresh condition: List expected behaviour for a missing file, a blank line and a valid three-line file.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 9: Function design
Situation and result: An illustrative function `def double(x): return 2*x` maps input 6 to output 12.
Why it works: A function describes a reusable computation; naming input and output before implementation clarifies its purpose.
Try a fresh condition: Write a function that returns the square of its input and test negative two.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 10: Spreadsheet fixed tax rate
Situation and result: Cell F1 holds 0.09, B2 contains 100, and `=B2*(1+$F$1)` calculates 109.
Why it works: The absolute reference keeps the rate fixed as the formula is copied to another row. B2 stays relative.
Try a fresh condition: If B3 contains 50, predict the copied calculation result.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 11: A spreadsheet validation range
Situation and result: An assessment spreadsheet allows scores from 0 to 100 inclusive. The correct validation accepts 0 and 100 but rejects −1 and 101.
Why it works: Boundary cases show whether the condition matches the written specification, not only ordinary mid-range inputs.
Try a fresh condition: Specify test values for a percentage input requiring exactly one decimal place.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 12: Network scope
Situation and result: Four computers share a printer through the same building network, while an external online service is temporarily unavailable.
Why it works: Local resource access may continue even when the wider internet connection fails, provided the LAN and printer work.
Try a fresh condition: Identify which devices or links could cause a site-wide external outage.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 13: Data representation and units
Situation and result: A storage calculation uses 1 KiB = 1024 bytes, while 1 kB in decimal convention is 1000 bytes.
Why it works: The prefix convention matters: casually treating them as identical can introduce error in large calculations.
Try a fresh condition: Convert 2 KiB to bytes and compare with 2 kB.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 14: A logic error in a grade rule
Situation and result: A program prints ‘Pass’ for `score > 50`, but the specified rule says a score of at least 50 passes.
Why it works: Input 50 exposes the logic error. The condition should include equality.
Try a fresh condition: Write expected results for 49, 50 and 51 before changing the code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 15: An algorithm with duplicate values
Situation and result: The maximum of [3, 9, 9, 4] is 9. An algorithm that reports a maximum value works, even though two list elements share it.
Why it works: If the specification instead requests the position of the first or last maximum, duplicate handling becomes relevant.
Try a fresh condition: Specify which index should be returned under a first-match rule.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 16: Responsible data use
Situation and result: A school app collects learners’ names and attendance. A proposed feature publicly ranks every learner without consent or clear educational need.
Why it works: Technical feasibility does not make data disclosure appropriate. Privacy, purpose and access controls must be evaluated.
Try a fresh condition: Suggest a less intrusive way to provide teachers with attendance insights.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 17: A JupyterLab save check
Situation and result: A student modifies a Python notebook, reruns a cell and sees correct output, but forgets to save after the final change.
Why it works: A correct visible output does not guarantee the submitted file includes the latest version. Saving and verifying are part of the task.
Try a fresh condition: Design a last-five-minutes checklist for a simulated lab that reopens all required files.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 18: Compare a G2 and G3 task
Situation and result: A G2 practice asks for Scratch sprite behaviour, while a G3 lab problem asks for Python code to process an input list.
Why it works: Both involve computational thinking, but the software and expected deliverables differ. A student should train on the actual syllabus.
Try a fresh condition: Rewrite the game concept as a high-level data-processing requirement and identify which platform suits each paper.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
How to plan, test and debug a computing solution
Start with a plain-language problem statement. Write down the required inputs and outputs, their data types and any permitted ranges. A teacher may specify a spreadsheet that rejects invalid stock counts or a program that returns the first matching item. Those requirements guide implementation more effectively than picking software features at random.
Next decompose the solution: data acquisition, validation, processing, presentation and saving. Describe the relevant relationships before writing code or formulas. This makes it easier to detect a missing step and avoids spending time on decorative formatting while the core result is still wrong.
Test normal cases and boundary cases deliberately. An ordinary mid-range score may pass every condition, while an exact threshold reveals a missing equality sign. Check empty input, repeated values, very small quantities and invalid formats where those cases are relevant to the specification. Record expected results before observing actual ones.
Distinguish syntax errors, runtime problems and logic errors where applicable. A syntax error prevents code from being interpreted correctly; a runtime failure arises during execution; a logic error may generate a plausible but wrong answer. Fixing each requires a different investigation. For spreadsheets, identify whether the issue lies in the selected range, copied reference, data type or chart source.
Finally inspect the deliverable, not only the workspace. The digital lab includes time to save files, and the submitted softcopy must reflect the final work. A correct answer that was never saved may be unavailable to the marking process. Reopen the actual exported or saved file during practice and verify its content against the task.
What an effective mock lab looks like
A good K349 simulation has one spreadsheet task and several Python tasks in a 150-minute working session. Plan solutions, test code in the approved Python/JupyterLab environment, and save every required file. The Python quick-reference guide helps with syntax but does not solve the algorithmic problem.
Set a checklist before beginning: which files are required, where outputs must appear, how calculations will be checked, and how much time remains for verification. This prevents a last-minute scramble to locate a file or export a project that was only saved within the editing application.
Do not claim that any individual home software version is automatically approved for national examinations. The syllabus describes required software categories and the candidate instructions specify the examination environment. Practise in a version and configuration confirmed by the school where possible, while learning concepts that transfer across interfaces.
Ten common mistakes and why they matter
Treating the written 60% paper as a computer e-exam
K349 Paper 1 is written, unlike K237’s computer-delivered e-exam.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring the Python lab because it is ‘only’ 40%
Paper 2 requires working code and spreadsheets and deserves genuine hands-on preparation.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Preparing Scratch instead of Python
K349’s practical programming uses Python and JupyterLab, not a Scratch-game task.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing K349 and K237 raw marks
K349 has 80 written and 70 practical marks; K237 has 70 e-exam and 80 practical marks.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Writing code without tests
Normal, boundary and erroneous inputs can expose bugs that familiar examples hide.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing string and numeric operations
Types affect results. Convert input only when required and validate expected form.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring fixed widths in two’s complement
A signed binary pattern cannot be interpreted correctly without its number of bits.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Choosing a spreadsheet chart for appearance
Chart type, axes and data selection should answer the question rather than decoration.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Treating any network connection as internet access
A LAN may work when WAN access fails. Use the correct network scope in explanations.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Assuming code that runs is necessarily correct
Logical errors can survive successful execution. Compare observed results to specifications.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Forgetting to save the final artefacts
The lab includes saving time, so a response is incomplete when required files are missing or outdated.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Importing unrestricted Python features
The official syllabus and Python quick-reference guide define examinable concepts and permitted tool expectations; practise within that scope.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
A six-week study sequence
Week 1 — confirm the correct code and environment
Read the K349 table and school guidance. Diagnose concepts, practical fluency, file management and tests separately.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 2 — rebuild core data and network understanding
Practise vocabulary with drawings, comparison cases and short source questions. Explain the difference between storage and memory, or LAN and internet.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 3 — develop spreadsheet reliability
Create formulas, use correct references, select charts and test validation rules. Change the data to check whether the workbook behaves correctly.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 4 — strengthen programming and debugging
Use Python variables, conditions, iterations, list operations and testing. Trace normal and edge cases before executing code.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 5 — perform a simulated paper and lab
Match the syllabus time and mode. For G2 include digital media; for G3 include the required Python and spreadsheet tasks. Practise saving and checking output.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 6 — correct the highest-impact problems
Use an error log to identify recurring mistakes. Retest with fresh inputs, confirm the permitted software and equipment, and protect rest before examinations.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Questions parents can ask without writing code themselves
- What exactly is the task’s input and expected output?
- Which part of the program or spreadsheet makes the important decision?
- What happens when the input is zero, missing or exactly at the limit?
- Can you explain the difference between a wrong answer and an invalid file?
- How did you check whether the formula still works when copied?
- Which software and response mode does the 2027 K349 paper actually require?
- Where is your saved final output, and can you reopen it?
- Can you show me one change you made after testing?
- What would make the system unsafe or unfair to users?
- What new question will prove you understand this skill next week?
Parents should aim to make the learner’s thinking visible, not to provide a prewritten script. A small-group tutor can help by identifying whether a child misunderstood the specification, chose the wrong data structure, wrote incorrect syntax, lost track of a file or simply ran out of time. Each problem needs a different intervention.
In eduKate’s three-student tutorial approach, close observation should lead to targeted feedback and increasing independence. A smaller class by itself is not proof of results. The valuable outcome is that the student can make and explain the next correct decision without prompts, then repeat it on an unfamiliar task.
Frequently asked questions about G3 Computing K349
What is the 2027 G3 Computing code?
K349, with earlier GCE O-Level reference 7155.
How are the papers weighted?
Paper 1 written is 60%; Paper 2 computer lab is 40%.
What are the durations?
Two hours for Paper 1 and two hours thirty minutes for Paper 2.
Is Paper 1 a computer e-exam?
No. The K349 syllabus identifies it as a written examination.
How many Paper 2 tasks are there?
One spreadsheet question and four to five programming questions.
Which programming language is assessed in the lab?
Python, with JupyterLab and spreadsheet software available under the examination arrangements.
Is a Python quick-reference provided?
Yes. The official syllabus says the lab provides a Python quick-reference guide.
Do candidates answer all questions?
Yes. Both papers are compulsory, and all their questions are compulsory.
Can I use an approved calculator?
Yes, under SEAB regulations, though a calculator cannot replace programming skills.
Does Paper 1 include Boolean logic?
Yes. Logic gates, Boolean relationships, binary representation and other computing fundamentals are among the official learning outcomes.
How does K349 differ from K237?
K349 is G3 with written paper and Python lab. K237 is a new G2 entry with e-exam and media, spreadsheet and Scratch practical.
Are the software versions always the same?
Follow SEAB’s current candidate instructions and the examination centre’s approved environment; do not infer exact installed versions from older practice.
Can a learner become ready by memorising Python syntax?
Syntax is necessary but insufficient. The exam also tests analysing problems, checking requirements, designing, testing and debugging.
What happens if I forget to save files?
The lab requires softcopy deliverables, and its duration includes time to save. Rehearse final-file verification.
Does K349 automatically qualify a candidate for a specific computing course?
No. Post-secondary programmes apply their own entry requirements alongside the student’s full subject combination.
SEC grades and future course choices
G3 subject grades run from A1 through grade 9, and E8 or better meets the SEC subject certificate-award threshold. Those thresholds are not the entry requirements for individual JC, polytechnic, ITE or computing programmes. Current admissions rules and the candidate’s full subject combination determine eligibility.
Computing skills also have value outside the examination: managing data carefully, checking algorithms, identifying misleading digital content, communicating findings and protecting information. Students can build those abilities even if they eventually study a different post-secondary subject.
Official SEAB documents and further reading
The structure and content described here were checked against the official 2027 K349 syllabus PDF, 2027 G3 school-candidate syllabus list and SEC overview as available on 11 November 2026. The sample tasks and calculations are independent educational illustrations. Use the latest SEAB candidate instructions for actual software, formats, file submission and examinations.
- G3 K349 syllabus Python and spreadsheet guide
- G3 Computing paper and lab primer
- 2027 G2 versus G3 Computing differences
For the next useful lesson, choose a small unfamiliar problem, state its requirements, predict an output, build the solution and test it against an edge case. Save the final artefact and reopen it. That routine develops the computing judgment the SEC is designed to assess, rather than dependence on a memorised set of clicks.
The subject modules explained through familiar situations
Module 1: computer architecture and storage
A computer is a system of processor, memory, buses, input/output interfaces and secondary storage. Performance and capacity cannot be judged using one specification alone. The syllabus covers data and address buses, USB, HDMI, PCI Express and storage technologies.
A fast processor cannot compensate for a missing required storage device or a program that exceeds available memory. A USB connector type does not automatically guarantee one transfer speed without more information about the supported standard and devices.
Compare two fictional school computers for running data analysis, considering processor, memory, storage and the actual applications being used.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 1: binary, hexadecimal and two’s complement
Digital data is represented using bits. Students convert whole numbers among denary, binary and hexadecimal and use fixed-bit two’s complement representations for signed values. Character encodings explain how text becomes storable data.
The binary pattern 11111101 means different things if interpreted as an unsigned byte or an 8-bit two’s complement signed integer. Representation must be described together with its width and interpretation.
Convert decimal 13 to 8-bit binary 00001101, then explain why one hexadecimal digit represents four binary bits.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 1: Boolean logic and gates
AND, OR, NOT, NAND, NOR and XOR gates represent logical relationships. Boolean statements and logic diagrams can model the same function, and the syllabus includes truth tables, De Morgan’s theorem and up to three input variables.
The XOR result is true when its two inputs differ, unlike OR which can also be true when both inputs are true. Students who interchange these gates will build the wrong logic circuit even if their drawing looks neat.
Make a truth table for a two-input door alarm using OR and then XOR. Compare how the two models respond when both conditions are true.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: decomposition, abstraction and problem specification
A programming solution begins with knowing what the task must do. Decomposition divides it into smaller jobs, while abstraction removes irrelevant details. A good problem specification states valid inputs, outputs, and conditions before code is written.
A student might create an elegant menu for an inventory system before deciding whether quantities can be negative or how duplicate item codes are handled. That order invites preventable errors.
Define inputs and outputs for a library fine calculator, then list invalid inputs and one boundary test before writing code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: Python variables and data types
Python uses names to refer to values, with types that affect how operations behave. Numeric values, text, Boolean values and collections must be handled according to the specified operations and conversions.
The expression `"5" + "2"` produces the string `"52"`, whereas `5 + 2` is numerical addition. A program that fails to convert user input can behave incorrectly even while displaying plausible output.
Write a short trace showing the value and type after `age = int(input())` and explain which inputs would raise an error without validation.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: selection, loops and conditions
Conditional branches choose actions while for and while loops repeat processes. A reliable algorithm must update its state and eventually satisfy any intended stopping condition.
A while loop that never changes the counter tested by its condition may run indefinitely. The syntax may be valid while the logic is wrong. Test a loop with a small number of iterations before scaling it.
Trace a loop that counts from zero to four and state its final counter value. Compare `>` with `>=` on the boundary.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: lists, strings and searching
Programming requires precise indexing, slicing and updating of sequences. Search algorithms can use a sequence of comparisons to locate an item, while simple sorting methods reorder data under defined rules.
A zero-based index does not use position 1 for the first element. Searching for a value not in the list should produce a deliberate not-found outcome, not crash or silently report the last index.
Trace a short list search by hand and use test cases for first element, middle, last and absent values.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: files and program errors
Input/output with files makes software useful beyond one interaction. Programs also need validation, error identification and planned test cases. Syntax, runtime and logic errors are different and require different debugging methods.
A program can run without a syntax error yet produce the wrong answer due to an incorrect formula. A filename error may cause a runtime failure despite otherwise correct calculations. Students should test each step and the data assumptions.
Design three test cases for a simple marks program: normal score, boundary score and invalid text. Record the expected output for each before running.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: algorithms as traceable processes
A good algorithm solves the specified problem in a way that is understandable and testable. Flowcharts and pseudocode help express sequence, selection and iteration before code obscures the reasoning.
A student might understand a sample trace but struggle when data contains duplicates or zero. An algorithm’s assumptions and what it does at boundaries determine whether it is correct.
Create a flowchart for choosing the greatest of three values, then test it with equal numbers as well as distinct ones.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 3: spreadsheet references and logic
Spreadsheets automate repeated calculations, summaries, charting and comparisons. Cell references can be relative or absolute, and conditional functions make decisions based on values. Correctness depends on selecting relevant ranges and handling unusual inputs.
A copied formula may silently refer to the wrong tax-rate cell when the reference is not fixed. Spreadsheet formatting does not prove a calculation is correct, and a tidy chart can still distort a result with poor axes.
Build a two-column budget and a fixed rate in a separate cell. Copy the formula, verify several rows manually and create a chart only after the totals are checked.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 3: validation and useful presentation
A spreadsheet solution should reject invalid input when requirements demand it, use suitable formatting and provide meaningful outputs. Graphs are chosen for communication, not decoration.
A bar chart may be suitable for comparing categories, while a line graph may be more informative for a sequence of time periods. A validation rule that accepts negative stock counts can undermine the entire workbook.
Add data validation to a hypothetical store stock sheet, then test zero, the upper bound and a negative value.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 4: networks and protocols
Networks use devices and communication rules to carry data between computers. A LAN differs from a WAN by scope; IP addressing and related networking concepts support routing across systems. Network design depends on security, reliability and performance requirements.
A working local Wi-Fi connection does not necessarily mean the internet is available. IP and hardware addressing serve different purposes, and a packet may traverse several network devices before reaching its destination.
Sketch a small school network with switches, a router and internet access. Mark where a failure would affect only one classroom or the wider site.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 5: impact and ethics of computing
Computing changes work, services and communications while creating security, privacy, legal and social concerns. Responsible use asks whose data are collected, how systems are secured, how results can be misinterpreted and who is accountable.
An automated decision can be fast and consistent yet unfair or wrong when training data or logic are flawed. A system should protect sensitive information and allow appropriate review; efficiency alone does not prove reliability.
Use an invented school scheduling algorithm and ask what happens if it excludes students without a certain device or network access.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
G3 laboratory technique and JupyterLab workflow
The lab paper expects practical Python coding and spreadsheet work, with digital deliverables saved within the examination period. Students must know how to locate files, execute code cells where relevant, inspect outputs and verify saved versions.
A correct function in a temporary unsaved notebook is not necessarily a submitted answer. Nor is a screenshot a substitute for the required executable file where the task asks for a digital artefact.
Practise a lab run with one spreadsheet and four coding tasks, then reopen saved results to confirm they correspond to the latest code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
G3 compared with G2 Computing
G2 K237 uses a 90-minute e-exam and a 135-minute Scratch/media/spreadsheet lab, 50% each. G3 K349 uses a two-hour written paper and a 150-minute Python/spreadsheet lab, weighted 60% and 40%.
A G3 candidate who only practises Scratch animations is neglecting required Python algorithm design. A G2 candidate who rehearses G3’s two-hour written paper will train the wrong conditions.
Keep a one-page table of the actual paper modes, modules, raw marks, weightings and software appropriate to the student’s registered code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Original worked examples and skill checks
These examples are original teaching exercises, not official specimen-paper questions or licensed software demonstrations. They isolate small decisions for learning; the examination may combine several concepts and demand complete practical files. Practise each example independently and then change the test condition.
Example 1: Binary for decimal 13
Situation and result: Decimal 13 is 8 + 4 + 1, so its binary form is 1101, or 00001101 in an eight-bit field.
Why it works: The sum of powers of two explains the conversion. Leading zeros are useful when the question asks for a fixed width.
Try a fresh condition: Convert 10 to 8-bit binary and check it by adding the weights of set bits.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 2: Two’s complement for negative three
Situation and result: In 8-bit two’s complement, positive 3 is 00000011. Invert to 11111100 and add one to obtain 11111101 for −3.
Why it works: Two’s complement is a signed representation within a specified bit width. Do not confuse this with unsigned value 253.
Try a fresh condition: Represent −1 using the same method and explain why eight bits are required in the example.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 3: XOR versus OR
Situation and result: For inputs A=1 and B=1, OR outputs 1 but XOR outputs 0. When A=1 and B=0, both output 1.
Why it works: The difference is whether exactly one input is true or at least one is true.
Try a fresh condition: Complete the truth tables for all four possible two-input combinations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 4: Python types
Situation and result: In an illustrative Python console, `"5" + "2"` results in `"52"`, while `int("5") + int("2")` results in 7.
Why it works: String concatenation and integer addition are different operations. Input handling must match the requirement.
Try a fresh condition: Test with `"03"` and discuss what is lost or retained after conversion.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 5: A loop trace
Situation and result: Original Python code: `total = 0; for x in [2, 4, 6]: total += x`. The final `total` is 12.
Why it works: The loop iterates over three values, updating the same accumulator each time. A trace table shows totals 2, 6 and 12.
Try a fresh condition: Change the list to [1, 3, 5, 7] and compute the final value without executing code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 6: While-loop boundary
Situation and result: A counter starts at 0. The loop condition is `count < 4` and each iteration adds 1. The loop body executes four times and ends with count 4.
Why it works: The condition is tested before each iteration. The boundary is central to determining the number of repetitions.
Try a fresh condition: Change the comparison to `<= 4` and predict the number of iterations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 7: Search a list
Situation and result: A simple linear search checks [8, 5, 11, 5] for the first occurrence of 5. With zero-based indexing, the answer is index 1.
Why it works: Duplicates mean a search specification should say whether it wants the first, last or all matches. A program cannot be judged correct without that requirement.
Try a fresh condition: Ask for the last occurrence and then for a value not in the list.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 8: A file-processing scenario
Situation and result: A program reads three numeric values from a text file to compute a total. The file may be missing or contain an invalid line.
Why it works: The program must know how to open and read, and the required input format. Testing only a perfect file misses realistic error conditions.
Try a fresh condition: List expected behaviour for a missing file, a blank line and a valid three-line file.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 9: Function design
Situation and result: An illustrative function `def double(x): return 2*x` maps input 6 to output 12.
Why it works: A function describes a reusable computation; naming input and output before implementation clarifies its purpose.
Try a fresh condition: Write a function that returns the square of its input and test negative two.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 10: Spreadsheet fixed tax rate
Situation and result: Cell F1 holds 0.09, B2 contains 100, and `=B2*(1+$F$1)` calculates 109.
Why it works: The absolute reference keeps the rate fixed as the formula is copied to another row. B2 stays relative.
Try a fresh condition: If B3 contains 50, predict the copied calculation result.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 11: A spreadsheet validation range
Situation and result: An assessment spreadsheet allows scores from 0 to 100 inclusive. The correct validation accepts 0 and 100 but rejects −1 and 101.
Why it works: Boundary cases show whether the condition matches the written specification, not only ordinary mid-range inputs.
Try a fresh condition: Specify test values for a percentage input requiring exactly one decimal place.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 12: Network scope
Situation and result: Four computers share a printer through the same building network, while an external online service is temporarily unavailable.
Why it works: Local resource access may continue even when the wider internet connection fails, provided the LAN and printer work.
Try a fresh condition: Identify which devices or links could cause a site-wide external outage.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 13: Data representation and units
Situation and result: A storage calculation uses 1 KiB = 1024 bytes, while 1 kB in decimal convention is 1000 bytes.
Why it works: The prefix convention matters: casually treating them as identical can introduce error in large calculations.
Try a fresh condition: Convert 2 KiB to bytes and compare with 2 kB.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 14: A logic error in a grade rule
Situation and result: A program prints ‘Pass’ for `score > 50`, but the specified rule says a score of at least 50 passes.
Why it works: Input 50 exposes the logic error. The condition should include equality.
Try a fresh condition: Write expected results for 49, 50 and 51 before changing the code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 15: An algorithm with duplicate values
Situation and result: The maximum of [3, 9, 9, 4] is 9. An algorithm that reports a maximum value works, even though two list elements share it.
Why it works: If the specification instead requests the position of the first or last maximum, duplicate handling becomes relevant.
Try a fresh condition: Specify which index should be returned under a first-match rule.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 16: Responsible data use
Situation and result: A school app collects learners’ names and attendance. A proposed feature publicly ranks every learner without consent or clear educational need.
Why it works: Technical feasibility does not make data disclosure appropriate. Privacy, purpose and access controls must be evaluated.
Try a fresh condition: Suggest a less intrusive way to provide teachers with attendance insights.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 17: A JupyterLab save check
Situation and result: A student modifies a Python notebook, reruns a cell and sees correct output, but forgets to save after the final change.
Why it works: A correct visible output does not guarantee the submitted file includes the latest version. Saving and verifying are part of the task.
Try a fresh condition: Design a last-five-minutes checklist for a simulated lab that reopens all required files.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 18: Compare a G2 and G3 task
Situation and result: A G2 practice asks for Scratch sprite behaviour, while a G3 lab problem asks for Python code to process an input list.
Why it works: Both involve computational thinking, but the software and expected deliverables differ. A student should train on the actual syllabus.
Try a fresh condition: Rewrite the game concept as a high-level data-processing requirement and identify which platform suits each paper.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
How to plan, test and debug a computing solution
Start with a plain-language problem statement. Write down the required inputs and outputs, their data types and any permitted ranges. A teacher may specify a spreadsheet that rejects invalid stock counts or a program that returns the first matching item. Those requirements guide implementation more effectively than picking software features at random.
Next decompose the solution: data acquisition, validation, processing, presentation and saving. Describe the relevant relationships before writing code or formulas. This makes it easier to detect a missing step and avoids spending time on decorative formatting while the core result is still wrong.
Test normal cases and boundary cases deliberately. An ordinary mid-range score may pass every condition, while an exact threshold reveals a missing equality sign. Check empty input, repeated values, very small quantities and invalid formats where those cases are relevant to the specification. Record expected results before observing actual ones.
Distinguish syntax errors, runtime problems and logic errors where applicable. A syntax error prevents code from being interpreted correctly; a runtime failure arises during execution; a logic error may generate a plausible but wrong answer. Fixing each requires a different investigation. For spreadsheets, identify whether the issue lies in the selected range, copied reference, data type or chart source.
Finally inspect the deliverable, not only the workspace. The digital lab includes time to save files, and the submitted softcopy must reflect the final work. A correct answer that was never saved may be unavailable to the marking process. Reopen the actual exported or saved file during practice and verify its content against the task.
What an effective mock lab looks like
A good K349 simulation has one spreadsheet task and several Python tasks in a 150-minute working session. Plan solutions, test code in the approved Python/JupyterLab environment, and save every required file. The Python quick-reference guide helps with syntax but does not solve the algorithmic problem.
Set a checklist before beginning: which files are required, where outputs must appear, how calculations will be checked, and how much time remains for verification. This prevents a last-minute scramble to locate a file or export a project that was only saved within the editing application.
Do not claim that any individual home software version is automatically approved for national examinations. The syllabus describes required software categories and the candidate instructions specify the examination environment. Practise in a version and configuration confirmed by the school where possible, while learning concepts that transfer across interfaces.
Ten common mistakes and why they matter
Treating the written 60% paper as a computer e-exam
K349 Paper 1 is written, unlike K237’s computer-delivered e-exam.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring the Python lab because it is ‘only’ 40%
Paper 2 requires working code and spreadsheets and deserves genuine hands-on preparation.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Preparing Scratch instead of Python
K349’s practical programming uses Python and JupyterLab, not a Scratch-game task.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing K349 and K237 raw marks
K349 has 80 written and 70 practical marks; K237 has 70 e-exam and 80 practical marks.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Writing code without tests
Normal, boundary and erroneous inputs can expose bugs that familiar examples hide.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing string and numeric operations
Types affect results. Convert input only when required and validate expected form.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring fixed widths in two’s complement
A signed binary pattern cannot be interpreted correctly without its number of bits.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Choosing a spreadsheet chart for appearance
Chart type, axes and data selection should answer the question rather than decoration.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Treating any network connection as internet access
A LAN may work when WAN access fails. Use the correct network scope in explanations.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Assuming code that runs is necessarily correct
Logical errors can survive successful execution. Compare observed results to specifications.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Forgetting to save the final artefacts
The lab includes saving time, so a response is incomplete when required files are missing or outdated.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Importing unrestricted Python features
The official syllabus and Python quick-reference guide define examinable concepts and permitted tool expectations; practise within that scope.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
A six-week study sequence
Week 1 — confirm the correct code and environment
Read the K349 table and school guidance. Diagnose concepts, practical fluency, file management and tests separately.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 2 — rebuild core data and network understanding
Practise vocabulary with drawings, comparison cases and short source questions. Explain the difference between storage and memory, or LAN and internet.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 3 — develop spreadsheet reliability
Create formulas, use correct references, select charts and test validation rules. Change the data to check whether the workbook behaves correctly.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 4 — strengthen programming and debugging
Use Python variables, conditions, iterations, list operations and testing. Trace normal and edge cases before executing code.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 5 — perform a simulated paper and lab
Match the syllabus time and mode. For G2 include digital media; for G3 include the required Python and spreadsheet tasks. Practise saving and checking output.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 6 — correct the highest-impact problems
Use an error log to identify recurring mistakes. Retest with fresh inputs, confirm the permitted software and equipment, and protect rest before examinations.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Questions parents can ask without writing code themselves
- What exactly is the task’s input and expected output?
- Which part of the program or spreadsheet makes the important decision?
- What happens when the input is zero, missing or exactly at the limit?
- Can you explain the difference between a wrong answer and an invalid file?
- How did you check whether the formula still works when copied?
- Which software and response mode does the 2027 K349 paper actually require?
- Where is your saved final output, and can you reopen it?
- Can you show me one change you made after testing?
- What would make the system unsafe or unfair to users?
- What new question will prove you understand this skill next week?
Parents should aim to make the learner’s thinking visible, not to provide a prewritten script. A small-group tutor can help by identifying whether a child misunderstood the specification, chose the wrong data structure, wrote incorrect syntax, lost track of a file or simply ran out of time. Each problem needs a different intervention.
In eduKate’s three-student tutorial approach, close observation should lead to targeted feedback and increasing independence. A smaller class by itself is not proof of results. The valuable outcome is that the student can make and explain the next correct decision without prompts, then repeat it on an unfamiliar task.
Frequently asked questions about G3 Computing K349
What is the 2027 G3 Computing code?
K349, with earlier GCE O-Level reference 7155.
How are the papers weighted?
Paper 1 written is 60%; Paper 2 computer lab is 40%.
What are the durations?
Two hours for Paper 1 and two hours thirty minutes for Paper 2.
Is Paper 1 a computer e-exam?
No. The K349 syllabus identifies it as a written examination.
How many Paper 2 tasks are there?
One spreadsheet question and four to five programming questions.
Which programming language is assessed in the lab?
Python, with JupyterLab and spreadsheet software available under the examination arrangements.
Is a Python quick-reference provided?
Yes. The official syllabus says the lab provides a Python quick-reference guide.
Do candidates answer all questions?
Yes. Both papers are compulsory, and all their questions are compulsory.
Can I use an approved calculator?
Yes, under SEAB regulations, though a calculator cannot replace programming skills.
Does Paper 1 include Boolean logic?
Yes. Logic gates, Boolean relationships, binary representation and other computing fundamentals are among the official learning outcomes.
How does K349 differ from K237?
K349 is G3 with written paper and Python lab. K237 is a new G2 entry with e-exam and media, spreadsheet and Scratch practical.
Are the software versions always the same?
Follow SEAB’s current candidate instructions and the examination centre’s approved environment; do not infer exact installed versions from older practice.
Can a learner become ready by memorising Python syntax?
Syntax is necessary but insufficient. The exam also tests analysing problems, checking requirements, designing, testing and debugging.
What happens if I forget to save files?
The lab requires softcopy deliverables, and its duration includes time to save. Rehearse final-file verification.
Does K349 automatically qualify a candidate for a specific computing course?
No. Post-secondary programmes apply their own entry requirements alongside the student’s full subject combination.
SEC grades and future course choices
G3 subject grades run from A1 through grade 9, and E8 or better meets the SEC subject certificate-award threshold. Those thresholds are not the entry requirements for individual JC, polytechnic, ITE or computing programmes. Current admissions rules and the candidate’s full subject combination determine eligibility.
Computing skills also have value outside the examination: managing data carefully, checking algorithms, identifying misleading digital content, communicating findings and protecting information. Students can build those abilities even if they eventually study a different post-secondary subject.
Official SEAB documents and further reading
The structure and content described here were checked against the official 2027 K349 syllabus PDF, 2027 G3 school-candidate syllabus list and SEC overview as available on 11 November 2026. The sample tasks and calculations are independent educational illustrations. Use the latest SEAB candidate instructions for actual software, formats, file submission and examinations.
- G3 K349 syllabus Python and spreadsheet guide
- G3 Computing paper and lab primer
- 2027 G2 versus G3 Computing differences
For the next useful lesson, choose a small unfamiliar problem, state its requirements, predict an output, build the solution and test it against an edge case. Save the final artefact and reopen it. That routine develops the computing judgment the SEC is designed to assess, rather than dependence on a memorised set of clicks.
Why does the 2027 SEC Computing syllabus matter?
The Singapore–Cambridge Secondary Education Certificate brings together the former N(T), N(A) and O-Level examinations from the 2027 graduating cohort. Students continue to be examined in individual subjects at approved G-levels. A specific code is therefore essential. Someone searching only for ‘Computing past papers’ might accidentally select G2 K237 materials, which cover a different mix of software, programming language and paper format.
K349 is the G3 SEC code with former reference 7155, which appears in older O-Level materials. The title alone does not confirm that an old workbook matches the 2027 syllabus. Before relying on a source, match its concepts and practical tasks to the published scheme.
Computing is valuable because it teaches learners to describe problems precisely, design processes and test whether a system actually does what it should. Writing a program is one way to demonstrate that skill; setting up a secure network, selecting a suitable data chart or creating a reliable digital artefact also require careful decisions.
The paper structures explained, one at a time
Paper 1: Written Computing
Duration: 2 hours. Raw marks: 80. Weight: 60%. Compulsory questions may include single- and multiple-answer MCQs, short answers, matching, cloze passages and structured tasks, covering all five modules. Relevant formulae are provided. This is a written paper, not the G2 K237 computer-delivered e-exam.
Effective preparation should match the paper rather than simply copying exercises from a general coding tutorial. For a theoretical question, learn to explain concepts and trace small examples on paper. For lab tasks, practise the real application environment, save the expected output and check the produced file. A working result is more informative than a screenshot of someone else’s successful answer.
Paper 2: Python and Spreadsheet Lab
Duration: 2 hours 30 minutes. Raw marks: 70. Weight: 40%. One spreadsheet question and four to five programming questions. The candidate uses a computer with access to spreadsheets, Python and JupyterLab, saves the required outputs and submits softcopies. A Python quick-reference guide is provided for the paper.
Effective preparation should match the paper rather than simply copying exercises from a general coding tutorial. For a theoretical question, learn to explain concepts and trace small examples on paper. For lab tasks, practise the real application environment, save the expected output and check the produced file. A working result is more informative than a screenshot of someone else’s successful answer.
Understanding assessment objectives, not merely marks
K349’s overall assessment grid gives approximately 30% knowledge, 40% application and 30% designing, developing, testing and refining computing solutions. The first paper contributes 60% and the lab paper 40%; elements of application and design can appear across papers.
The assessment percentages describe skills, not the probability that one favourite question will appear. An algorithm may be assessed by tracing its output, proposing a change or producing running code. A spreadsheet idea may appear as a theory question about references and as a live task that must be saved. Students need to understand both versions.
A reliable study session therefore has three parts: explain the idea without opening an application, attempt a new problem under suitable conditions, and check the output against the actual requirements. If an error occurs, identify whether it comes from misunderstanding the problem, the representation, the implementation or the final saved deliverable.
The subject modules explained through familiar situations
Module 1: computer architecture and storage
A computer is a system of processor, memory, buses, input/output interfaces and secondary storage. Performance and capacity cannot be judged using one specification alone. The syllabus covers data and address buses, USB, HDMI, PCI Express and storage technologies.
A fast processor cannot compensate for a missing required storage device or a program that exceeds available memory. A USB connector type does not automatically guarantee one transfer speed without more information about the supported standard and devices.
Compare two fictional school computers for running data analysis, considering processor, memory, storage and the actual applications being used.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 1: binary, hexadecimal and two’s complement
Digital data is represented using bits. Students convert whole numbers among denary, binary and hexadecimal and use fixed-bit two’s complement representations for signed values. Character encodings explain how text becomes storable data.
The binary pattern 11111101 means different things if interpreted as an unsigned byte or an 8-bit two’s complement signed integer. Representation must be described together with its width and interpretation.
Convert decimal 13 to 8-bit binary 00001101, then explain why one hexadecimal digit represents four binary bits.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 1: Boolean logic and gates
AND, OR, NOT, NAND, NOR and XOR gates represent logical relationships. Boolean statements and logic diagrams can model the same function, and the syllabus includes truth tables, De Morgan’s theorem and up to three input variables.
The XOR result is true when its two inputs differ, unlike OR which can also be true when both inputs are true. Students who interchange these gates will build the wrong logic circuit even if their drawing looks neat.
Make a truth table for a two-input door alarm using OR and then XOR. Compare how the two models respond when both conditions are true.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: decomposition, abstraction and problem specification
A programming solution begins with knowing what the task must do. Decomposition divides it into smaller jobs, while abstraction removes irrelevant details. A good problem specification states valid inputs, outputs, and conditions before code is written.
A student might create an elegant menu for an inventory system before deciding whether quantities can be negative or how duplicate item codes are handled. That order invites preventable errors.
Define inputs and outputs for a library fine calculator, then list invalid inputs and one boundary test before writing code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: Python variables and data types
Python uses names to refer to values, with types that affect how operations behave. Numeric values, text, Boolean values and collections must be handled according to the specified operations and conversions.
The expression `"5" + "2"` produces the string `"52"`, whereas `5 + 2` is numerical addition. A program that fails to convert user input can behave incorrectly even while displaying plausible output.
Write a short trace showing the value and type after `age = int(input())` and explain which inputs would raise an error without validation.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: selection, loops and conditions
Conditional branches choose actions while for and while loops repeat processes. A reliable algorithm must update its state and eventually satisfy any intended stopping condition.
A while loop that never changes the counter tested by its condition may run indefinitely. The syntax may be valid while the logic is wrong. Test a loop with a small number of iterations before scaling it.
Trace a loop that counts from zero to four and state its final counter value. Compare `>` with `>=` on the boundary.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: lists, strings and searching
Programming requires precise indexing, slicing and updating of sequences. Search algorithms can use a sequence of comparisons to locate an item, while simple sorting methods reorder data under defined rules.
A zero-based index does not use position 1 for the first element. Searching for a value not in the list should produce a deliberate not-found outcome, not crash or silently report the last index.
Trace a short list search by hand and use test cases for first element, middle, last and absent values.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: files and program errors
Input/output with files makes software useful beyond one interaction. Programs also need validation, error identification and planned test cases. Syntax, runtime and logic errors are different and require different debugging methods.
A program can run without a syntax error yet produce the wrong answer due to an incorrect formula. A filename error may cause a runtime failure despite otherwise correct calculations. Students should test each step and the data assumptions.
Design three test cases for a simple marks program: normal score, boundary score and invalid text. Record the expected output for each before running.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: algorithms as traceable processes
A good algorithm solves the specified problem in a way that is understandable and testable. Flowcharts and pseudocode help express sequence, selection and iteration before code obscures the reasoning.
A student might understand a sample trace but struggle when data contains duplicates or zero. An algorithm’s assumptions and what it does at boundaries determine whether it is correct.
Create a flowchart for choosing the greatest of three values, then test it with equal numbers as well as distinct ones.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 3: spreadsheet references and logic
Spreadsheets automate repeated calculations, summaries, charting and comparisons. Cell references can be relative or absolute, and conditional functions make decisions based on values. Correctness depends on selecting relevant ranges and handling unusual inputs.
A copied formula may silently refer to the wrong tax-rate cell when the reference is not fixed. Spreadsheet formatting does not prove a calculation is correct, and a tidy chart can still distort a result with poor axes.
Build a two-column budget and a fixed rate in a separate cell. Copy the formula, verify several rows manually and create a chart only after the totals are checked.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 3: validation and useful presentation
A spreadsheet solution should reject invalid input when requirements demand it, use suitable formatting and provide meaningful outputs. Graphs are chosen for communication, not decoration.
A bar chart may be suitable for comparing categories, while a line graph may be more informative for a sequence of time periods. A validation rule that accepts negative stock counts can undermine the entire workbook.
Add data validation to a hypothetical store stock sheet, then test zero, the upper bound and a negative value.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 4: networks and protocols
Networks use devices and communication rules to carry data between computers. A LAN differs from a WAN by scope; IP addressing and related networking concepts support routing across systems. Network design depends on security, reliability and performance requirements.
A working local Wi-Fi connection does not necessarily mean the internet is available. IP and hardware addressing serve different purposes, and a packet may traverse several network devices before reaching its destination.
Sketch a small school network with switches, a router and internet access. Mark where a failure would affect only one classroom or the wider site.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 5: impact and ethics of computing
Computing changes work, services and communications while creating security, privacy, legal and social concerns. Responsible use asks whose data are collected, how systems are secured, how results can be misinterpreted and who is accountable.
An automated decision can be fast and consistent yet unfair or wrong when training data or logic are flawed. A system should protect sensitive information and allow appropriate review; efficiency alone does not prove reliability.
Use an invented school scheduling algorithm and ask what happens if it excludes students without a certain device or network access.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
G3 laboratory technique and JupyterLab workflow
The lab paper expects practical Python coding and spreadsheet work, with digital deliverables saved within the examination period. Students must know how to locate files, execute code cells where relevant, inspect outputs and verify saved versions.
A correct function in a temporary unsaved notebook is not necessarily a submitted answer. Nor is a screenshot a substitute for the required executable file where the task asks for a digital artefact.
Practise a lab run with one spreadsheet and four coding tasks, then reopen saved results to confirm they correspond to the latest code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
G3 compared with G2 Computing
G2 K237 uses a 90-minute e-exam and a 135-minute Scratch/media/spreadsheet lab, 50% each. G3 K349 uses a two-hour written paper and a 150-minute Python/spreadsheet lab, weighted 60% and 40%.
A G3 candidate who only practises Scratch animations is neglecting required Python algorithm design. A G2 candidate who rehearses G3’s two-hour written paper will train the wrong conditions.
Keep a one-page table of the actual paper modes, modules, raw marks, weightings and software appropriate to the student’s registered code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Original worked examples and skill checks
These examples are original teaching exercises, not official specimen-paper questions or licensed software demonstrations. They isolate small decisions for learning; the examination may combine several concepts and demand complete practical files. Practise each example independently and then change the test condition.
Example 1: Binary for decimal 13
Situation and result: Decimal 13 is 8 + 4 + 1, so its binary form is 1101, or 00001101 in an eight-bit field.
Why it works: The sum of powers of two explains the conversion. Leading zeros are useful when the question asks for a fixed width.
Try a fresh condition: Convert 10 to 8-bit binary and check it by adding the weights of set bits.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 2: Two’s complement for negative three
Situation and result: In 8-bit two’s complement, positive 3 is 00000011. Invert to 11111100 and add one to obtain 11111101 for −3.
Why it works: Two’s complement is a signed representation within a specified bit width. Do not confuse this with unsigned value 253.
Try a fresh condition: Represent −1 using the same method and explain why eight bits are required in the example.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 3: XOR versus OR
Situation and result: For inputs A=1 and B=1, OR outputs 1 but XOR outputs 0. When A=1 and B=0, both output 1.
Why it works: The difference is whether exactly one input is true or at least one is true.
Try a fresh condition: Complete the truth tables for all four possible two-input combinations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 4: Python types
Situation and result: In an illustrative Python console, `"5" + "2"` results in `"52"`, while `int("5") + int("2")` results in 7.
Why it works: String concatenation and integer addition are different operations. Input handling must match the requirement.
Try a fresh condition: Test with `"03"` and discuss what is lost or retained after conversion.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 5: A loop trace
Situation and result: Original Python code: `total = 0; for x in [2, 4, 6]: total += x`. The final `total` is 12.
Why it works: The loop iterates over three values, updating the same accumulator each time. A trace table shows totals 2, 6 and 12.
Try a fresh condition: Change the list to [1, 3, 5, 7] and compute the final value without executing code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 6: While-loop boundary
Situation and result: A counter starts at 0. The loop condition is `count < 4` and each iteration adds 1. The loop body executes four times and ends with count 4.
Why it works: The condition is tested before each iteration. The boundary is central to determining the number of repetitions.
Try a fresh condition: Change the comparison to `<= 4` and predict the number of iterations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 7: Search a list
Situation and result: A simple linear search checks [8, 5, 11, 5] for the first occurrence of 5. With zero-based indexing, the answer is index 1.
Why it works: Duplicates mean a search specification should say whether it wants the first, last or all matches. A program cannot be judged correct without that requirement.
Try a fresh condition: Ask for the last occurrence and then for a value not in the list.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 8: A file-processing scenario
Situation and result: A program reads three numeric values from a text file to compute a total. The file may be missing or contain an invalid line.
Why it works: The program must know how to open and read, and the required input format. Testing only a perfect file misses realistic error conditions.
Try a fresh condition: List expected behaviour for a missing file, a blank line and a valid three-line file.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 9: Function design
Situation and result: An illustrative function `def double(x): return 2*x` maps input 6 to output 12.
Why it works: A function describes a reusable computation; naming input and output before implementation clarifies its purpose.
Try a fresh condition: Write a function that returns the square of its input and test negative two.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 10: Spreadsheet fixed tax rate
Situation and result: Cell F1 holds 0.09, B2 contains 100, and `=B2*(1+$F$1)` calculates 109.
Why it works: The absolute reference keeps the rate fixed as the formula is copied to another row. B2 stays relative.
Try a fresh condition: If B3 contains 50, predict the copied calculation result.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 11: A spreadsheet validation range
Situation and result: An assessment spreadsheet allows scores from 0 to 100 inclusive. The correct validation accepts 0 and 100 but rejects −1 and 101.
Why it works: Boundary cases show whether the condition matches the written specification, not only ordinary mid-range inputs.
Try a fresh condition: Specify test values for a percentage input requiring exactly one decimal place.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 12: Network scope
Situation and result: Four computers share a printer through the same building network, while an external online service is temporarily unavailable.
Why it works: Local resource access may continue even when the wider internet connection fails, provided the LAN and printer work.
Try a fresh condition: Identify which devices or links could cause a site-wide external outage.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 13: Data representation and units
Situation and result: A storage calculation uses 1 KiB = 1024 bytes, while 1 kB in decimal convention is 1000 bytes.
Why it works: The prefix convention matters: casually treating them as identical can introduce error in large calculations.
Try a fresh condition: Convert 2 KiB to bytes and compare with 2 kB.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 14: A logic error in a grade rule
Situation and result: A program prints ‘Pass’ for `score > 50`, but the specified rule says a score of at least 50 passes.
Why it works: Input 50 exposes the logic error. The condition should include equality.
Try a fresh condition: Write expected results for 49, 50 and 51 before changing the code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 15: An algorithm with duplicate values
Situation and result: The maximum of [3, 9, 9, 4] is 9. An algorithm that reports a maximum value works, even though two list elements share it.
Why it works: If the specification instead requests the position of the first or last maximum, duplicate handling becomes relevant.
Try a fresh condition: Specify which index should be returned under a first-match rule.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 16: Responsible data use
Situation and result: A school app collects learners’ names and attendance. A proposed feature publicly ranks every learner without consent or clear educational need.
Why it works: Technical feasibility does not make data disclosure appropriate. Privacy, purpose and access controls must be evaluated.
Try a fresh condition: Suggest a less intrusive way to provide teachers with attendance insights.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 17: A JupyterLab save check
Situation and result: A student modifies a Python notebook, reruns a cell and sees correct output, but forgets to save after the final change.
Why it works: A correct visible output does not guarantee the submitted file includes the latest version. Saving and verifying are part of the task.
Try a fresh condition: Design a last-five-minutes checklist for a simulated lab that reopens all required files.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 18: Compare a G2 and G3 task
Situation and result: A G2 practice asks for Scratch sprite behaviour, while a G3 lab problem asks for Python code to process an input list.
Why it works: Both involve computational thinking, but the software and expected deliverables differ. A student should train on the actual syllabus.
Try a fresh condition: Rewrite the game concept as a high-level data-processing requirement and identify which platform suits each paper.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
How to plan, test and debug a computing solution
Start with a plain-language problem statement. Write down the required inputs and outputs, their data types and any permitted ranges. A teacher may specify a spreadsheet that rejects invalid stock counts or a program that returns the first matching item. Those requirements guide implementation more effectively than picking software features at random.
Next decompose the solution: data acquisition, validation, processing, presentation and saving. Describe the relevant relationships before writing code or formulas. This makes it easier to detect a missing step and avoids spending time on decorative formatting while the core result is still wrong.
Test normal cases and boundary cases deliberately. An ordinary mid-range score may pass every condition, while an exact threshold reveals a missing equality sign. Check empty input, repeated values, very small quantities and invalid formats where those cases are relevant to the specification. Record expected results before observing actual ones.
Distinguish syntax errors, runtime problems and logic errors where applicable. A syntax error prevents code from being interpreted correctly; a runtime failure arises during execution; a logic error may generate a plausible but wrong answer. Fixing each requires a different investigation. For spreadsheets, identify whether the issue lies in the selected range, copied reference, data type or chart source.
Finally inspect the deliverable, not only the workspace. The digital lab includes time to save files, and the submitted softcopy must reflect the final work. A correct answer that was never saved may be unavailable to the marking process. Reopen the actual exported or saved file during practice and verify its content against the task.
What an effective mock lab looks like
A good K349 simulation has one spreadsheet task and several Python tasks in a 150-minute working session. Plan solutions, test code in the approved Python/JupyterLab environment, and save every required file. The Python quick-reference guide helps with syntax but does not solve the algorithmic problem.
Set a checklist before beginning: which files are required, where outputs must appear, how calculations will be checked, and how much time remains for verification. This prevents a last-minute scramble to locate a file or export a project that was only saved within the editing application.
Do not claim that any individual home software version is automatically approved for national examinations. The syllabus describes required software categories and the candidate instructions specify the examination environment. Practise in a version and configuration confirmed by the school where possible, while learning concepts that transfer across interfaces.
Ten common mistakes and why they matter
Treating the written 60% paper as a computer e-exam
K349 Paper 1 is written, unlike K237’s computer-delivered e-exam.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring the Python lab because it is ‘only’ 40%
Paper 2 requires working code and spreadsheets and deserves genuine hands-on preparation.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Preparing Scratch instead of Python
K349’s practical programming uses Python and JupyterLab, not a Scratch-game task.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing K349 and K237 raw marks
K349 has 80 written and 70 practical marks; K237 has 70 e-exam and 80 practical marks.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Writing code without tests
Normal, boundary and erroneous inputs can expose bugs that familiar examples hide.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing string and numeric operations
Types affect results. Convert input only when required and validate expected form.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring fixed widths in two’s complement
A signed binary pattern cannot be interpreted correctly without its number of bits.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Choosing a spreadsheet chart for appearance
Chart type, axes and data selection should answer the question rather than decoration.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Treating any network connection as internet access
A LAN may work when WAN access fails. Use the correct network scope in explanations.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Assuming code that runs is necessarily correct
Logical errors can survive successful execution. Compare observed results to specifications.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Forgetting to save the final artefacts
The lab includes saving time, so a response is incomplete when required files are missing or outdated.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Importing unrestricted Python features
The official syllabus and Python quick-reference guide define examinable concepts and permitted tool expectations; practise within that scope.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
A six-week study sequence
Week 1 — confirm the correct code and environment
Read the K349 table and school guidance. Diagnose concepts, practical fluency, file management and tests separately.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 2 — rebuild core data and network understanding
Practise vocabulary with drawings, comparison cases and short source questions. Explain the difference between storage and memory, or LAN and internet.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 3 — develop spreadsheet reliability
Create formulas, use correct references, select charts and test validation rules. Change the data to check whether the workbook behaves correctly.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 4 — strengthen programming and debugging
Use Python variables, conditions, iterations, list operations and testing. Trace normal and edge cases before executing code.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 5 — perform a simulated paper and lab
Match the syllabus time and mode. For G2 include digital media; for G3 include the required Python and spreadsheet tasks. Practise saving and checking output.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 6 — correct the highest-impact problems
Use an error log to identify recurring mistakes. Retest with fresh inputs, confirm the permitted software and equipment, and protect rest before examinations.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Questions parents can ask without writing code themselves
- What exactly is the task’s input and expected output?
- Which part of the program or spreadsheet makes the important decision?
- What happens when the input is zero, missing or exactly at the limit?
- Can you explain the difference between a wrong answer and an invalid file?
- How did you check whether the formula still works when copied?
- Which software and response mode does the 2027 K349 paper actually require?
- Where is your saved final output, and can you reopen it?
- Can you show me one change you made after testing?
- What would make the system unsafe or unfair to users?
- What new question will prove you understand this skill next week?
Parents should aim to make the learner’s thinking visible, not to provide a prewritten script. A small-group tutor can help by identifying whether a child misunderstood the specification, chose the wrong data structure, wrote incorrect syntax, lost track of a file or simply ran out of time. Each problem needs a different intervention.
In eduKate’s three-student tutorial approach, close observation should lead to targeted feedback and increasing independence. A smaller class by itself is not proof of results. The valuable outcome is that the student can make and explain the next correct decision without prompts, then repeat it on an unfamiliar task.
Frequently asked questions about G3 Computing K349
What is the 2027 G3 Computing code?
K349, with earlier GCE O-Level reference 7155.
How are the papers weighted?
Paper 1 written is 60%; Paper 2 computer lab is 40%.
What are the durations?
Two hours for Paper 1 and two hours thirty minutes for Paper 2.
Is Paper 1 a computer e-exam?
No. The K349 syllabus identifies it as a written examination.
How many Paper 2 tasks are there?
One spreadsheet question and four to five programming questions.
Which programming language is assessed in the lab?
Python, with JupyterLab and spreadsheet software available under the examination arrangements.
Is a Python quick-reference provided?
Yes. The official syllabus says the lab provides a Python quick-reference guide.
Do candidates answer all questions?
Yes. Both papers are compulsory, and all their questions are compulsory.
Can I use an approved calculator?
Yes, under SEAB regulations, though a calculator cannot replace programming skills.
Does Paper 1 include Boolean logic?
Yes. Logic gates, Boolean relationships, binary representation and other computing fundamentals are among the official learning outcomes.
How does K349 differ from K237?
K349 is G3 with written paper and Python lab. K237 is a new G2 entry with e-exam and media, spreadsheet and Scratch practical.
Are the software versions always the same?
Follow SEAB’s current candidate instructions and the examination centre’s approved environment; do not infer exact installed versions from older practice.
Can a learner become ready by memorising Python syntax?
Syntax is necessary but insufficient. The exam also tests analysing problems, checking requirements, designing, testing and debugging.
What happens if I forget to save files?
The lab requires softcopy deliverables, and its duration includes time to save. Rehearse final-file verification.
Does K349 automatically qualify a candidate for a specific computing course?
No. Post-secondary programmes apply their own entry requirements alongside the student’s full subject combination.
SEC grades and future course choices
G3 subject grades run from A1 through grade 9, and E8 or better meets the SEC subject certificate-award threshold. Those thresholds are not the entry requirements for individual JC, polytechnic, ITE or computing programmes. Current admissions rules and the candidate’s full subject combination determine eligibility.
Computing skills also have value outside the examination: managing data carefully, checking algorithms, identifying misleading digital content, communicating findings and protecting information. Students can build those abilities even if they eventually study a different post-secondary subject.
Official SEAB documents and further reading
The structure and content described here were checked against the official 2027 K349 syllabus PDF, 2027 G3 school-candidate syllabus list and SEC overview as available on 11 November 2026. The sample tasks and calculations are independent educational illustrations. Use the latest SEAB candidate instructions for actual software, formats, file submission and examinations.
- G3 K349 syllabus Python and spreadsheet guide
- G3 Computing paper and lab primer
- 2027 G2 versus G3 Computing differences
For the next useful lesson, choose a small unfamiliar problem, state its requirements, predict an output, build the solution and test it against an edge case. Save the final artefact and reopen it. That routine develops the computing judgment the SEC is designed to assess, rather than dependence on a memorised set of clicks.
What is SEC Examinations | G3 Computing (SEAB K349)? G3 Computing K349 is the 2027 Singapore–Cambridge SEC subject that develops a deeper understanding of computer systems, algorithms, programming, spreadsheets, networks and the impact of computing. Students need to design, trace, test and debug actual solutions using logical reasoning. The paper structure differs from the new G2 K237 subject: G3 Computing uses a written examination and a Python-based laboratory examination.
What parents and students need to know first: K349 has two compulsory papers. Paper 1 is a 2-hour written paper of 80 marks and 60% overall; its five modules include Computing Fundamentals, Algorithms and Programming, Spreadsheets, Networking and Impact of Computing. Paper 2 is a 2-hour-30-minute lab with Python, JupyterLab and spreadsheet software, worth 70 marks and 40%. The lab has one spreadsheet question and four or five programming questions. A Python quick-reference guide is provided, and time for saving required files is included.
- 2027 SEC level: G3.
- Official code: K349; earlier reference 7155.
- Paper 1: Written Computing: 80 marks, 60%, 2 hours.
- Paper 2: Python and Spreadsheet Lab: 70 marks, 40%, 2 hours 30 minutes.
- All questions: compulsory in both papers.
- Official syllabus: SEAB K349 2027 PDF.
- School subject list: SEAB 2027 G3 examination subjects.
- First action: confirm the student’s correct code, exam software and component requirements.
Why does the 2027 SEC Computing syllabus matter?
The Singapore–Cambridge Secondary Education Certificate brings together the former N(T), N(A) and O-Level examinations from the 2027 graduating cohort. Students continue to be examined in individual subjects at approved G-levels. A specific code is therefore essential. Someone searching only for ‘Computing past papers’ might accidentally select G2 K237 materials, which cover a different mix of software, programming language and paper format.
K349 is the G3 SEC code with former reference 7155, which appears in older O-Level materials. The title alone does not confirm that an old workbook matches the 2027 syllabus. Before relying on a source, match its concepts and practical tasks to the published scheme.
Computing is valuable because it teaches learners to describe problems precisely, design processes and test whether a system actually does what it should. Writing a program is one way to demonstrate that skill; setting up a secure network, selecting a suitable data chart or creating a reliable digital artefact also require careful decisions.
The paper structures explained, one at a time
Paper 1: Written Computing
Duration: 2 hours. Raw marks: 80. Weight: 60%. Compulsory questions may include single- and multiple-answer MCQs, short answers, matching, cloze passages and structured tasks, covering all five modules. Relevant formulae are provided. This is a written paper, not the G2 K237 computer-delivered e-exam.
Effective preparation should match the paper rather than simply copying exercises from a general coding tutorial. For a theoretical question, learn to explain concepts and trace small examples on paper. For lab tasks, practise the real application environment, save the expected output and check the produced file. A working result is more informative than a screenshot of someone else’s successful answer.
Paper 2: Python and Spreadsheet Lab
Duration: 2 hours 30 minutes. Raw marks: 70. Weight: 40%. One spreadsheet question and four to five programming questions. The candidate uses a computer with access to spreadsheets, Python and JupyterLab, saves the required outputs and submits softcopies. A Python quick-reference guide is provided for the paper.
Effective preparation should match the paper rather than simply copying exercises from a general coding tutorial. For a theoretical question, learn to explain concepts and trace small examples on paper. For lab tasks, practise the real application environment, save the expected output and check the produced file. A working result is more informative than a screenshot of someone else’s successful answer.
Understanding assessment objectives, not merely marks
K349’s overall assessment grid gives approximately 30% knowledge, 40% application and 30% designing, developing, testing and refining computing solutions. The first paper contributes 60% and the lab paper 40%; elements of application and design can appear across papers.
The assessment percentages describe skills, not the probability that one favourite question will appear. An algorithm may be assessed by tracing its output, proposing a change or producing running code. A spreadsheet idea may appear as a theory question about references and as a live task that must be saved. Students need to understand both versions.
A reliable study session therefore has three parts: explain the idea without opening an application, attempt a new problem under suitable conditions, and check the output against the actual requirements. If an error occurs, identify whether it comes from misunderstanding the problem, the representation, the implementation or the final saved deliverable.
The subject modules explained through familiar situations
Module 1: computer architecture and storage
A computer is a system of processor, memory, buses, input/output interfaces and secondary storage. Performance and capacity cannot be judged using one specification alone. The syllabus covers data and address buses, USB, HDMI, PCI Express and storage technologies.
A fast processor cannot compensate for a missing required storage device or a program that exceeds available memory. A USB connector type does not automatically guarantee one transfer speed without more information about the supported standard and devices.
Compare two fictional school computers for running data analysis, considering processor, memory, storage and the actual applications being used.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 1: binary, hexadecimal and two’s complement
Digital data is represented using bits. Students convert whole numbers among denary, binary and hexadecimal and use fixed-bit two’s complement representations for signed values. Character encodings explain how text becomes storable data.
The binary pattern 11111101 means different things if interpreted as an unsigned byte or an 8-bit two’s complement signed integer. Representation must be described together with its width and interpretation.
Convert decimal 13 to 8-bit binary 00001101, then explain why one hexadecimal digit represents four binary bits.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 1: Boolean logic and gates
AND, OR, NOT, NAND, NOR and XOR gates represent logical relationships. Boolean statements and logic diagrams can model the same function, and the syllabus includes truth tables, De Morgan’s theorem and up to three input variables.
The XOR result is true when its two inputs differ, unlike OR which can also be true when both inputs are true. Students who interchange these gates will build the wrong logic circuit even if their drawing looks neat.
Make a truth table for a two-input door alarm using OR and then XOR. Compare how the two models respond when both conditions are true.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: decomposition, abstraction and problem specification
A programming solution begins with knowing what the task must do. Decomposition divides it into smaller jobs, while abstraction removes irrelevant details. A good problem specification states valid inputs, outputs, and conditions before code is written.
A student might create an elegant menu for an inventory system before deciding whether quantities can be negative or how duplicate item codes are handled. That order invites preventable errors.
Define inputs and outputs for a library fine calculator, then list invalid inputs and one boundary test before writing code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: Python variables and data types
Python uses names to refer to values, with types that affect how operations behave. Numeric values, text, Boolean values and collections must be handled according to the specified operations and conversions.
The expression `"5" + "2"` produces the string `"52"`, whereas `5 + 2` is numerical addition. A program that fails to convert user input can behave incorrectly even while displaying plausible output.
Write a short trace showing the value and type after `age = int(input())` and explain which inputs would raise an error without validation.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: selection, loops and conditions
Conditional branches choose actions while for and while loops repeat processes. A reliable algorithm must update its state and eventually satisfy any intended stopping condition.
A while loop that never changes the counter tested by its condition may run indefinitely. The syntax may be valid while the logic is wrong. Test a loop with a small number of iterations before scaling it.
Trace a loop that counts from zero to four and state its final counter value. Compare `>` with `>=` on the boundary.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: lists, strings and searching
Programming requires precise indexing, slicing and updating of sequences. Search algorithms can use a sequence of comparisons to locate an item, while simple sorting methods reorder data under defined rules.
A zero-based index does not use position 1 for the first element. Searching for a value not in the list should produce a deliberate not-found outcome, not crash or silently report the last index.
Trace a short list search by hand and use test cases for first element, middle, last and absent values.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: files and program errors
Input/output with files makes software useful beyond one interaction. Programs also need validation, error identification and planned test cases. Syntax, runtime and logic errors are different and require different debugging methods.
A program can run without a syntax error yet produce the wrong answer due to an incorrect formula. A filename error may cause a runtime failure despite otherwise correct calculations. Students should test each step and the data assumptions.
Design three test cases for a simple marks program: normal score, boundary score and invalid text. Record the expected output for each before running.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 2: algorithms as traceable processes
A good algorithm solves the specified problem in a way that is understandable and testable. Flowcharts and pseudocode help express sequence, selection and iteration before code obscures the reasoning.
A student might understand a sample trace but struggle when data contains duplicates or zero. An algorithm’s assumptions and what it does at boundaries determine whether it is correct.
Create a flowchart for choosing the greatest of three values, then test it with equal numbers as well as distinct ones.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 3: spreadsheet references and logic
Spreadsheets automate repeated calculations, summaries, charting and comparisons. Cell references can be relative or absolute, and conditional functions make decisions based on values. Correctness depends on selecting relevant ranges and handling unusual inputs.
A copied formula may silently refer to the wrong tax-rate cell when the reference is not fixed. Spreadsheet formatting does not prove a calculation is correct, and a tidy chart can still distort a result with poor axes.
Build a two-column budget and a fixed rate in a separate cell. Copy the formula, verify several rows manually and create a chart only after the totals are checked.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 3: validation and useful presentation
A spreadsheet solution should reject invalid input when requirements demand it, use suitable formatting and provide meaningful outputs. Graphs are chosen for communication, not decoration.
A bar chart may be suitable for comparing categories, while a line graph may be more informative for a sequence of time periods. A validation rule that accepts negative stock counts can undermine the entire workbook.
Add data validation to a hypothetical store stock sheet, then test zero, the upper bound and a negative value.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 4: networks and protocols
Networks use devices and communication rules to carry data between computers. A LAN differs from a WAN by scope; IP addressing and related networking concepts support routing across systems. Network design depends on security, reliability and performance requirements.
A working local Wi-Fi connection does not necessarily mean the internet is available. IP and hardware addressing serve different purposes, and a packet may traverse several network devices before reaching its destination.
Sketch a small school network with switches, a router and internet access. Mark where a failure would affect only one classroom or the wider site.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Module 5: impact and ethics of computing
Computing changes work, services and communications while creating security, privacy, legal and social concerns. Responsible use asks whose data are collected, how systems are secured, how results can be misinterpreted and who is accountable.
An automated decision can be fast and consistent yet unfair or wrong when training data or logic are flawed. A system should protect sensitive information and allow appropriate review; efficiency alone does not prove reliability.
Use an invented school scheduling algorithm and ask what happens if it excludes students without a certain device or network access.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
G3 laboratory technique and JupyterLab workflow
The lab paper expects practical Python coding and spreadsheet work, with digital deliverables saved within the examination period. Students must know how to locate files, execute code cells where relevant, inspect outputs and verify saved versions.
A correct function in a temporary unsaved notebook is not necessarily a submitted answer. Nor is a screenshot a substitute for the required executable file where the task asks for a digital artefact.
Practise a lab run with one spreadsheet and four coding tasks, then reopen saved results to confirm they correspond to the latest code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
G3 compared with G2 Computing
G2 K237 uses a 90-minute e-exam and a 135-minute Scratch/media/spreadsheet lab, 50% each. G3 K349 uses a two-hour written paper and a 150-minute Python/spreadsheet lab, weighted 60% and 40%.
A G3 candidate who only practises Scratch animations is neglecting required Python algorithm design. A G2 candidate who rehearses G3’s two-hour written paper will train the wrong conditions.
Keep a one-page table of the actual paper modes, modules, raw marks, weightings and software appropriate to the student’s registered code.
A good diagnostic asks the learner to identify the input, the processing or decision step, the expected output and one plausible failure. If the result changes when a condition or data item changes, the explanation should change with it. That is evidence of computational thinking rather than recognition of a copied interface.
Original worked examples and skill checks
These examples are original teaching exercises, not official specimen-paper questions or licensed software demonstrations. They isolate small decisions for learning; the examination may combine several concepts and demand complete practical files. Practise each example independently and then change the test condition.
Example 1: Binary for decimal 13
Situation and result: Decimal 13 is 8 + 4 + 1, so its binary form is 1101, or 00001101 in an eight-bit field.
Why it works: The sum of powers of two explains the conversion. Leading zeros are useful when the question asks for a fixed width.
Try a fresh condition: Convert 10 to 8-bit binary and check it by adding the weights of set bits.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 2: Two’s complement for negative three
Situation and result: In 8-bit two’s complement, positive 3 is 00000011. Invert to 11111100 and add one to obtain 11111101 for −3.
Why it works: Two’s complement is a signed representation within a specified bit width. Do not confuse this with unsigned value 253.
Try a fresh condition: Represent −1 using the same method and explain why eight bits are required in the example.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 3: XOR versus OR
Situation and result: For inputs A=1 and B=1, OR outputs 1 but XOR outputs 0. When A=1 and B=0, both output 1.
Why it works: The difference is whether exactly one input is true or at least one is true.
Try a fresh condition: Complete the truth tables for all four possible two-input combinations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 4: Python types
Situation and result: In an illustrative Python console, `"5" + "2"` results in `"52"`, while `int("5") + int("2")` results in 7.
Why it works: String concatenation and integer addition are different operations. Input handling must match the requirement.
Try a fresh condition: Test with `"03"` and discuss what is lost or retained after conversion.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 5: A loop trace
Situation and result: Original Python code: `total = 0; for x in [2, 4, 6]: total += x`. The final `total` is 12.
Why it works: The loop iterates over three values, updating the same accumulator each time. A trace table shows totals 2, 6 and 12.
Try a fresh condition: Change the list to [1, 3, 5, 7] and compute the final value without executing code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 6: While-loop boundary
Situation and result: A counter starts at 0. The loop condition is `count < 4` and each iteration adds 1. The loop body executes four times and ends with count 4.
Why it works: The condition is tested before each iteration. The boundary is central to determining the number of repetitions.
Try a fresh condition: Change the comparison to `<= 4` and predict the number of iterations.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 7: Search a list
Situation and result: A simple linear search checks [8, 5, 11, 5] for the first occurrence of 5. With zero-based indexing, the answer is index 1.
Why it works: Duplicates mean a search specification should say whether it wants the first, last or all matches. A program cannot be judged correct without that requirement.
Try a fresh condition: Ask for the last occurrence and then for a value not in the list.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 8: A file-processing scenario
Situation and result: A program reads three numeric values from a text file to compute a total. The file may be missing or contain an invalid line.
Why it works: The program must know how to open and read, and the required input format. Testing only a perfect file misses realistic error conditions.
Try a fresh condition: List expected behaviour for a missing file, a blank line and a valid three-line file.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 9: Function design
Situation and result: An illustrative function `def double(x): return 2*x` maps input 6 to output 12.
Why it works: A function describes a reusable computation; naming input and output before implementation clarifies its purpose.
Try a fresh condition: Write a function that returns the square of its input and test negative two.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 10: Spreadsheet fixed tax rate
Situation and result: Cell F1 holds 0.09, B2 contains 100, and `=B2*(1+$F$1)` calculates 109.
Why it works: The absolute reference keeps the rate fixed as the formula is copied to another row. B2 stays relative.
Try a fresh condition: If B3 contains 50, predict the copied calculation result.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 11: A spreadsheet validation range
Situation and result: An assessment spreadsheet allows scores from 0 to 100 inclusive. The correct validation accepts 0 and 100 but rejects −1 and 101.
Why it works: Boundary cases show whether the condition matches the written specification, not only ordinary mid-range inputs.
Try a fresh condition: Specify test values for a percentage input requiring exactly one decimal place.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 12: Network scope
Situation and result: Four computers share a printer through the same building network, while an external online service is temporarily unavailable.
Why it works: Local resource access may continue even when the wider internet connection fails, provided the LAN and printer work.
Try a fresh condition: Identify which devices or links could cause a site-wide external outage.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 13: Data representation and units
Situation and result: A storage calculation uses 1 KiB = 1024 bytes, while 1 kB in decimal convention is 1000 bytes.
Why it works: The prefix convention matters: casually treating them as identical can introduce error in large calculations.
Try a fresh condition: Convert 2 KiB to bytes and compare with 2 kB.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 14: A logic error in a grade rule
Situation and result: A program prints ‘Pass’ for `score > 50`, but the specified rule says a score of at least 50 passes.
Why it works: Input 50 exposes the logic error. The condition should include equality.
Try a fresh condition: Write expected results for 49, 50 and 51 before changing the code.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 15: An algorithm with duplicate values
Situation and result: The maximum of [3, 9, 9, 4] is 9. An algorithm that reports a maximum value works, even though two list elements share it.
Why it works: If the specification instead requests the position of the first or last maximum, duplicate handling becomes relevant.
Try a fresh condition: Specify which index should be returned under a first-match rule.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 16: Responsible data use
Situation and result: A school app collects learners’ names and attendance. A proposed feature publicly ranks every learner without consent or clear educational need.
Why it works: Technical feasibility does not make data disclosure appropriate. Privacy, purpose and access controls must be evaluated.
Try a fresh condition: Suggest a less intrusive way to provide teachers with attendance insights.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 17: A JupyterLab save check
Situation and result: A student modifies a Python notebook, reruns a cell and sees correct output, but forgets to save after the final change.
Why it works: A correct visible output does not guarantee the submitted file includes the latest version. Saving and verifying are part of the task.
Try a fresh condition: Design a last-five-minutes checklist for a simulated lab that reopens all required files.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
Example 18: Compare a G2 and G3 task
Situation and result: A G2 practice asks for Scratch sprite behaviour, while a G3 lab problem asks for Python code to process an input list.
Why it works: Both involve computational thinking, but the software and expected deliverables differ. A student should train on the actual syllabus.
Try a fresh condition: Rewrite the game concept as a high-level data-processing requirement and identify which platform suits each paper.
After reading the explanation, hide it and ask the student to predict the output or decision before running software. Record whether the output matches the prediction. If it fails, find the first incorrect assumption, repair it and retest. This turns an error into a small experiment rather than a reason to memorise the answer.
How to plan, test and debug a computing solution
Start with a plain-language problem statement. Write down the required inputs and outputs, their data types and any permitted ranges. A teacher may specify a spreadsheet that rejects invalid stock counts or a program that returns the first matching item. Those requirements guide implementation more effectively than picking software features at random.
Next decompose the solution: data acquisition, validation, processing, presentation and saving. Describe the relevant relationships before writing code or formulas. This makes it easier to detect a missing step and avoids spending time on decorative formatting while the core result is still wrong.
Test normal cases and boundary cases deliberately. An ordinary mid-range score may pass every condition, while an exact threshold reveals a missing equality sign. Check empty input, repeated values, very small quantities and invalid formats where those cases are relevant to the specification. Record expected results before observing actual ones.
Distinguish syntax errors, runtime problems and logic errors where applicable. A syntax error prevents code from being interpreted correctly; a runtime failure arises during execution; a logic error may generate a plausible but wrong answer. Fixing each requires a different investigation. For spreadsheets, identify whether the issue lies in the selected range, copied reference, data type or chart source.
Finally inspect the deliverable, not only the workspace. The digital lab includes time to save files, and the submitted softcopy must reflect the final work. A correct answer that was never saved may be unavailable to the marking process. Reopen the actual exported or saved file during practice and verify its content against the task.
What an effective mock lab looks like
A good K349 simulation has one spreadsheet task and several Python tasks in a 150-minute working session. Plan solutions, test code in the approved Python/JupyterLab environment, and save every required file. The Python quick-reference guide helps with syntax but does not solve the algorithmic problem.
Set a checklist before beginning: which files are required, where outputs must appear, how calculations will be checked, and how much time remains for verification. This prevents a last-minute scramble to locate a file or export a project that was only saved within the editing application.
Do not claim that any individual home software version is automatically approved for national examinations. The syllabus describes required software categories and the candidate instructions specify the examination environment. Practise in a version and configuration confirmed by the school where possible, while learning concepts that transfer across interfaces.
Ten common mistakes and why they matter
Treating the written 60% paper as a computer e-exam
K349 Paper 1 is written, unlike K237’s computer-delivered e-exam.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring the Python lab because it is ‘only’ 40%
Paper 2 requires working code and spreadsheets and deserves genuine hands-on preparation.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Preparing Scratch instead of Python
K349’s practical programming uses Python and JupyterLab, not a Scratch-game task.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing K349 and K237 raw marks
K349 has 80 written and 70 practical marks; K237 has 70 e-exam and 80 practical marks.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Writing code without tests
Normal, boundary and erroneous inputs can expose bugs that familiar examples hide.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Confusing string and numeric operations
Types affect results. Convert input only when required and validate expected form.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Ignoring fixed widths in two’s complement
A signed binary pattern cannot be interpreted correctly without its number of bits.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Choosing a spreadsheet chart for appearance
Chart type, axes and data selection should answer the question rather than decoration.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Treating any network connection as internet access
A LAN may work when WAN access fails. Use the correct network scope in explanations.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Assuming code that runs is necessarily correct
Logical errors can survive successful execution. Compare observed results to specifications.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Forgetting to save the final artefacts
The lab includes saving time, so a response is incomplete when required files are missing or outdated.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
Importing unrestricted Python features
The official syllabus and Python quick-reference guide define examinable concepts and permitted tool expectations; practise within that scope.
The correction is to locate the first failed decision and test it on new data. A learner should be able to explain what went wrong and why the revised solution is valid. Simply pressing Run again or copying a formula without checking references may hide the original misunderstanding.
A six-week study sequence
Week 1 — confirm the correct code and environment
Read the K349 table and school guidance. Diagnose concepts, practical fluency, file management and tests separately.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 2 — rebuild core data and network understanding
Practise vocabulary with drawings, comparison cases and short source questions. Explain the difference between storage and memory, or LAN and internet.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 3 — develop spreadsheet reliability
Create formulas, use correct references, select charts and test validation rules. Change the data to check whether the workbook behaves correctly.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 4 — strengthen programming and debugging
Use Python variables, conditions, iterations, list operations and testing. Trace normal and edge cases before executing code.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 5 — perform a simulated paper and lab
Match the syllabus time and mode. For G2 include digital media; for G3 include the required Python and spreadsheet tasks. Practise saving and checking output.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Week 6 — correct the highest-impact problems
Use an error log to identify recurring mistakes. Retest with fresh inputs, confirm the permitted software and equipment, and protect rest before examinations.
A useful weekly measure is whether a student can explain the problem, predict the expected output and verify a fresh result unaided. A full folder of copied projects does not show that these independent decisions have been learnt.
Questions parents can ask without writing code themselves
- What exactly is the task’s input and expected output?
- Which part of the program or spreadsheet makes the important decision?
- What happens when the input is zero, missing or exactly at the limit?
- Can you explain the difference between a wrong answer and an invalid file?
- How did you check whether the formula still works when copied?
- Which software and response mode does the 2027 K349 paper actually require?
- Where is your saved final output, and can you reopen it?
- Can you show me one change you made after testing?
- What would make the system unsafe or unfair to users?
- What new question will prove you understand this skill next week?
Parents should aim to make the learner’s thinking visible, not to provide a prewritten script. A small-group tutor can help by identifying whether a child misunderstood the specification, chose the wrong data structure, wrote incorrect syntax, lost track of a file or simply ran out of time. Each problem needs a different intervention.
In eduKate’s three-student tutorial approach, close observation should lead to targeted feedback and increasing independence. A smaller class by itself is not proof of results. The valuable outcome is that the student can make and explain the next correct decision without prompts, then repeat it on an unfamiliar task.
Frequently asked questions about G3 Computing K349
What is the 2027 G3 Computing code?
K349, with earlier GCE O-Level reference 7155.
How are the papers weighted?
Paper 1 written is 60%; Paper 2 computer lab is 40%.
What are the durations?
Two hours for Paper 1 and two hours thirty minutes for Paper 2.
Is Paper 1 a computer e-exam?
No. The K349 syllabus identifies it as a written examination.
How many Paper 2 tasks are there?
One spreadsheet question and four to five programming questions.
Which programming language is assessed in the lab?
Python, with JupyterLab and spreadsheet software available under the examination arrangements.
Is a Python quick-reference provided?
Yes. The official syllabus says the lab provides a Python quick-reference guide.
Do candidates answer all questions?
Yes. Both papers are compulsory, and all their questions are compulsory.
Can I use an approved calculator?
Yes, under SEAB regulations, though a calculator cannot replace programming skills.
Does Paper 1 include Boolean logic?
Yes. Logic gates, Boolean relationships, binary representation and other computing fundamentals are among the official learning outcomes.
How does K349 differ from K237?
K349 is G3 with written paper and Python lab. K237 is a new G2 entry with e-exam and media, spreadsheet and Scratch practical.
Are the software versions always the same?
Follow SEAB’s current candidate instructions and the examination centre’s approved environment; do not infer exact installed versions from older practice.
Can a learner become ready by memorising Python syntax?
Syntax is necessary but insufficient. The exam also tests analysing problems, checking requirements, designing, testing and debugging.
What happens if I forget to save files?
The lab requires softcopy deliverables, and its duration includes time to save. Rehearse final-file verification.
Does K349 automatically qualify a candidate for a specific computing course?
No. Post-secondary programmes apply their own entry requirements alongside the student’s full subject combination.
SEC grades and future course choices
G3 subject grades run from A1 through grade 9, and E8 or better meets the SEC subject certificate-award threshold. Those thresholds are not the entry requirements for individual JC, polytechnic, ITE or computing programmes. Current admissions rules and the candidate’s full subject combination determine eligibility.
Computing skills also have value outside the examination: managing data carefully, checking algorithms, identifying misleading digital content, communicating findings and protecting information. Students can build those abilities even if they eventually study a different post-secondary subject.
Official SEAB documents and further reading
The structure and content described here were checked against the official 2027 K349 syllabus PDF, 2027 G3 school-candidate syllabus list and SEC overview as available on 11 November 2026. The sample tasks and calculations are independent educational illustrations. Use the latest SEAB candidate instructions for actual software, formats, file submission and examinations.
- G3 K349 syllabus Python and spreadsheet guide
- G3 Computing paper and lab primer
- 2027 G2 versus G3 Computing differences
For the next useful lesson, choose a small unfamiliar problem, state its requirements, predict an output, build the solution and test it against an edge case. Save the final artefact and reopen it. That routine develops the computing judgment the SEC is designed to assess, rather than dependence on a memorised set of clicks.
