NYSTCE Computer Science common mistakes
NYSTCE Computer Science · Understand the traps and how to avoid them.
When tracing a recursive function on paper, the candidate writes only the final returned value at each call instead of tracking the full call stack, unwinding order, and how each frame's local variables change.
Recursion is taught through small examples that can be 'seen' intuitively, so candidates skip the mechanical stack discipline. Timed conditions reward speed, and the candidate substitutes pattern-matching ('this looks like factorial') for actual execution, which fails on non-standard base cases or when the return expression combines two recursive calls.
What to do instead
Adopt a fixed trace template: draw one column per active frame, record parameter values on entry, mark the point where each recursive call is made, and fill in return values on the way back up. Practice on functions with two recursive calls (e.g., a naive Fibonacci or a tree-height function) where the unwinding order, not just the count, determines the answer. Do five traces per study session until the template is automatic.
The candidate evaluates postfix, prefix, and infix expressions and Boolean short-circuit expressions left-to-right by habit, without applying operator precedence, associativity, and the rule that && and || stop evaluating once the result is determined.
Everyday arithmetic reading is left-to-right, and many candidates never internalized that unary minus, exponentiation, and assignment associate differently, or that a side-effecting operand to the right of a short-circuit operator is never executed. Under time pressure the candidate computes the 'obvious' value and moves on.
What to do instead
Before computing, rewrite the expression fully parenthesized according to the precedence table, then evaluate. For short-circuit questions, explicitly mark which operands are evaluated and which are skipped, and note any variable increments that therefore do not happen. Drill a mixed set of ten expressions per session, including at least two where the skipped operand would have changed a variable's value.
When asked what a loop or algorithm outputs, the candidate runs the loop mentally for the first two or three iterations and then extrapolates the final value, rather than building a table of iteration number, loop variable, accumulator, and loop condition for every iteration including the terminating one.
Mental simulation feels sufficient for short loops, and off-by-one errors, loop-variable updates placed before versus after the accumulator update, and the final failing-condition check are exactly the details that extrapolation drops. Fatigue late in the test makes the shortcut more likely.
What to do instead
Always build a four-column trace table and continue it until the loop condition fails, circling the last row to confirm the exit test. Pay special attention to whether the update happens before or after the body and whether the condition is < or <=. Practice with loops that modify the loop variable inside the body, which is where extrapolation most often breaks.
The candidate converts between binary, decimal, hexadecimal, and two's-complement representations by estimating magnitude instead of doing positional expansion and, for negatives, the invert-and-add-one procedure, and then misreads the sign bit.
Base conversion is treated as a memorized trick rather than a positional-value computation, so candidates guess at digit counts and forget that the leftmost bit in a fixed-width two's-complement number carries negative weight. Range questions (how many values fit in n bits) are then answered from memory rather than from 2^n reasoning.
What to do instead
For every conversion, write the place values (…, 16, 8, 4, 2, 1) above the digits and sum the weights of the 1 bits. For two's complement, compute the unsigned value, then subtract 2^width, and verify the result lies in the representable range. Practice converting the same value in all four representations and check that the bit patterns agree.
When reading a short program, the candidate assumes the language uses the same scoping, parameter-passing, and equality rules as the language they know best, instead of applying the rules of the language actually shown (e.g., pass-by-value versus pass-by-reference, == versus equals, block scope versus function scope).
Candidates prepare in one language and transfer intuitions wholesale. Pseudocode and unfamiliar syntax are skimmed rather than parsed, and the distinction between a variable holding a value and holding a reference is invisible unless the candidate deliberately looks for it.
What to do instead
Before answering, identify the language and write down its rules for the three features the question turns on: how arguments are passed, how equality is tested, and where variables are visible. For pass-by-reference questions, track the aliasing explicitly by drawing two names pointing at one box. Practice the same ten-line program rewritten in two languages with different semantics and predict where the outputs diverge.
The candidate answers questions about data-structure operations by recalling Big-O labels from a table rather than reasoning about the structure's shape, so they misstate average versus worst case for hash tables and misidentify which traversal order a given structure or algorithm produces.
Complexity is often memorized as a list ('hash lookup is O(1)') without the caveat about collisions, and tree traversals are memorized as acronyms without connecting pre-order to root-first processing. Questions that combine a structure with an operation (insert at the front of a linked list versus a dynamic array, find-min in a heap versus a BST) then defeat table recall.
What to do instead
For each structure, sketch it with five elements and narrate the pointer or index changes for insert, delete, and search, then derive the cost from that narration. State hash-table costs as average O(1) but worst-case O(n) under collision. For traversals, write the visiting order as a sequence of node labels from a drawn tree rather than naming the acronym.
When asked to select an algorithm or trace a sort or search, the candidate applies a memorized pass-by-pass pattern without checking the algorithm's invariant, so they misreport the array state after a specific pass or choose an algorithm that does not satisfy the stated constraints (stability, in-place, or worst-case bound).
Sorting is learned as a set of visual animations, and the invariant (what is guaranteed sorted after k passes, or what partition property holds) is glossed over. Constraint words in the stem ('stable', 'in place', 'guaranteed O(n log n)') are read as decoration rather than as filters.
What to do instead
For each sort, write its invariant in one sentence and trace a six-element array pass by pass, marking the guaranteed-sorted region. Build a comparison grid of the common sorts against the four constraints (stable, in-place, worst-case bound, adaptive) and consult it before choosing. For searches, state the precondition (sorted input, random access) before applying binary search.
On networking and systems questions, the candidate conflates layers and protocols, for example placing HTTP or DNS at the transport layer, treating TCP and IP as interchangeable, or describing an IP address as identifying a process rather than a host interface.
Layer models are memorized as a stack of names without a functional rule for assigning a protocol, and the exam's distractors are built precisely from adjacent-layer confusion. Candidates also carry over loose everyday usage ('the website's IP') into technical questions.
What to do instead
Assign every protocol by asking what it addresses: application-level data and semantics (HTTP, DNS, SMTP), end-to-end process-to-process delivery with ports (TCP, UDP), host-to-host addressing and routing (IP), link-local delivery (Ethernet, ARP). Redraw the layer stack from memory and place ten protocols on it, then explain in one sentence what each layer adds that the layer below does not provide.
The candidate writes SQL or relational-algebra answers that ignore NULL semantics, join type, or grouping rules, producing a query that returns rows the stem excludes, or predicts a result set without accounting for duplicate elimination and aggregate behavior over empty groups.
Practice queries use clean data with no NULLs and simple inner joins, so the candidate never confronts three-valued logic, outer-join padding, or the rule that WHERE filters rows before grouping while HAVING filters groups after. The candidate also assumes SELECT DISTINCT is implicit.
What to do instead
Before writing a query, state in words which rows should survive each clause and in what order the clauses execute (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY). Test the answer against a small table that includes a NULL and a duplicate, and check whether the comparison with NULL yields unknown rather than false. For result-set prediction, list the output rows explicitly.
On computing-systems and impacts questions, the candidate answers from general impressions about technology rather than from the specific mechanism named in the stem, so they misattribute a security threat (phishing versus spoofing versus man-in-the-middle), misstate what a given hardware component does, or give a vague social-impact answer that does not engage the stated scenario.
These items are perceived as 'common sense' and are answered quickly without reading the scenario's distinguishing details. Terminology in security and hardware is also learned from headlines, where terms are used loosely and interchangeably.
What to do instead
Read the stem and underline the mechanism or actor it names, then match against precise definitions: who initiates contact, what is forged, what is intercepted, what resource is exhausted. For hardware, state the function of each component in one sentence (registers, ALU, control unit, cache, bus) and how data flows between them. For impact items, identify the specific stakeholder and the specific tradeoff before choosing.