Saarland Vocational Informatics, basic level - independent foundations common mistakes
Saarland Vocational Informatics, basic level - independent foundations · 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.
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.
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.
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.
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).