Bukit Timah families seeking IB Diploma Computer Science tuition should first confirm the student’s exact IB subject guide, level and examination session. A three-student tutorial can support understanding, evidence-based reasoning and independent assessment preparation, but the IB Diploma Programme is not a SEAB syllabus and its requirements should not be confused with Singapore national examinations.

Small-group teaching works best when each learner receives a diagnostic explanation, guided practice, specific correction and a fresh independent task. Parents should confirm actual class availability, timetable, fees and the tutor’s familiarity with the school’s current course. Coursework remains the student’s own work and all external help must comply with school academic integrity rules.

• Subject: IB Diploma Computer Science at the student’s registered Standard Level or Higher Level.
• Group: up to three learners, matched by course, programming language and learning needs.
• Location focus: Bukit Timah, Singapore; confirm actual arrangements before enrolling.
• Session check: the revised course is first assessed in May 2027.
• Practice: systems knowledge, algorithms, programming, testing and written explanations.
• Integrity: support the learner’s skills without developing their assessed solution for them.

Start with the 2027 course, not an outdated options list

The revised IB Computer Science course began teaching in August 2025 and is first assessed in May 2027. The official curriculum update describes two broad areas: how computer systems work, and computational thinking with problem-solving and programming. The course covers areas including computer fundamentals, networks, databases and machine learning, alongside programming and object-oriented thinking. Higher Level includes additional depth, including abstract data types.

Several assessment changes make session checking important. The old option structure has been removed from the revised course, and the former Higher Level Paper 3 is not part of the new model. A case study now contributes to Paper 1 at both levels. Java and Python are the supported programming-language choices for the new assessment. A revision plan built around the former options or an old Paper 3 checklist therefore needs careful revision, not merely a new year on its cover.

Parents should establish the examination session, level and language used by the school before selecting a group. A student writing Java and a student writing Python may share useful work on algorithms, but they also need language-specific feedback. A retake candidate should confirm the applicable arrangements with the coordinator. The tutor should teach the student’s actual course rather than assume that all Computer Science material found online is interchangeable.

Assessment weights and examination times for first assessment 2027

The table below follows the assessment table in the official 2027 Computer Science subject brief. In particular, the internal assessment is weighted differently at the two levels.

Component	Standard Level	Higher Level
Paper 1	75 minutes; 35%	120 minutes; 40%
Paper 2	75 minutes; 35%	120 minutes; 40%
Internal assessment	30%	20%

Paper 1 and Paper 2 require different kinds of preparation. A learner needs to explain systems and use a case-study context, but also to reason about algorithms and programming. For the programming questions, the new assessment provides Java or Python alternatives. Pseudocode can help a student plan a solution, but it should not be treated as a substitute where the question requires an answer in the selected programming language.

The assessment percentages are not a formula for dividing tuition time. If a student understands systems well but cannot trace a loop, the immediate teaching priority may be programming. Another student may produce working code but struggle to justify design decisions in writing. An initial diagnostic should identify that difference before a provider recommends additional sessions.

What the new computational-solution IA requires

The IB’s 2027 Computer Science assessment instructions describe an independently developed computational solution. The requirements are the same at both levels, although the weights are 30% at SL and 20% at HL. Collaborative IA work is not permitted. The submission includes documentation of no more than 2,000 words, a video no longer than five minutes, and appendices containing the full source code. Detailed word-count exclusions and submission instructions should be checked with the school.

The examiner is not expected to run the finished product. The video therefore needs to demonstrate functionality and testing clearly; a decorative presentation is not a replacement for evidence that the solution works. The documentation, demonstration and source code should tell a consistent story about what the student designed, developed and evaluated. The separate collaborative sciences project must not be confused with permission to collaborate on the individual IA.

A tutor’s role is to build transferable skills on unrelated exercises. For example, the tutor can teach boundary testing using an invented ticket-price function while the student’s own assessed application remains untouched. Writing the student’s code, supplying their documentation or fabricating a development history would undermine independent authorship. School-approved libraries or other permitted resources must be handled transparently according to the current rules; acknowledgement does not turn someone else’s completed project into the student’s work.

Diagnose the problem before adding another coding course

A useful first meeting contains three small tasks: trace an unfamiliar algorithm, explain a system concept, and design tests for a simple requirement. These tasks reveal more than asking which programming language the student knows. A learner may recognise syntax without understanding how values change, or understand a solution verbally but struggle to express it precisely.

For an original diagnostic, describe a function that should accept ages from five to seventeen inclusive. Ask the learner to identify valid inputs, invalid inputs and values close to each boundary. Then ask how the program should respond to an empty entry or non-numerical text. No large application is needed to discover whether the learner understands conditions, validation and requirements.

Keep the student’s first response. If the tutor supplies most of the reasoning, note that honestly rather than recording the task as mastered. The next lesson should address the specific missing step, such as the meaning of inclusive boundaries or the distinction between input validation and calculation.

1. Computational thinking begins with the problem specification

Before writing code, identify what the system must do. Consider an invented school-library borrowing system. It needs information about books, borrowers and loans, but the exact rules matter: can an item have multiple copies, can a borrower renew a loan, and what happens when an identifier is not found? A vague instruction to build a library app leaves too many decisions hidden.

Ask the student to separate inputs, processing, outputs and constraints. An input might be a book identifier. Processing might check availability and create a loan record. An output might confirm the due date. A constraint might prevent the same physical copy being issued twice. These distinctions make it easier to test whether a proposed solution actually answers the problem.

Not every decision should be automated without thought. A disputed record may need human review rather than another condition buried in code. The learner should explain which decisions are represented in the model, which remain outside it, and why. This is a stronger start than choosing a fashionable interface before understanding the requirements.

2. Decomposition and abstraction solve different difficulties

Decomposition divides a large task into manageable parts. Abstraction selects the details relevant to the problem. For a fictional route planner, decomposition might separate reading the network, finding a route and displaying the answer. Abstraction might represent stops as nodes and travel connections as links with costs, while leaving out details irrelevant to the chosen calculation.

The choice of cost matters. A route that minimises distance need not minimise travel time or the number of changes. If the requirement is accessible travel, a model that ignores accessibility cannot reliably answer the intended question. Students should learn to test an abstraction against the requirement rather than assume that a mathematically neat model is automatically suitable.

A practical exercise is to give the same network two different objectives. Ask which parts of the model can stay and which must change. The student should explain the modification before attempting code. This checks whether they understand the representation or are merely repeating a memorised diagram.

3. Design algorithms that survive awkward inputs

Finding the largest value in a list is simple enough to expose important mistakes. Suppose the invented input is negative seven, negative two and negative nine. An algorithm that begins by setting the largest value to zero will return an answer that does not appear in the list. The problem is not difficult syntax; it is an unjustified assumption about the data.

For a non-empty list, one sensible approach begins with its first value and compares each remaining value with the current largest. In this example the current largest changes from negative seven to negative two, then remains negative two. The learner should explain why the method works rather than only reproduce a sequence of statements.

An empty list requires a separately specified response because it has no largest member. Possible designs include returning a defined signal or raising an appropriate error, depending on the requirement. Ties also need consideration if the task asks for a position rather than merely a value. These questions show why a correct algorithm must be judged against a precise specification.

4. Trace state changes before pressing Run

A trace table records values step by step. It is particularly useful when a student says that a loop looks right but cannot explain its output. For an invented example, begin with a total of zero and add the values two, four and six in sequence. The running totals are two, six and twelve. Now alter the loop so that it stops before the final item: the trace reveals exactly where the required work is omitted.

Ask the learner to distinguish the index from the value stored at that index. Confusing the two can produce code that runs without producing the intended answer. The tutor should also check whether the learner understands when a condition is tested and when a variable is updated.

Use pseudocode for planning where it helps, then practise the selected Java or Python notation required by the school and assessment. Switching constantly between languages can obscure a basic logic problem. First make the state changes understandable; then make their expression accurate.

5. Data representation needs units and assumptions

Binary representation can be taught through a small worked conversion. The decimal value thirteen is represented by eight plus four plus one, so its four-bit unsigned representation is 1101. The student should be able to reconstruct the decimal value from the place values, not just recall a conversion procedure.

Storage calculations require equally careful assumptions. An invented uncompressed image with one hundred by one hundred pixels and twenty-four bits per pixel contains 240,000 bits of pixel data, or 30,000 bytes. That calculation excludes headers, metadata and any compression. A learner who states those assumptions gives a more accurate answer than one who presents the number as the exact size of every such image file.

Changing the representation changes what can be stored. A limited range may require a decision about overflow; text needs an encoding; a decimal-looking value may be represented approximately in a particular numeric format. Match the depth of these issues to the current school unit, and insist on correct units before introducing more complicated examples.

6. Connect applications, operating systems and hardware

When a student saves a file, several layers are involved. For a simplified teaching model, distinguish the application’s request, the operating system’s handling of that request and the storage device receiving data. The model is deliberately incomplete, but it helps prevent the vague explanation that the computer simply puts the file somewhere.

Give an invented fault scenario: the application appears responsive, but a save operation fails. Ask what additional information would help locate the problem. Possible questions concern permissions, available storage or the requested destination. The student should not choose an explanation solely because it is the only technical term they remember.

Systems answers improve when each component has a stated role and the relationship between components is clear. The tutor can ask the learner to explain why a fast processor alone does not guarantee that every operation will finish quickly. A response grounded in the task and its constraints is more useful than a list of hardware specifications.

7. Explain networks through a complete communication task

Use a fictional school device requesting a page from a server. Ask students to identify the sender, receiver, information being transferred and possible reasons for delay or failure. Then introduce the relevant network concepts from the school’s current unit. The task provides a reason to discuss addressing, communication rules and the distinction between a local connection and a wider service.

Bandwidth and latency should not be treated as interchangeable descriptions of speed. A simple analogy can help, but students should return to the technical meaning and the actual problem. A system carrying large files and one responding to many small interactive requests may be affected differently by communication constraints.

For evaluation, present two invented school-network arrangements with different requirements. One might prioritise reliable access in a small room; another might need coverage across several buildings. Ask the learner to justify a choice using the supplied conditions. Avoid unsupported claims that one technology is always the best option regardless of context.

8. Organise database information around relationships

In an invented borrowing system, a book title, a physical copy and a loan are not the same thing. Several copies can share a title, and one copy can be borrowed many times on different dates. Putting all information into one repeated row can make updates confusing. A useful lesson begins by identifying the entities and the relationships the system needs to preserve.

Ask why names alone make poor identifiers in some situations: two people may share a name, while a name may change. A carefully chosen identifier can distinguish records without pretending that the label itself explains the person or object. Then examine how a loan record refers to the relevant borrower and copy.

Query practice should begin with the question being answered. Which copies are currently on loan is different from which titles have ever been borrowed. The learner should explain the conditions before writing the query and test it with deliberately chosen records, including cases that should be excluded. This connects database syntax to reasoning.

9. Approach machine learning as an evidence problem

The revised course includes machine learning, but a tuition lesson should not reduce it to fashionable terminology. Start with an invented classifier that predicts whether a message belongs to one of two categories. Identify the information supplied, the target label and how the proposed model would be evaluated. A convincing demonstration needs more than a few successful examples selected after the result is known.

Consider a fictional dataset in which ninety of one hundred messages belong to one category. A rule that always predicts that category would achieve 90% accuracy on those examples, while failing completely on the minority category. The arithmetic shows why an overall percentage can hide a serious weakness. It does not establish which metric or model is best for every application.

Ask whether evaluation data have been kept appropriately separate from model development, whether the examples represent the intended use and what mistakes would matter most. These questions connect the technical topic with responsible interpretation. Use clearly invented data for practice, not private messages or classmates’ personal information.

10. Programming fundamentals should remain visible

A student who can assemble a large application may still be uncertain about functions, conditions or variable scope. Choose a small task and require an explanation of its inputs, output and intermediate values. For example, a function might accept a quantity and a unit price, validate them against stated rules and return a total. Each responsibility should be clear.

Distinguish a syntax problem from a runtime failure and from a logical error. A statement can be grammatically valid in the language and still calculate the wrong result. Reading an error message is therefore only one part of debugging; the learner must also compare behaviour with the requirement.

Good practice changes one feature at a time. After the basic function works, add a clearly specified discount rule or an invalid-input case. Ask the student to predict the effect before running the code. This keeps the lesson focused on understanding rather than random editing until an error disappears.

11. Object-oriented thinking is more than naming classes

For an invented library model, a copy of a book could have an identifier and a loan status, together with operations that change that status under stated conditions. A class describes the kind of object; an object represents a particular instance. Students should be able to explain this distinction using their own example.

The design also needs rules. If an operation issues an already borrowed copy, what should happen? Which part of the system should protect the consistency of the information? These questions are more revealing than drawing several boxes and labelling them as classes.

Do not introduce inheritance merely because the word sounds advanced. Ask whether a relationship genuinely represents the intended design and whether a simpler arrangement would be clearer. The school’s current guide determines the required depth. A tutorial should make the student’s reasoning explicit, not reward complexity for its own sake.

12. Testing should challenge the claim that the program works

Return to the invented age rule: values from five to seventeen are valid. Tests should include four, five, seventeen and eighteen, because these expose mistakes near the boundaries. A normal value such as ten is useful but insufficient. The student should state the expected result before running each test.

Now include empty input, non-numerical input and any additional cases required by the specification. If the program rejects a valid value, trace the relevant condition. If it accepts an invalid one, identify which rule was not enforced. A test table is useful when it records the input, expected behaviour, actual behaviour and what the result means.

Debugging should follow evidence. Change the smallest relevant part, rerun the failing test and then check that previously successful cases still work. Randomly changing several lines makes it harder to learn why the fault occurred. For assessed development, the student must perform and document their own work under the school’s rules.

13. Choose data structures for the required operations

The best representation depends on what the program needs to do. A list may suit a sequence whose order matters. A mapping from an identifier to a record may suit repeated lookup by that identifier. A stack and a queue express different removal rules. Naming these structures is only the beginning; students need to connect the choice to the operation.

Use an invented help-desk queue and a separate undo history. The help desk might serve requests in arrival order, while undo typically returns to the most recent action first. Ask what would go wrong if the structures were exchanged without changing the requirements. The comparison gives the terminology a practical purpose.

For Higher Level work, follow the additional abstract-data-type requirements in the current course. A learner should distinguish the behaviour promised by an abstract structure from the particular way it is implemented. This helps prevent an implementation detail from being mistaken for the definition of the structure itself.

14. Discuss efficiency without ignoring correctness

A fast algorithm that returns the wrong answer is not a successful solution. Establish correctness for the stated inputs before comparing resource use. For linear search, the number of inspected entries can grow with the size of the list. Binary search repeatedly reduces the search range, but it depends on an appropriate ordered collection and correct boundary handling.

Consider a hypothetical dataset that arrives unsorted and is searched only once. Sorting it solely to use binary search may introduce work that a simple scan would avoid. If the same stable dataset will be searched many times, the trade-off can change. The student should state the workload rather than repeat that one algorithm is always faster.

Measured execution times also depend on the test environment and input. A fair comparison keeps relevant conditions consistent and uses more than one convenient example. Distinguish observed timings from a reasoned account of how work grows as the input grows. Both can be useful, but they answer different questions.

15. Responsible computing belongs in the design

For a fictional login system, ask what information is actually necessary and who should be able to access it. Avoid collecting real classmates’ details for a demonstration. A lesson can examine data minimisation, access control, clear error handling and recovery using invented records. Security discussion should remain within authorised educational examples.

A useful evaluation explains consequences. A convenient feature that reveals another user’s private record is not justified merely because it saves a click. A design that depends on users noticing every mistake may need stronger controls. Conversely, a control that makes an essential task inaccessible can create another problem that needs attention.

Students should make these trade-offs visible rather than append a sentence saying security is important. Ask which requirement addresses the risk, how it could be tested safely, and what limitation remains. No tutorial exercise should involve attempting access to real systems without explicit permission.

16. Prepare for case-study and written explanations

The new case-study requirement makes careful reading important at both levels. Use the school’s authorised materials for the actual assessment context. For general practice, an invented scheduling service can provide questions about storage, communication, reliability and user needs. Students should connect each technical explanation to the stated scenario.

A strong written response moves from requirement to choice to consequence. For example, choosing an identifier-based lookup may serve a particular access pattern, but the answer should also consider how records are updated and what happens when an identifier is missing. Unsupported adjectives such as efficient, secure or user-friendly do not explain a design.

During revision, have the learner write a short justification without code. Then ask whether the implementation actually follows that explanation. This exposes a frequent gap between knowing technical vocabulary and understanding the program that has been produced.

Use a three-student group without hiding individual gaps

A suggested session begins with everyone tracing the same short algorithm independently. Compare answers only after the first attempt is recorded. One learner can then propose a correction, another design a test that might disprove it, and the third explain the requirement being protected. These roles should rotate.

The tutor needs to prevent the most experienced programmer from becoming the group’s permanent problem-solver. After discussion, give each student a new variant. One might change an inclusive boundary, another handle an empty collection, and another explain a failed test. Independent follow-up reveals whether the discussion changed each learner’s understanding.

Match the group by more than school year. The examination session, selected language, current unit and pace of work all affect suitability. A group can share conceptual teaching while still needing different programming exercises. When the differences consume most of the lesson, reconsider the grouping rather than ask one student to wait repeatedly.

Plan progress around specific capabilities

For a learner who is behind, begin with variable tracing, conditions and small functions. A complicated project may conceal the same basic uncertainty across hundreds of lines. For a learner maintaining a steady performance, mix systems explanations with independent programming so that one strength does not hide the other weakness.

For a learner ready to progress, ask for justified alternatives: a different data structure, a clearer decomposition or a better test strategy. The objective is not simply a longer program. It is the ability to choose a solution under constraints and explain the trade-offs.

A four-week review can compare a baseline task with a fresh task of similar difficulty. Record whether the student can now trace accurately, identify missing cases and explain a correction without help. This is a suggested review method, not a promise of a particular grade or improvement within a fixed period.

Homework and academic integrity

Keep ordinary homework small enough to inspect closely. One traced algorithm, one function and a few purposeful tests can reveal more than a large copied application. Ask the student to explain a choice and change a requirement during the next lesson. A learner who understands the work should be able to reason about an unfamiliar variation.

External examples, libraries and generated suggestions require appropriate scrutiny and acknowledgement under school rules. A student must not present work produced by another person or service as their own. The IB academic integrity guidance identifies both plagiarism and the creation or overediting of student coursework as concerns.

Parents should reject offers to finish an IA, supply a development log or manufacture testing evidence. A legitimate tutorial can teach a debugging technique on separate material, then leave the learner to apply their understanding independently. The school’s teacher decides the boundaries for feedback on assessed work.

Questions parents should settle before committing

Ask which syllabus and language the tutor teaches, how the 2027 changes are reflected in lessons, and how independent coding is checked. Request a demonstration of the teaching process: can the tutor explain an incorrect loop, not merely replace it with working code? Ask how a three-student class handles differences in prior experience.

Confirm actual Computer Science availability, staff expertise, fees, timetable, location and cancellation arrangements directly. This article describes a teaching model, not a confirmed vacancy or IB-endorsed programme. Class size alone does not guarantee results, and tuition should not displace the time a student needs for independent development and other Diploma Programme commitments.

Must students learn both Java and Python? Follow the school’s selected approach and the current assessment instructions; the existence of two alternatives is not a reason to divide attention unnecessarily. Is pseudocode useless? No: it remains a planning tool, but it must not replace a language-specific answer when one is required.

Can students collaborate on the IA because there is a collaborative sciences project? No. They are separate requirements. Is a polished interface enough? No. The solution needs to meet its requirements, demonstrate functionality and testing, and remain the student’s independent work.

Sources and scope

Curriculum and assessment details were checked on 15 November 2026 against the linked IB curriculum update, 2027 subject brief and assessment instructions. The IB Computer Science subject page provides the starting point for official course information. The examples, calculations and suggested teaching sequence here are original practice illustrations, not official examination questions or a complete subject guide. The student’s school remains the point of contact for registered course details and permitted assessment support.