CPN CPE Computer Engineering common mistakes
CPN CPE Computer Engineering · Understand the traps and how to avoid them.
Computing cache hit ratio or average memory access time (AMAT) using the total number of accesses instead of separating hits and misses, or forgetting to add the miss penalty to the hit time in the AMAT formula.
Candidates memorize AMAT = hit time + miss rate × miss penalty but then plug in the total access count as the denominator, or they compute only the miss portion and report it as the average. Under exam time pressure the formula gets half-remembered and the arithmetic is done quickly without a sanity check on whether the answer is between hit time and miss penalty.
What to do instead
Before computing, write the three quantities explicitly: hit time, miss rate (misses ÷ total accesses), miss penalty. Compute AMAT and verify it lies strictly between hit time and hit time + miss penalty. If the result is outside that band, the setup is wrong. Practice with a worked example where the miss rate is stated as a fraction and as a percentage to build the habit of converting correctly.
Deriving a Boolean expression or next-state equation from a truth table or state diagram and failing to minimize it, or minimizing with a Karnaugh map but ignoring don't-care conditions, producing an implementation that is logically correct in simulation but has more gates than the intended answer.
Candidates jump straight to a sum-of-products from the truth table and stop, treating minimization as optional. Don't-cares are skipped because they look like incomplete data rather than design freedom. The result is a correct but non-minimal expression, and on multiple-choice items the minimal form is usually the only option offered.
What to do instead
Adopt a fixed pipeline: truth table → K-map with don't-cares marked as X → group largest power-of-two rectangles → read off minimized SOP or POS → verify by re-expanding two or three minterms. Always check whether the question asks for minimal SOP, minimal POS, or a specific gate count, because those give different answers. Practice problems with unused input combinations to build the don't-care reflex.
Confusing page faults with segmentation faults, or describing virtual-to-physical translation without correctly placing the TLB, page table walk, and page fault handler in the sequence.
The terms sound similar and both involve memory access failure, so candidates conflate them. The translation sequence has several stages and candidates learn it as a list of words rather than a causal chain, so they misorder TLB lookup and page-table walk or claim a TLB miss always causes a page fault.
What to do instead
Write the chain once by hand: CPU issues virtual address → TLB lookup → on TLB miss, hardware or OS walks the page table → if PTE invalid or not present, page fault trap to OS → OS loads page, updates PTE and TLB → instruction restarts. Memorize the key distinction: TLB miss is a performance event handled without OS involvement in hardware-managed schemes; page fault is an exception requiring OS service. Segmentation fault is a protection violation, not a missing page.
Applying subnetting arithmetic to the wrong mask boundary, for example computing usable hosts as 2^n instead of 2^n − 2, or misidentifying the network and broadcast addresses when the prefix is not a multiple of 8.
Candidates memorize 2^n − 2 for a classful /24 and then apply it mechanically to non-octet-aligned prefixes, or they borrow bits in the wrong octet. The arithmetic is simple enough that it feels safe, so no verification step is performed.
What to do instead
For every subnetting problem, first write the prefix in binary and mark the boundary bit position. Then compute host bits = 32 − prefix, usable hosts = 2^(host bits) − 2 for traditional subnets (note /31 point-to-point and /32 host exceptions). Confirm the network address by ANDing the address with the mask, and confirm broadcast by setting all host bits to 1. Do three drills with prefixes like /19, /27, and /30 before the exam.
Answering software design and testing questions by naming a pattern or test type without justifying it against the stated constraints, for example recommending Singleton for a scenario that requires testability, or claiming unit tests cover integration behaviour.
Pattern names and test categories are easy to recall, so candidates pattern-match on keywords in the stem rather than reading the constraints (concurrency, testability, coupling, latency). The question usually hinges on a trade-off the candidate never evaluated.
What to do instead
Read the stem twice and underline the constraint words before looking at options. For design questions, state the trade-off explicitly in your reasoning: what the pattern buys and what it costs. For testing questions, map each option to the level it actually exercises (unit, integration, system, acceptance) and reject options that claim a level they cannot reach. Practice writing one-sentence justifications for each rejected option.
Reporting the wrong asymptotic complexity because the analysis counts loop iterations rather than the growth of the dominant operation, or because amortized and worst-case costs are conflated (for example calling dynamic-array append O(n)).
Candidates count visible loops and multiply nesting levels, which fails for recursive algorithms, divide-and-conquer recurrences, and amortized structures. Worst-case and amortized are treated as synonyms because the distinction is rarely exercised in casual programming.
What to do instead
For loops, derive the iteration count as a function of n and take the dominant term. For recursion, write the recurrence T(n) and solve it (substitution or Master Theorem) rather than guessing. For amortized structures, state the accounting argument: n appends cost O(n) total because doubling gives geometric growth, so each append is O(1) amortized but O(n) worst case. Always label which complexity you are reporting.
Writing SQL that answers a slightly different question than asked, typically by filtering in WHERE instead of HAVING for aggregate conditions, or by using an inner join where a left outer join is needed to preserve unmatched rows.
The syntax is familiar and candidates write the query that comes to mind first. Aggregate filtering and outer-join semantics are the two places where a syntactically valid query silently returns the wrong row set, so there is no error to prompt a rethink.
What to do instead
Before writing, state in words what each output row represents and which rows must survive even with no match. If the condition involves an aggregate, it belongs in HAVING. If unmatched left-side rows must appear, use LEFT JOIN and be careful that a WHERE predicate on the right table does not silently convert it to an inner join (move it to the ON clause). Test mentally with a row that has no match.
Choosing a cryptographic primitive by name recognition rather than by the security property required, for example using a hash for confidentiality, ECB mode for multi-block data, or a plain hash for password storage.
AES, SHA-256, and RSA are familiar tokens, and candidates associate them with 'security' generically. The mapping from requirement (confidentiality, integrity, authenticity, key exchange, password verification) to primitive is the actual skill being tested and is often skipped.
What to do instead
Classify the requirement first: confidentiality → symmetric encryption with an authenticated mode (AES-GCM); integrity and authenticity → MAC or digital signature; key exchange → Diffie-Hellman or ECDH; password storage → salted, slow KDF (bcrypt, scrypt, Argon2). Explicitly reject ECB for anything longer than one block. For each option, name the property it provides and check it against the requirement.
Analyzing a real-time scheduling problem with average-case reasoning, for example judging rate-monotonic schedulability by CPU utilization alone without checking the utilization bound or performing response-time analysis for the given task set.
General-purpose OS intuition says a system is fine if utilization is below 100 percent. Hard real-time correctness depends on worst-case execution time and deadline satisfaction, which candidates do not habitually compute. The utilization bound for rate-monotonic scheduling (n(2^(1/n) − 1)) is remembered approximately or not at all.
What to do instead
For rate-monotonic scheduling, compute total utilization and compare to the bound for the task count n; if it exceeds the bound, do exact response-time analysis (R_i = C_i + sum of ceiling interference from higher-priority tasks) rather than declaring failure. For earliest-deadline-first, note that utilization ≤ 1 is sufficient for schedulability on a single processor. Always use worst-case execution times, never averages.
Treating professional ethics items as opinion questions and selecting the answer that sounds most accommodating to the client or employer, rather than applying the duty to public safety, competence limits, and conflict-of-interest disclosure.
Candidates read ethics items the way they read workplace-advice questions and optimize for being agreeable. Codes of ethics are specific: paramount obligation to public safety, disclose conflicts, do not practice outside competence, and report rather than conceal. The 'reasonable-sounding' option often violates one of these.
What to do instead
For each ethics scenario, identify which duty is engaged: public safety, competence, conflict of interest, confidentiality, or truthful reporting. Eliminate options that conceal a known hazard, accept work outside your competence without disclosure, or defer a safety issue to a manager who has no authority over it. The correct answer is usually the one that documents and escalates through the proper channel while protecting the public.