Praxis Computer Science common mistakes
Praxis Computer Science · Understand the traps and how to avoid them.
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.
Writing loop bounds one off, such as iterating an n-element array with i <= n or starting a search at index 1, and then reporting an out-of-range value or a missing final element as the program's output.
Mathematics notation counts from 1, and candidates translate a counted range directly into code without rehearsing how many times the loop body actually executes at the boundary.
What to do instead
Before answering, execute the loop with the smallest concrete case (n = 3, array [7, 8, 9]) and write the value of the index at entry and exit for each iteration. Confirm the last valid index is n - 1 and that the loop body runs exactly n times.
Predicting a function's output from its apparent purpose instead of tracing it, especially for recursion, pass-by-value parameter changes, or a local variable that shadows an outer one, so the candidate claims the caller's variable was modified when it was not.
Reading code for intent is faster than simulating it, and the candidate has no disciplined trace habit; recursion in particular is trusted as 'it must work' rather than expanded step by step.
What to do instead
Trace on paper with a stack of frames: each call gets its own box for parameters and locals, and every return value is written on the arrow back to the caller. Expand recursion to the base case and count total calls, not just the first level.
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.
Attributing the wrong job to the wrong device, such as saying a switch assigns IP addresses, a router forwards by MAC address, or a hub prevents collisions, when explaining how a packet travels across a subnet boundary.
The devices are taught as a list of names with vague 'networking' functions, so the candidate matches on familiarity rather than on the layer and address each device actually uses.
What to do instead
Anchor each device to a layer and an address type: hub repeats bits, switch forwards frames by MAC within a LAN, router forwards packets by IP between networks, and DHCP servers lease addresses. Re-explain one end-to-end request naming the device and address at each hop.
Treating TCP and UDP as interchangeable or as 'TCP is better', and asserting that HTTPS hides everything from an observer, including the domain name being contacted, rather than distinguishing what TLS protects from what remains visible in DNS and the handshake.
Reliability is conflated with quality, so latency-sensitive cases such as streaming or DNS lookups get assigned TCP by default, and 'encrypted' is heard as 'invisible' without a model of which fields travel in the clear.
What to do instead
Build a two-column comparison of TCP and UDP covering connection setup, ordering, retransmission, and the workloads each suits. For HTTPS, trace the sequence that still leaks metadata: DNS query, then SNI in the client hello, then the encrypted payload once keys are exchanged.
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.
Using 'encryption' and 'hashing' as synonyms, calling a salted hash reversible, or treating authentication and authorization as the same check, so a question about password storage or access control is answered with the wrong primitive.
Both techniques transform data into an unreadable-looking string, and the candidate has memorized the word 'secure' instead of the direction of the mapping: encryption is reversible with a key, hashing is one-way.
What to do instead
Sort every scenario into a table with columns for reversible, key required, and purpose. Passwords are salted and hashed slowly; stored files are encrypted symmetrically; keys are exchanged asymmetrically. Then separate the two access questions: who are you (authentication) versus what may you do (authorization).