ITEE FE common mistakes
ITEE FE · Understand the traps and how to avoid them.
Spending disproportionate time on calculation-heavy questions in the first pass and running out of time for the shorter conceptual items near the end of the paper.
Candidates treat the exam as a pure maths test, get absorbed in one derivation, and lose track of the overall clock; the FE paper mixes quick recall items with longer numeric work, so pacing errors compound.
What to do instead
Do a first pass answering only items solvable in under a minute, flag the rest, then return. Practise with a timer in blocks of 20 questions and record per-block time so you learn your personal cut-off for abandoning a question.
Choosing an answer from the first plausible-sounding option without eliminating the others, especially on definitional questions about project constraints, roles, and process models.
Recognition bias: familiar terminology makes an option feel correct even when it subtly violates a condition in the stem, such as confusing verification with validation or a project manager with a programme manager.
What to do instead
For every item, state in one sentence why each rejected option is wrong before selecting. Where two options seem right, find the single word in the stem that discriminates them (scope, cost, quality, timing) and choose on that basis.
Answering ethics and legal questions from personal opinion or workplace habit rather than from the professional obligation the question is testing.
Candidates reason from what their own organisation tolerates, and the FE ethics items often set up a conflict between loyalty to an employer and duty to the public or to a code of conduct.
What to do instead
Learn the hierarchy explicitly: public safety and law first, then professional codes, then employer instructions. For each scenario, identify who bears the risk and what a reasonable, documented escalation would be, then match to the option that protects the public interest while staying within the code.
Misreading units and prefixes in numeric items, mixing bits and bytes, milliseconds and microseconds, or decimal and binary multiples, and then selecting the answer that matches the misread arithmetic.
Exam stems deliberately include distractors computed from the wrong unit, and under time pressure candidates skip the conversion step because the numbers look familiar.
What to do instead
Before calculating, write the given quantity with its unit and the required unit side by side, and convert explicitly. Sanity-check the magnitude: if a result implies a network faster than the medium allows or storage larger than the stated capacity, recheck the conversion.
Applying a memorised formula or configuration to a scenario without checking the assumptions behind it, for example using a simple queuing formula where arrival rates exceed service capacity, or a subnet mask that does not fit the required host count.
Rote preparation produces pattern matching: the stem contains a keyword that triggers a remembered procedure, and the candidate never tests whether the preconditions hold.
What to do instead
After choosing a method, spend ten seconds verifying its preconditions against the stem (utilisation below one, address space sufficient, failure rates independent). If a precondition fails, switch method rather than forcing the numbers.
Confusing similar technology concepts that differ by one property, such as encryption versus hashing, symmetric versus asymmetric keys, circuit versus packet switching, or compiled versus interpreted execution.
These pairs share vocabulary and are learned together, so retrieval under stress returns the wrong member of the pair; the exam exploits exactly this proximity.
What to do instead
Build comparison tables with three columns: property, concept A, concept B. Include one distinguishing test question per row (reversible? requires shared secret? ordered delivery?). Review by covering a column and reconstructing it.
Treating development-process questions as general knowledge and picking the textbook-correct answer while ignoring the constraints stated in the scenario, such as team size, regulatory audit needs, or unstable requirements.
Candidates memorise that agile is modern and waterfall is rigid, then default to agile even when the stem describes fixed contractual scope with heavy documentation requirements.
What to do instead
Extract the constraints from the stem into a short list before looking at the options, then score each option against that list. The correct answer is the one that fits the stated constraints, not the one that is generally fashionable.
Skipping the test-design step in questions that ask how many test cases are needed, or which technique applies, and instead guessing from the technique name alone.
Coverage questions look like trivia but require actually applying equivalence partitioning or boundary analysis to the stated ranges; candidates answer from the label rather than from the partition.
What to do instead
For each such item, sketch the partitions and boundaries on scratch paper, count the values including the invalid ones, and only then compare with the options. Note that boundary analysis adds values at each edge of each partition, which changes the count.
Ignoring operational aspects such as backup, monitoring, rollback, and change control when a scenario asks for the best next action during an incident or release.
Candidates focus on the technical fix and forget that the exam tests operational discipline: restoring service safely and preserving evidence often outranks root-cause analysis in the correct option.
What to do instead
For incident items, rank the options by immediate risk reduction and reversibility. Prefer the option that restores service or preserves data with a documented rollback over the option that investigates causes first, unless the stem says service is already stable.
Leaving items blank or changing correct answers late in the paper based on a vague feeling of unease rather than new evidence from the stem.
Fatigue and anxiety near the end produce second-guessing; without a rule, candidates overwrite reasoned answers with guesses, and unanswered items score zero even where partial knowledge would have sufficed.
What to do instead
Adopt a fixed policy: answer every item, mark uncertain ones, and only change an answer when you can name a specific fact or stem detail that was missed. Review flagged items once, then stop revisiting them.