UPMSP Intermediate Computer common mistakes
UPMSP Intermediate Computer · Understand the traps and how to avoid them.
When subtracting binary numbers, the candidate borrows 1 and adds it as 1 to the next column instead of adding the full base value 2, producing a wrong result such as 1001₂ − 0110₂ = 0111₂.
The candidate memorised decimal borrowing (borrow 1, add 10) and mechanically transfers the rule without restating it in base 2, where a borrow supplies 2 to the current column. The same habit then breaks subtraction in octal and hexadecimal.
What to do instead
Before every subtraction, write the base at the top of the working area and say the borrow rule aloud: a borrow adds the base value (2 for binary, 8 for octal, 16 for hex) to the current column. Do five binary subtractions by converting to decimal and back to check, then do five more with direct column subtraction and verify with addition (difference + subtrahend = minuend).
The candidate converts a decimal fraction such as 0.375 to binary by repeatedly multiplying and then writes the remainders in the order produced, giving 0.011₂ instead of 0.011₂ reversed correctly - or stops after one or two multiplications and truncates.
Fraction conversion reuses the integer algorithm's vocabulary (multiply, remainder) but reads the digits in the opposite direction, and the candidate has practised only integer conversions. The process also terminates only when the fractional part reaches zero, which the candidate does not check.
What to do instead
Treat integer and fraction conversion as two separate recipes: integers divide and read remainders bottom-up; fractions multiply by the base and read the integer digits top-down. Practise ten fractions with terminating binary forms (0.5, 0.25, 0.75, 0.375, 0.125) and always verify by adding the place values back to the decimal value.
The candidate computes 2's complement of a negative number by inverting the bits only, forgetting to add 1, and therefore misreads the stored bit pattern of a signed integer.
The name '2's complement' invites the candidate to think the inversion is the whole operation. The add-1 step is easy to drop under exam time pressure, especially when the question is phrased as 'find the representation of −5' rather than 'apply the algorithm'.
What to do instead
Use a fixed three-step written template every time: write the magnitude in 8 bits, invert all bits, add 1, then state the range check (−128 to +127 for 8-bit signed). Reverse the process to check: invert and add 1 again and confirm you recover the original magnitude.
The candidate lists a flowchart's shapes or a pseudocode snippet's output by tracing it once from top to bottom, ignoring that a loop body executes multiple times, and reports the value after the first pass.
Flowchart and pseudocode questions are read like prose rather than simulated. The candidate does not maintain a variable table, so the loop counter's changing value is held only in memory and the exit condition is evaluated carelessly.
What to do instead
For every algorithm-tracing question, draw a two-column table of variable names and values and add one row per statement execution, crossing out old values. Mark each loop test with a tick or cross for true/false. Never write the final answer until the table shows the loop condition failing.
The candidate answers a 'which sorting/searching method is this' question by matching a keyword in the question ('divide') to the wrong algorithm, for example calling binary search a divide-and-conquer sort or confusing bubble sort with selection sort.
Algorithm names are learned as vocabulary lists rather than as procedures with distinguishing invariants. Bubble sort's adjacent swaps and selection sort's single swap per pass are not contrasted, so the candidate relies on surface wording.
What to do instead
Build a one-page comparison table with columns for what is compared, when swaps happen, number of passes, best and worst case, and a two-line trace on the array 5, 3, 8, 1. Redo the trace from memory a day later and check the swap counts match the table.
The candidate writes an SQL query that selects the right columns but omits GROUP BY when an aggregate such as COUNT or AVG is mixed with a plain column, or puts a filtering condition in WHERE when it belongs in HAVING.
The candidate writes SQL in the order the words come to mind (SELECT, FROM, WHERE) rather than the logical evaluation order, and has not internalised that grouping happens before aggregate functions are computed.
What to do instead
Write queries in the fixed order FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, then rearrange into the required syntax. For each query, underline every aggregate and confirm each non-aggregated selected column appears in GROUP BY. Test on a small two-table example and predict the row count before running.
The candidate labels a primary key as a field that merely 'identifies a record' but then accepts a table design where the chosen key can repeat or be null, or confuses primary key with foreign key in a two-table relationship.
Definitions are memorised as slogans without the two testable properties (uniqueness and non-null). Referential integrity is understood as a phrase rather than as a rule about matching values across tables.
What to do instead
Apply a two-question test to every proposed key: can two rows share this value, and can it be blank? If either answer is yes, it is not a primary key. Then draw two related tables and mark the primary key in one and the foreign key in the other with an arrow, and state which table's values must already exist.
The candidate describes the OSI or TCP/IP model by listing layer names in the wrong order, or places a device or protocol at the wrong layer, for example putting a switch at the network layer or HTTP at the transport layer.
Layer stacks are memorised as a sequence of words without an anchor for what each layer actually does. Device and protocol placement is then guessed from the name rather than from the addressing or function involved.
What to do instead
Anchor each layer to one concrete artefact: hub and repeater at physical, MAC address and switch at data link, IP address and router at network, port number and TCP/UDP at transport, HTTP and SMTP at application. For any device or protocol question, first ask 'what does it address or act on?' and derive the layer from that answer.
The candidate answers a URL-structure or web-technology question by calling the whole address a domain name, or claims a web page is the same thing as a website, and cannot separate protocol, host, path, and query parts.
Everyday browsing hides the structure of a URL, so the candidate has never had to parse one. Terms like domain, host, website, and web page are treated as synonyms because they are used loosely in conversation.
What to do instead
Take five real URLs and label each part by hand: scheme, subdomain, domain, top-level domain, port, path, query string, fragment. Then write one sentence each defining web page, website, web server, and search engine, and check that no two sentences could be swapped.
The candidate treats cyber safety as a list of good behaviours and answers scenario questions with a generic 'be careful online' rather than naming the specific threat and the specific countermeasure, such as failing to distinguish phishing from pharming or a virus from a worm.
Safety topics are revised as moral advice rather than as technical definitions with distinguishing features. Scenario questions reward precise identification, and the candidate's vague answer cannot earn those marks.
What to do instead
Make a threat table with columns for how it spreads, whether it needs user action, a real-life example, and the exact countermeasure (for example phishing: arrives by message and needs a click, countered by verifying the sender and typing the address directly; worm: self-propagates over a network without user action, countered by patching and firewalls). Answer scenario questions by naming the threat first, then the countermeasure.