SQU IT Exit common mistakes
SQU IT Exit · Understand the traps and how to avoid them.
When asked to trace a short loop or recursive function by hand, the candidate stops after one or two iterations and writes down the value of the loop counter rather than the value the function actually returns, so the final answer is off by one iteration or reports an intermediate variable.
Candidates read the code as prose and assume they already know what it does, so they skip the mechanical discipline of maintaining a variable table. Under time pressure, tracing on paper feels slower than 'just seeing' the answer, and off-by-one errors are invisible without a written trace.
What to do instead
For every trace question, draw a three-column table (iteration, changed variables, output so far) and fill one row per iteration until the loop condition fails. Then state explicitly which variable the question asks for before writing the answer. Practise ten traces of loops with boundary conditions (i < n versus i <= n, pre- versus post-increment) until the table habit is automatic.
The candidate analyses a problem and immediately writes code, then discovers mid-solution that the chosen loop structure or data structure cannot handle an edge case (empty input, single element, duplicates), and patches it with special-case branches instead of redesigning.
Exams reward visible output, so candidates rush to produce code they can show. Decomposing the problem into input, constraints, and steps feels like lost time, and many candidates have never been taught a structured problem-solving routine, so they default to trial and error.
What to do instead
Before writing any line, write three sentences: what the input looks like including its worst case, what the output must be, and the steps in plain language. List at least four edge cases (empty, one item, all duplicates, maximum size) and check the planned steps against each on paper. Only then translate to code. In practice, time-box planning to two minutes so it does not become procrastination.
When asked for the time complexity of a nested-loop or recursive algorithm, the candidate answers with the cost of the inner loop only (for example O(n) for a double loop) or guesses from the number of lines of code rather than counting how many times the dominant operation executes.
Complexity is taught as a formula to memorise rather than a counting exercise, so candidates pattern-match on surface features. Recursion especially confuses candidates because the cost is hidden in the recurrence rather than visible in the loop structure.
What to do instead
Count operations mechanically: for nested loops multiply the iteration counts; for recursion write the recurrence (T(n) = aT(n/b) + f(n)) and solve it by expansion for two or three levels. Always state which operation you are counting (comparisons, assignments) and drop constants only at the end. Drill one example each of O(log n) binary search, O(n log n) merge sort, and O(2^n) subset enumeration until you can justify each from the code.
The candidate writes a SQL query that puts a filter on the right-hand table of a LEFT JOIN in the WHERE clause, or uses WHERE instead of HAVING with an aggregate, and reports a result set that silently drops rows or errors out.
Candidates learn JOIN syntax and WHERE filtering separately and never internalise the logical order of evaluation (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY). The query runs without a syntax error, so the candidate assumes it is correct and never checks row counts.
What to do instead
Memorise the logical evaluation order and recite it before writing any query. For outer joins, put conditions on the preserved table in WHERE and conditions on the optional table in the ON clause. For aggregates, use HAVING. Always sanity-check by predicting the row count before running the query, and test with a NULL-containing row.
Asked to design tables for a scenario, the candidate produces one wide table with repeated groups (for example a student row containing comma-separated course codes) and declares it normalised because 'each row has a primary key'.
Candidates equate 'has a primary key' with 'normalised' and have not practised spotting partial and transitive dependencies. Wide tables also feel closer to the spreadsheet view of data that many candidates are comfortable with.
What to do instead
Apply the normal-form tests as explicit questions: does any non-key column depend on only part of a composite key (2NF)? Does any non-key column depend on another non-key column (3NF)? Split repeating groups into their own table with a foreign key. Practise by taking three wide tables, listing every functional dependency, and decomposing them, then verifying the decomposition is lossless by joining back.
The candidate describes TCP as 'reliable and connection-oriented' but cannot say what happens at the transport layer versus the network layer, and when asked to trace a packet from a browser to a server lists application, transport, and then jumps straight to 'the internet' without mentioning IP addressing, ARP, routing, or the return path.
Networks are learned as a list of layer names and protocol acronyms rather than as an encapsulation process. Candidates memorise definitions for recall questions but never practise the end-to-end walkthrough that scenario questions demand.
What to do instead
Practise narrating one full request aloud: DNS resolution, TCP three-way handshake, HTTP request, IP routing hop by hop, ARP for the next-hop MAC, response, and connection teardown. For each step name the layer, the address used (MAC, IP, port), and the device involved. Build a one-page diagram from memory and redraw it weekly until the encapsulation story is fluent.
On a security question the candidate lists controls ('use a firewall, use encryption, train users') without linking each control to the specific threat in the scenario, and omits the human and process controls entirely.
Candidates treat security as a vocabulary test and dump every control they remember, hoping the marker finds one that matches. Scenario analysis requires mapping threat to asset to control, which is a skill rarely practised in isolation.
What to do instead
Structure every answer as asset, threat, vulnerability, control, residual risk. Name the asset from the scenario, state the specific attack (phishing, SQL injection, insider misuse), then choose the control that addresses that mechanism and say why. Include at least one preventive, one detective, and one corrective control. Rehearse with three short scenarios until the mapping is automatic.
When asked to compare scheduling algorithms or explain a page fault, the candidate gives the definition of the algorithm but cannot compute a short schedule or state what the operating system does step by step after the fault occurs.
OS topics are abstract and candidates memorise textbook definitions without ever running the algorithm on a small example. The mechanisms (context switch, TLB lookup, page replacement, swap-in) have many steps and candidates learn them as a blur.
What to do instead
For every algorithm, work two small numeric examples by hand (five processes with given burst and arrival times; a reference string of ten pages under FIFO and LRU) and draw the Gantt chart or page-frame table. For mechanisms, write the numbered sequence of events and check each step against the definition. Do this from memory first, then verify against your notes.
In a system analysis or project management question the candidate jumps to a solution (a class diagram or a Gantt chart) without first eliciting and stating requirements, and then cannot justify why the design meets the stated need.
Candidates believe producing an artefact demonstrates competence, and requirements gathering feels like preamble. They also confuse 'the client wants an app' with a requirement and never practise converting vague wishes into testable statements.
What to do instead
Always start with a short requirements block: functional requirements as 'the system shall...' statements and at least two non-functional ones (performance, security). Trace each design element back to a numbered requirement and note any requirement not covered. For planning questions, derive tasks from the requirements before estimating. In practice, rewrite five vague client statements as testable requirements.
When asked to critique or improve a piece of code, the candidate rewrites it silently and submits the new version without stating what was wrong, why the change helps, or what trade-off it introduces, and does not mention testing or review.
Candidates treat critique as a coding exercise and assume the improvement speaks for itself. Professional-practice questions reward explicit reasoning about quality, maintainability, and team process, which many candidates have never had to articulate.
What to do instead
Use a fixed critique structure: name the defect (readability, duplication, missing validation, poor naming), explain the consequence, propose the change, state the trade-off, and say how you would verify it (unit test, code review, static analysis). Close with one sentence on how the change affects the team, for example reviewability or onboarding. Practise on three short code snippets until the five-part structure is reflex.