Industrial Engineer Information Processing common mistakes
Industrial Engineer Information Processing · Understand the traps and how to avoid them.
Treating every UML relationship as an association and drawing plain lines where the stem calls for aggregation, composition, or generalization, then answering the multiplicity question from that wrong diagram.
Candidates memorize box-and-line syntax but never learn the semantic tests (lifetime dependency for composition, is-a for generalization, whole-part for aggregation), so the diagram looks plausible and the error goes unnoticed until the answer choices expose it.
What to do instead
Before drawing, classify each pair with a one-line test: 'Does the part die with the whole?' (composition, filled diamond), 'Can the part exist independently?' (aggregation, hollow diamond), 'Is it a kind of?' (generalization, hollow triangle). Build a 10-item drill set and re-derive the diagram from the scenario text rather than from memory of a similar past question.
Choosing the design pattern whose name matches a keyword in the scenario (for example picking Observer because the word 'notify' appears) instead of matching the pattern's intent and structure to the stated forces.
Pattern names are memorable and the exam deliberately seeds trigger words; candidates pattern-match on vocabulary rather than on the problem's coupling and extension requirements.
What to do instead
For each candidate pattern write the intent in one sentence and check it against the scenario's stated change axis ('new algorithms added often' -> Strategy; 'subscribers react to state change' -> Observer; 'one interface over incompatible APIs' -> Adapter). Eliminate options whose intent names a different change axis before selecting.
Confusing cohesion and coupling goals, or labeling a module 'highly cohesive' when it performs several unrelated tasks simply because it is small.
Cohesion and coupling are taught together and the definitions blur under time pressure; size feels like a proxy for quality.
What to do instead
Apply the single test: cohesion is about how strongly related the responsibilities inside one module are; coupling is about how many assumptions one module makes about another. Judge each module by listing its responsibilities in one phrase each; if two phrases are unrelated, cohesion is low regardless of module size.
Reading a code snippet and predicting output by mental execution while ignoring the language's evaluation order, short-circuit rules, or pass-by-value vs pass-by-reference semantics for the specific language named.
Candidates carry habits from another language (for example assuming objects are passed by reference in Java, or that && and & behave identically) and the snippet is designed to exploit exactly that.
What to do instead
Before tracing, write the language and version at the top, then annotate each operator with its evaluation rule. Trace with a variable table (name, value after each line) instead of in your head, and mark short-circuited operands as 'not evaluated'.
Mixing up black-box and white-box test design techniques, or applying statement and branch coverage interchangeably and concluding that 100% statement coverage implies 100% branch coverage.
Coverage metrics sound similar and candidates rarely compute a small example by hand, so the containment relationship between them is not internalized.
What to do instead
Memorize the containment: branch coverage subsumes statement coverage, not the reverse. Practice on a 5-line if/else snippet: construct a test set with full statement coverage but a missed branch (an empty if body) to see the gap concretely, then re-answer the question.
Writing a SQL answer that returns the right rows but the wrong grain because a JOIN multiplies rows, then reporting an inflated aggregate such as a doubled SUM or COUNT.
Candidates validate the query by eyeballing a few rows rather than by reasoning about cardinality, and one-to-many joins silently duplicate the aggregated side.
What to do instead
State the intended grain in words before writing SQL ('one row per customer per month'). Check every JOIN's cardinality, and when aggregating across a one-to-many join, aggregate in a subquery first or use COUNT(DISTINCT ...). Verify with a row count before and after the join.
Treating NULL as an ordinary value, using = NULL, or assuming NULL participates normally in NOT IN and aggregate functions.
Three-valued logic is counterintuitive; candidates reason in two-valued boolean terms and forget that NOT IN with a NULL in the list yields no rows.
What to do instead
Adopt fixed rules: test with IS NULL / IS NOT NULL, remember NULL propagates through comparisons to UNKNOWN, and remember that COUNT(*) counts rows while COUNT(col) skips NULLs. When a query returns unexpectedly zero rows, check for NOT IN against a nullable column first.
Normalizing to 3NF reflexively and then failing the performance or denormalization question, or the reverse: denormalizing without stating which anomaly is being accepted.
Candidates learn normalization as a single 'correct' answer and treat denormalization as an error, missing that the exam asks for a justified trade-off.
What to do instead
Answer normalization questions by naming the anomaly removed at each step (update, insert, delete) and the functional dependency used. For performance questions, explicitly state the accepted redundancy, the read/write ratio that justifies it, and the consistency mechanism (trigger, batch job, application logic).
Mixing up implementation and operation activities, for example classifying a parallel (phased) cutover or a regression test during migration as 'operation' rather than 'implementation', or attributing acceptance testing to the operations phase.
The phase boundaries overlap in practice, and candidates map activities by feel rather than by the phase's exit criteria.
What to do instead
Anchor on deliverables: implementation ends when the system is accepted and in production (installation, migration, cutover, acceptance test); operation begins with service delivery (monitoring, backup, incident and capacity management). Sort each activity by asking which phase's completion criterion it serves.
Confusing backup types and recovery objectives, treating a differential backup as cumulative-from-last-full when it is not, or selecting a recovery strategy without checking whether RTO and RPO are both satisfied.
Full, differential, and incremental backups are defined by their reference point, and RTO/RPO are memorized as definitions rather than applied as constraints.
What to do instead
Draw a timeline: full at day 0, differential always references the last full, incremental references the last backup of any type. For recovery questions, write RTO (time to restore) and RPO (acceptable data loss) as numbers and test each proposed strategy against both; a strategy that meets RPO but exceeds RTO is wrong.
Answering security questions by naming a control without placing it correctly in the threat model, for example proposing encryption at rest to stop SQL injection, or confusing authentication with authorization.
Controls are learned as a list and candidates match on the word 'security' rather than on which asset, threat, and attack path the scenario describes.
What to do instead
For each scenario write asset -> threat -> attack path -> control, and reject any control that does not sit on that path. Keep the authentication (who you are) versus authorization (what you may do) distinction explicit, and check whether the control is preventive, detective, or corrective before choosing.
Applying the CIA triad as a checklist and picking 'availability' or 'integrity' for every scenario, or ignoring that a stated countermeasure trades one property against another.
The triad is easy to recite but candidates do not map scenario language to the specific property under attack, and they miss the trade-off the question is testing.
What to do instead
Read the scenario for the harmed property: disclosure -> confidentiality, unauthorized modification -> integrity, service loss -> availability. When a control is proposed, name the property it strengthens and the one it may weaken (for example encryption strengthening confidentiality while adding key-management availability risk).
Memorizing ITIL-style process definitions and then answering 'who does what' questions from the definition rather than from the process's purpose and scope, producing answers that are terminologically correct but functionally wrong.
Service management vocabulary is dense and similar across processes (incident vs problem vs change), so candidates select by word familiarity.
What to do instead
Build a one-line purpose statement for each process and a discriminator: incident restores service fast, problem removes the root cause, change controls risk of modification. Answer by asking which purpose the scenario's stated goal matches, not which term appears in the stem.