ILTS Computer Science (205) common mistakes
ILTS Computer Science (205) · Understand the traps and how to avoid them.
When tracing a loop or recursive function on paper, the candidate writes only the final return value and skips recording intermediate variable states, so an off-by-one iteration count or a missed base-case call goes unnoticed.
Candidates who are fluent readers of code often 'run' short programs mentally, and mental execution drops state that paper would preserve; exam traces involve nested loops, accumulator updates, and recursive call stacks where a single skipped step changes the answer.
What to do instead
Adopt a fixed trace table: one row per iteration or call, columns for each variable plus output. For recursion, draw the call stack and record arguments and return values as frames pop. Practise on 5-10 short loops and recursive functions until the table habit is automatic, then compare the table's last row to each answer choice before selecting.
The candidate classifies an algorithm's complexity by counting the visible loop keywords rather than the work per iteration, labelling a single loop over n elements with an inner operation over a growing substring as O(n) instead of O(n^2).
Textbook examples pair one loop with O(1) work, so pattern-matching 'one loop equals linear' feels safe; questions that hide quadratic work inside string slicing, list membership checks, or nested comprehensions exploit that shortcut.
What to do instead
For each candidate answer, derive the count of elementary operations as a function of input size: identify the dominant operation, sum how many times it executes across all loop levels including hidden iterations inside library calls, then drop constants and lower terms. Verify by asking what happens when n doubles (doubling suggests linear, quadrupling suggests quadratic).
The candidate writes pseudocode or Java/Python answers that compile conceptually but mishandle boundary conditions: loop bounds that skip the last element, base cases that never trigger, or swap logic that loses a value because a temporary was not used.
Candidates rehearse standard algorithms from memory and reproduce the shape of the solution while omitting the guard clauses and temporary variables that make it correct; exam items often supply partially written code and ask which line completes it, so the boundary is the whole question.
What to do instead
Before answering, test the proposed code against three inputs: empty or single-element, a typical case, and a case hitting the boundary (last index, first index, duplicate values). Hand-execute the boundary case fully. Memorise the canonical boundary forms for binary search (low <= high with mid+1/mid-1 updates) and for swaps (temp or tuple assignment).
The candidate describes a software process or paradigm in slogan form ('use agile', 'apply encapsulation') without connecting it to the concrete artifact or consequence the question asks about, such as which test type catches a specific defect or which design principle a code fragment violates.
Methodology vocabulary is easy to memorise at the definition level, and under time pressure candidates reach for the most familiar term rather than mapping the scenario's details to the concept; questions are written to reward the mapping.
What to do instead
For each concept in the programming domain (unit vs integration vs regression testing, encapsulation, inheritance vs composition, waterfall vs iterative), write a one-line 'trigger' describing the scenario that signals it. When reading a stem, underline the concrete detail (a changed module breaking an untouched feature signals regression testing) and match it to the trigger before choosing.
The candidate confuses the abstract properties of a data structure with a specific implementation: stating a hash table guarantees sorted iteration, that a binary search tree is always balanced, or that a stack supports random access.
Introductory courses teach structures alongside one library implementation (for example Python dicts, which preserve insertion order), so implementation behaviour gets mistaken for the abstract data type's contract; exam items deliberately test the distinction.
What to do instead
Build a comparison table with rows for stack, queue, priority queue, linked list, hash table, balanced tree, and graph, and columns for access, search, insert, delete complexity plus ordering guarantees and typical use. Mark which entries depend on implementation (balanced vs unbalanced BST, hash collision handling) and treat only the abstract contract as guaranteed.
The candidate writes SQL or relational-algebra answers that return the right rows for the sample data but are logically wrong: using WHERE instead of HAVING with aggregates, omitting GROUP BY columns, or choosing INNER JOIN where unmatched rows must be preserved.
Sample tables in a stem are small and often lack the rows that would expose the error, so the candidate validates against the visible data instead of the query's semantics; aggregate filtering and outer joins are the two spots where this is most tempting.
What to do instead
Ignore the sample rows until the query is written. State in words what each clause must do, then check three things: filters on aggregates belong in HAVING, every non-aggregated selected column appears in GROUP BY, and the join type matches whether unmatched rows should appear. Then test against a hypothetical row that matches no join partner.
The candidate answers number-representation and machine-level questions by decimal intuition: misjudging two's complement ranges, treating overflow as an error the hardware detects, or forgetting that floating-point values such as 0.1 are not exact.
Daily programming hides representation, and languages with arbitrary-precision integers or automatic overflow checks mask the underlying fixed-width behaviour; exam items target the gap between source-level expectations and hardware reality.
What to do instead
Memorise the formulas for an n-bit two's complement range (-2^(n-1) to 2^(n-1)-1) and practise converting negative values by inverting and adding one. Work several addition-overflow examples at 8 bits by hand. For floating point, recall that binary fractions represent sums of powers of 1/2, so decimal fractions with denominators other than powers of two repeat and round.
The candidate collapses the layers of networking into a single mental model: attributing end-to-end reliability to IP, placing encryption at the wrong layer, or confusing the roles of MAC addresses, IP addresses, and port numbers when asked what a device or protocol uses.
Users interact with applications, so 'the internet is reliable and secure' is the everyday experience, and the layered model is learned as a list of names rather than as a division of responsibility; questions probe exactly which layer provides which guarantee.
What to do instead
Draw the layer stack once with a one-line responsibility and a sample protocol per layer, then annotate where each guarantee originates: reliability and ordering from TCP, best-effort delivery from IP, link-local addressing from Ethernet/Wi-Fi, application encryption from TLS. For addressing questions, state the scope of each identifier (global network, local network, process) before answering.
The candidate treats legal, ethical, and social-impact scenarios as opinion questions, picking the response that sounds most idealistic rather than the one that matches a named principle, law, or professional obligation embedded in the stem.
These items read like discussion prompts, and candidates who have not studied the specific frameworks (privacy principles, intellectual property categories, acceptable-use and professional-ethics codes) answer from personal values; the stem usually names a concrete constraint that determines the answer.
What to do instead
Learn the small set of named frameworks the exam draws on: data privacy principles such as minimal collection and purpose limitation, the distinction between copyright, patent, and trade secret, software licensing categories, and the professional obligations of a computing educator (confidentiality of student data, acceptable use, accessibility). For each scenario, identify the named constraint first, then select the option that satisfies it without overreaching.
The candidate answers pedagogy items with a general preference ('use hands-on activities', 'differentiate instruction') instead of identifying the specific misconception, assessment purpose, or instructional strategy the stem describes.
Candidates with classroom experience have strong general instincts, and the options are written so that several are defensible teaching advice; only one addresses the exact situation, such as formative versus summative use or the difference between a misconception and a careless error.
What to do instead
Read the stem for three signals: what the student did, what the teacher wants to know, and when in the learning cycle it occurs. Map these to the assessment or strategy named in the options (diagnostic before instruction, formative during, summative after; pair programming, Parsons problems, and worked examples for specific novice difficulties). Eliminate options that are sound advice but do not answer the stated question.