EGEL Plus Informática common mistakes
EGEL Plus Informática · Understand the traps and how to avoid them.
Choosing the algorithm with the best big-O complexity even when the stated constraints (small fixed input size, memory limit, or readability requirement) make a simpler approach correct.
Candidates memorize complexity tables and treat asymptotic optimality as always the right answer, ignoring that the scenario specifies n is tiny or that memory is constrained.
What to do instead
Before selecting, restate the scenario's explicit constraints (input size, memory cap, maintainability). Pick the option that satisfies those constraints, not the one with the lowest theoretical complexity.
Confusing the purpose of a design pattern with its structure, e.g., labeling any creational need as Singleton or any decoupling need as Adapter without checking whether the described problem is object creation, interface conversion, or behavioral responsibility.
Pattern names are learned as vocabulary rather than as problem-solution pairs, so candidates pattern-match on keywords in the stem.
What to do instead
Classify the stated problem first (creation vs. interface mismatch vs. algorithm interchange vs. notification), then map to the pattern whose intent matches that classification.
In questions about requirements or user stories, accepting a vague statement as a valid requirement and rejecting a testable one because it looks too simple.
Candidates evaluate whether a statement sounds technical rather than whether it is verifiable, unambiguous, and bounded.
What to do instead
Test each requirement against verifiability criteria: can a pass/fail test be written for it? Reject options that lack measurable criteria, regardless of how sophisticated they sound.
Mixing up agile roles, artifacts, and ceremonies, e.g., assigning backlog prioritization to the Scrum Master or treating the sprint review as a retrospective.
Terminology overlaps across frameworks, and candidates rely on general impressions of what each role 'does' rather than the framework's defined accountabilities.
What to do instead
Build a small reference table of role-artifact-ceremony ownership per framework and, on each item, identify which specific artifact or ceremony the stem describes before answering.
Selecting a project management response based on what is ideal in theory rather than what the described methodology or contract type prescribes.
Candidates answer from personal workplace experience, which may not match the methodology (predictive vs. adaptive) or the contractual context given in the stem.
What to do instead
Identify the methodology and constraints stated in the stem first, then choose the action consistent with that framework's prescribed process, even if it differs from your workplace practice.
Confusing network-layer concepts, such as attributing port-level filtering to a router, assigning IP addressing to a switch, or placing a function at the wrong OSI layer.
Device functions and layers are learned as isolated facts, and the stem's vocabulary ('segment', 'frame', 'packet') is not used as a diagnostic cue.
What to do instead
Use the PDU and layer keywords in the stem to anchor the layer first, then recall which device or protocol operates at that layer before evaluating options.
Choosing a subnet or addressing answer without verifying it against the stated mask and host requirements, e.g., picking a range that overlaps or a size that cannot accommodate the required hosts.
Candidates estimate the answer mentally and skip the arithmetic check under time pressure.
What to do instead
Compute the block size from the mask, list the network and broadcast boundaries, and confirm the candidate answer fits the host count and does not overlap before selecting.
Treating normalization and performance as opposing absolutes, e.g., rejecting a denormalization option even when the scenario explicitly describes a read-heavy reporting workload with measured join cost.
Candidates learn 'normalize to 3NF' as a rule and do not adjust for the workload characteristics described in the stem.
What to do instead
Read the stated workload (read vs. write ratio, latency requirement) and choose the design trade-off that the scenario's evidence supports rather than the default rule.
Confusing SQL clause semantics in query-result questions, e.g., predicting rows for WHERE versus HAVING, or ignoring how NULL behaves in comparisons and aggregates.
Candidates reason about the query's apparent intent instead of executing the clause order and NULL rules step by step.
What to do instead
Evaluate the query in logical order (FROM, WHERE, GROUP BY, HAVING, SELECT), and explicitly apply three-valued logic wherever NULL can appear in a predicate or aggregate.
Selecting a control based on the threat it addresses while ignoring the governance or risk-management framing, e.g., choosing encryption when the stem asks for the appropriate risk treatment decision or the correct control category (preventive, detective, corrective).
Candidates focus on technical familiarity and skip classifying what the question actually asks: treatment option, control type, or governance responsibility.
What to do instead
Identify the question type first (risk treatment, control classification, or policy ownership), then evaluate options against that classification before considering technical merit.