EGEL Plus Ciencias Computacionales common mistakes
EGEL Plus Ciencias Computacionales · Understand the traps and how to avoid them.
On relational-normalization items, stopping at 2NF or 3NF after removing partial dependencies but leaving transitive dependencies on non-key attributes, then declaring the schema normalized.
Candidates memorize the definitions in order but practice mostly with 1NF/2NF examples; they do not habitually test each non-key attribute against every candidate key, so transitive dependencies slip through.
What to do instead
Before selecting an answer, list all candidate keys and, for every non-key attribute, ask 'does this depend on a non-key attribute?' Repeat until no such dependency remains; verify the chosen normal form against that list rather than against a feeling of 'looks decomposed'.
In SQL query items, selecting an option that uses WHERE to filter on the result of an aggregate (e.g., WHERE COUNT(*) > 5) or that groups by a non-aggregated column not in GROUP BY.
Candidates translate the English requirement directly into SQL syntax without checking the logical evaluation order (FROM, WHERE, GROUP BY, HAVING, SELECT), and many practice sets never contrast WHERE vs HAVING side by side.
What to do instead
For each SQL option, annotate the clause order and mark any aggregate inside WHERE as automatically wrong; confirm every non-aggregated SELECT column appears in GROUP BY. Eliminate options on syntax-logic grounds before judging which returns the right rows.
On transaction/concurrency items, choosing the isolation level or locking scheme that prevents a named anomaly without checking whether it also permits a different anomaly described in the same scenario.
Candidates learn anomaly-to-isolation mappings as isolated facts (dirty read = READ UNCOMMITTED, etc.) and do not build the full hierarchy table, so they answer the first anomaly they recognize and ignore the second condition in the stem.
What to do instead
Reconstruct the isolation-level matrix (dirty read, non-repeatable read, phantom) from memory before answering, then check the scenario against every anomaly mentioned. If the stem names two anomalies, the answer must satisfy both.
On software-design items, picking the design pattern or architecture whose name matches a keyword in the stem (e.g., 'notify many objects' → Observer) without verifying that the stated constraints (coupling, extensibility, direction of dependency) are actually satisfied.
Keyword-to-pattern flashcards create a reflex; candidates do not read the constraints that distinguish, for example, Strategy from State or Adapter from Facade.
What to do instead
Ignore the pattern names on first pass. Write the required behavior and constraints from the stem, then test each option against them; discard any option that violates a stated constraint even if its name seems to fit.
On algorithm-complexity items, answering with the complexity of the most familiar implementation rather than the one specified, or confusing average with worst case when the stem asks for one explicitly.
Candidates memorize single big-O values per data structure (e.g., hash table = O(1)) without the qualifier, and skip the words 'worst case', 'amortized', or 'on average' in the stem.
What to do instead
Underline the case qualifier and the exact operation before evaluating options; recall the qualified complexity (hash lookup worst case O(n), balanced BST search O(log n)) and eliminate options that only hold under a different qualifier.
On subnetting and addressing items, computing the subnet mask or host range correctly but then choosing the broadcast or network address as a usable host, or misjudging the number of usable hosts (2^n vs 2^n − 2).
Candidates drill mask arithmetic but rarely practice the final step of excluding reserved addresses, and under time pressure they stop as soon as the arithmetic matches an option.
What to do instead
Adopt a fixed four-step routine: mask, block size, network address, usable range. Always subtract the network and broadcast addresses before matching, and write the first and last usable host explicitly.
On OSI/TCP-IP layer items, assigning a protocol or device to the layer where it is 'usually discussed' rather than where its function operates (e.g., placing a switch at layer 3, TLS at layer 4, or ARP at layer 2 only).
Layering is learned through protocol lists rather than function, and encapsulation/decapsulation is rarely traced end to end, so borderline cases are guessed.
What to do instead
For each device or protocol, state the unit of data it handles (frame, packet, segment, message) and the addressing it uses (MAC, IP, port); the layer follows from that, not from memorized lists.
On project-management items, applying a predictive/waterfall answer to a scenario that describes iterative delivery with changing requirements, or vice versa, because the methodology keyword rather than the risk and requirements profile drove the choice.
Candidates map methodologies to memorized slogans and do not extract the decision drivers (requirement volatility, regulatory constraints, team co-location, contract type) from the scenario text.
What to do instead
Before answering, list the scenario's explicit drivers (fixed scope vs evolving scope, contractual rigidity, feedback cadence) and choose the approach that the drivers support; reject any option that contradicts a stated constraint even if it is the 'modern' answer.
On operating-systems items, confusing concurrency hazards (race condition, deadlock, starvation, livelock) and selecting the mechanism (mutex, semaphore, monitor) that 'sounds safer' without matching it to the described symptom.
Definitions are memorized in isolation and the four necessary conditions for deadlock are rarely applied to scenarios, so similar-sounding symptoms are conflated.
What to do instead
Classify the symptom first: are processes blocked forever waiting on each other (deadlock), making no progress while changing state (livelock), or intermittently corrupting shared data (race)? Then check whether the proposed mechanism addresses that specific symptom.
On security items, choosing the control that mitigates the consequence of an attack rather than the vulnerability described, or selecting symmetric/asymmetric primitives that cannot provide the stated property (e.g., confidentiality vs non-repudiation, hashing vs encryption).
Candidates memorize control lists per threat category but do not separate prevention, detection, and recovery, nor the security property each cryptographic primitive delivers.
What to do instead
For each item, name the asset, the threat, and the required property (confidentiality, integrity, authenticity, non-repudiation) before reading options; eliminate any option that cannot deliver that property (e.g., a hash alone cannot provide confidentiality or non-repudiation).