BCS Written Computer Science common mistakes
BCS Written Computer Science · Understand the traps and how to avoid them.
Writing a definition of a concept (e.g. cache memory or normalization) and stopping there, instead of answering the actual verb of the question such as 'compare', 'justify' or 'evaluate'.
Under time pressure candidates latch onto the first familiar term in the question and dump memorized text, because recall feels productive and they do not re-read the command word before writing.
What to do instead
Underline the command word and the number of required parts before starting; build a one-line skeleton (e.g. 'Compare: point 1, point 2, then verdict') and check at the end that each demanded verb has an explicit sentence answering it.
Describing a stack, queue or tree only in the abstract without tracing the given data through the stated operations, so the final state or output is wrong or missing.
Candidates know the definitions but avoid step-by-step tracing because it feels slow, and they try to infer the answer from the pattern rather than simulate it.
What to do instead
Draw the structure and rewrite its full state after every single operation (push/pop, enqueue/dequeue, insert/rotate), numbering each step; the answer is then read off the final diagram rather than guessed.
Giving a Big-O bound without stating what variable it is in, whether it is worst/average/best case, and without justifying it from the code or recurrence.
Complexity is memorized as a label attached to an algorithm name, so candidates skip the derivation and lose the marks allocated to reasoning.
What to do instead
Always write 'in terms of n = ..., worst case is O(...) because the loop runs ... times / the recurrence T(n)=... solves to ...', and state the assumption (e.g. balanced tree, uniform hashing) explicitly.
Confusing pass-by-value with pass-by-reference and mispredicting output when a function reassigns a parameter or mutates an object passed to it.
Candidates learn the terms from one language (often Java or Python) and transfer intuitions to C or C++ without checking whether the parameter is a pointer, a reference, or a copied value.
What to do instead
For each call, annotate the parameter type at the call site (value, pointer, reference) and track two separate things: whether the caller's variable is rebound and whether the pointed-to object is mutated; then write the printed output line by line.
Writing SQL that runs but answers a different question, typically by putting a filter on the wrong side of a join, using WHERE instead of HAVING with aggregates, or omitting GROUP BY columns.
Candidates translate the English sentence clause by clause in reading order, so the join and filter order in the query mirrors the sentence rather than the semantics of the tables.
What to do instead
Before writing SQL, list the output columns, then the tables and join keys, then the rows to exclude, then the grouping; place row filters in WHERE, group filters in HAVING, and test the query mentally against one sample row per group.
Drawing a normalized schema or ER diagram without showing keys, cardinalities and participation constraints, so the design cannot be marked as correct even when the entities are right.
Candidates focus on getting the boxes and relationships drawn and treat notation details as cosmetic, often because they are racing to finish a long question.
What to do instead
Adopt one notation and always label primary keys (underline), foreign keys, 1:1/1:N/M:N on each relationship end, and total vs partial participation; finish with a two-line statement of which normal form each table is in and why.
Computing a subnet mask, host range or number of subnets without showing the binary working, and giving an answer that contradicts the stated prefix length.
Candidates memorize formulas (2^n subnets, 2^h - 2 hosts) but apply them to the wrong exponent under exam pressure, and the missing working removes any chance of partial credit.
What to do instead
Write the address and mask in binary or in octet form, mark the network/host boundary, then derive network address, broadcast address and usable range explicitly; sanity-check that the host count matches the number of host bits.
Explaining a scheduling, synchronization or deadlock scenario by naming the algorithm rather than computing the timeline, waiting times or safe sequence the question asks for.
Candidates recognize the algorithm name (e.g. round robin, banker's algorithm) and assume recognition earns the marks, skipping the tabular computation that the question actually rewards.
What to do instead
Draw a Gantt chart or allocation/need table and fill it completely, then compute average waiting time or the safe sequence from the table; state the final numeric answer in a separate line so the marker can find it.
Producing a design or requirements answer with no traceability: use cases, DFD levels or test cases that cannot be linked back to the stated requirements or to each other.
Candidates treat each diagram as an isolated drawing exercise and do not maintain a consistent set of actors, process names and data stores across the answer.
What to do instead
Number the requirements first, tag each use case, process and test case with the requirement numbers it satisfies, and use identical names for actors and data stores in every diagram so the set is internally consistent.
Answering a security question with a list of controls (firewall, encryption, IDS) without mapping each control to a specific threat, asset or layer, and without stating the residual risk.
Security answers are often recalled as vocabulary lists, and candidates are reluctant to commit to a threat model in case they choose the wrong one.
What to do instead
Structure the answer as asset, threat, vulnerability, control, residual risk; state the assumed threat model up front and justify each control against one named threat at one named layer (network, host, application, human).