Ruankao Software Designer (Intermediate) common mistakes
Ruankao Software Designer (Intermediate) · Understand the traps and how to avoid them.
Mixing up pre-increment and post-increment, or assuming left-to-right evaluation of function arguments, in code-tracing questions.
Candidates read expressions as mathematical notation rather than as sequenced side effects, and evaluation order of arguments is often unspecified in the language being tested.
What to do instead
Separate side effects into individual statements and trace the specified language and version. Distinguish a permitted but unspecified order from undefined behavior caused by conflicting unsequenced accesses. A compiler run is an observation, not proof that an undefined expression has a guaranteed result. Avoid using such an expression as a numeric-output exercise.
Writing pseudocode or a code fragment that ignores the stated input constraints, such as assuming nonempty input or using a sentinel loop that fails on the first element.
Candidates focus on the happy path and do not test their written answer against boundary cases before moving on.
What to do instead
Before finalizing any constructed response, run three cases mentally: empty or zero input, a single element, and a duplicate or maximum value. Adjust the loop bounds and initializations so each case is handled, and state the assumption explicitly if the problem permits it.
Converting between binary, decimal, and hexadecimal by treating the digits as ordinary base-10 place values, for example writing 0.1 decimal as 0.0001 binary or translating 2 KB as 2000 bytes without noticing the prefix convention the question uses.
Candidates memorize '1 KB = 1024 bytes' from consumer packaging and never build a positional-value model, so digit-by-digit conversion feels like a copying exercise rather than a weighted sum.
What to do instead
Convert by explicit place-value expansion: write each bit's weight (128, 64, 32, 16, 8, 4, 2, 1) above the digit, circle the powers that sum to the target, and group bits in fours for hex. State whether the stem uses SI or binary prefixes before computing.
Ordering the memory hierarchy by capacity instead of by proximity to the CPU, or explaining cache as 'extra RAM' that stores whole programs, so questions about locality, hit rate, or why a loop over a large array runs slowly get answered with speed-of-RAM claims.
The slogan 'cache is fast memory' is recalled in isolation, without a mental picture linking registers, L1, L2, L3, RAM, and disk along shared axes of latency, size, cost, and volatility.
What to do instead
Draw the hierarchy once as a ladder from registers to disk and label each rung with typical latency and typical size. Then rehearse locality: explain why the same loop is faster after a warm-up pass and why row-major traversal of a 2-D array beats column-major.
Equating every TLB miss with a disk-backed page fault.
The shortcut substitutes a label for the actual mapping, system state or measurable requirement, so it can select a technically inappropriate remedy.
What to do instead
Track translation-cache lookup separately from page-table residency and protection. A TLB miss can resolve to a valid resident page, while a fault may indicate permission rather than a missing disk page.
Choosing a software architecture from a fashionable label without a measurable constraint.
The shortcut substitutes a label for the actual mapping, system state or measurable requirement, so it can select a technically inappropriate remedy.
What to do instead
State the actual quality scenario, failure assumptions, interfaces and evidence. Compare trade-offs rather than assuming microservices or an event bus automatically improve every quality attribute.
Filtering grouped results in a WHERE clause (for example WHERE COUNT(*) > 5), comparing a column to NULL with = instead of IS NULL, or assuming UNION and JOIN do the same thing when combining two tables.
WHERE is encountered first in every tutorial and gets generalized to all filtering, and NULL is treated as an ordinary value rather than as unknown, which produces wrong intuitions about three-valued logic.
What to do instead
Classify every filter before writing it: row-level predicates go in WHERE, group-level predicates go in HAVING, and any NULL test uses IS NULL or IS NOT NULL. Sketch the result table for JOIN (horizontal, matched columns) versus UNION (vertical, matching schemas) to fix the distinction.
Declaring a table well designed because it 'looks organized', while leaving a transitive dependency such as storing instructor name and office in a course-enrollment table, or designating a foreign key as the primary key without checking uniqueness.
Spreadsheet intuition treats any tidy grid as normalized, and the candidate checks only that a key exists rather than testing candidate keys against every functional dependency the scenario implies.
What to do instead
List the functional dependencies in plain sentences ('each course has one instructor, and each instructor has one office') before any table is drawn. Place every determinant on the left, split off any non-key dependency into its own relation, and verify that each relation's chosen key uniquely determines all its other attributes.
Converts between denary and two's complement or between binary and hexadecimal but drops the sign bit, forgets to state the number of bits, or performs subtraction by ordinary binary subtraction and reports a positive result for a negative answer.
Candidates learn the flip-and-add-one procedure as a ritual without understanding the fixed width, so leading zeros and the sign bit get lost and range questions become guesswork.
What to do instead
Always state the word length first, for example '8-bit two's complement'. Write out all bits including leading zeros and leading sign bits. Check by converting back. Learn the range formula for n bits, minus two to the power n minus one up to two to the power n minus one minus one, and use it to sanity-check every answer. For subtraction, convert to adding the two's complement and discard the final carry with a note saying so.
Compares data structures by naming them, for example 'a linked list is better than an array', without linking the choice to the operations required: insertion, deletion, search, and access by index, or to memory layout and static versus dynamic sizing.
Structures are memorised as definitions with a vague advantage attached, and candidates do not rehearse justifying a choice against a stated scenario.
What to do instead
For each structure (array, linked list, stack, queue, binary search tree, hash table) write its memory layout, the cost of access by index, search, insertion and deletion, and one scenario where it is the right choice. When answering, quote the scenario's dominant operation and justify with that cost, for example frequent insertion at the front favours a linked list because no elements need shifting. Use the same reasoning to explain why a stack suits recursion or expression evaluation.
The candidate confuses the roles of devices and at which layer each operates: hub versus switch versus router versus Layer 3 switch versus firewall versus wireless controller and AP, and which device terminates a broadcast domain or a collision domain.
Device names are learned from product categories, not from the OSI layer and forwarding behaviour. Broadcast and collision domain counting questions then become guesswork, and design questions produce topologies with a hub where a switch belongs.
What to do instead
For each device write three facts: OSI layer, unit of forwarding (bit, frame, packet), and effect on collision and broadcast domains. Then redo domain-counting exercises by marking every port and every link on a diagram before counting. Tie each device to one design rule you would defend.
Answering an impacts-of-computing prompt with a slogan, such as 'automation causes job loss' or 'algorithms are biased', without naming the mechanism, the affected group, or a plausible mitigation, and confusing patents, copyrights, and trademarks in intellectual-property items.
These questions read as opinion rather than analysis, so candidates write the first socially acceptable claim instead of constructing a cause-and-effect chain, and the three IP regimes blur together as 'legal protection'.
What to do instead
Use a fixed three-part structure: mechanism (what the system does), affected party (who bears the cost or benefit), and mitigation (policy, design, or access remedy). For IP, key on the object protected (invention, expression, brand identifier) rather than on the duration.