Ruankao Embedded System Designer (Intermediate) common mistakes
Ruankao Embedded System Designer (Intermediate) · Understand the traps and how to avoid them.
Converting between binary, decimal, and hexadecimal by treating the digits as ordinary base-10 place values, for example writing 0.1 decimal as 0.0001 binary or translating 2 KB as 2000 bytes without noticing the prefix convention the question uses.
Candidates memorize '1 KB = 1024 bytes' from consumer packaging and never build a positional-value model, so digit-by-digit conversion feels like a copying exercise rather than a weighted sum.
What to do instead
Convert by explicit place-value expansion: write each bit's weight (128, 64, 32, 16, 8, 4, 2, 1) above the digit, circle the powers that sum to the target, and group bits in fours for hex. State whether the stem uses SI or binary prefixes before computing.
Ordering the memory hierarchy by capacity instead of by proximity to the CPU, or explaining cache as 'extra RAM' that stores whole programs, so questions about locality, hit rate, or why a loop over a large array runs slowly get answered with speed-of-RAM claims.
The slogan 'cache is fast memory' is recalled in isolation, without a mental picture linking registers, L1, L2, L3, RAM, and disk along shared axes of latency, size, cost, and volatility.
What to do instead
Draw the hierarchy once as a ladder from registers to disk and label each rung with typical latency and typical size. Then rehearse locality: explain why the same loop is faster after a warm-up pass and why row-major traversal of a 2-D array beats column-major.
Treating volatile as proof that shared firmware state is synchronized.
A local observation or language feature does not establish the wider state, timing or end-to-end guarantee required by the scenario.
What to do instead
Identify atomic widths, ownership, interrupt/task contexts, publication ordering and the actual platform protocol. Volatile alone does not establish mutual exclusion or general atomicity.
Using average response time as proof of meeting a required worst-case deadline.
A local observation or language feature does not establish the wider state, timing or end-to-end guarantee required by the scenario.
What to do instead
Analyze the stated execution, blocking, interrupt and interference bounds under the real scheduler, then verify relevant cases with appropriate tests and authority.
Equating every TLB miss with a disk-backed page fault.
The shortcut substitutes a label for the actual mapping, system state or measurable requirement, so it can select a technically inappropriate remedy.
What to do instead
Track translation-cache lookup separately from page-table residency and protection. A TLB miss can resolve to a valid resident page, while a fault may indicate permission rather than a missing disk page.
Mixing up pre-increment and post-increment, or assuming left-to-right evaluation of function arguments, in code-tracing questions.
Candidates read expressions as mathematical notation rather than as sequenced side effects, and evaluation order of arguments is often unspecified in the language being tested.
What to do instead
Separate side effects into individual statements and trace the specified language and version. Distinguish a permitted but unspecified order from undefined behavior caused by conflicting unsequenced accesses. A compiler run is an observation, not proof that an undefined expression has a guaranteed result. Avoid using such an expression as a numeric-output exercise.
Writing pseudocode or a code fragment that ignores the stated input constraints, such as assuming nonempty input or using a sentinel loop that fails on the first element.
Candidates focus on the happy path and do not test their written answer against boundary cases before moving on.
What to do instead
Before finalizing any constructed response, run three cases mentally: empty or zero input, a single element, and a duplicate or maximum value. Adjust the loop bounds and initializations so each case is handled, and state the assumption explicitly if the problem permits it.
Choosing a software architecture from a fashionable label without a measurable constraint.
The shortcut substitutes a label for the actual mapping, system state or measurable requirement, so it can select a technically inappropriate remedy.
What to do instead
State the actual quality scenario, failure assumptions, interfaces and evidence. Compare trade-offs rather than assuming microservices or an event bus automatically improve every quality attribute.
Candidates rely on generic project-management intuition for the information systems and technology fundamentals section, guessing at questions on network topologies, database normalisation, encryption and authentication, or system integration architectures, and they skip the laws, regulations and standards items assuming they are common sense.
The technology and legal domains feel peripheral to the 'management' identity of the exam, so study time is concentrated on the ten management knowledge areas. The technical vocabulary is broad and candidates cannot judge which terms they actually know.
What to do instead
Allocate a fixed weekly block to the technical fundamentals, covering networking basics, database and normalisation concepts, information security principles including symmetric versus asymmetric encryption and authentication factors, and common integration styles. For law and standards, learn the specific obligations and thresholds rather than slogans, and note which standard applies to which artefact. Use short recall quizzes rather than long reading so gaps surface quickly.
Answering an impacts-of-computing prompt with a slogan, such as 'automation causes job loss' or 'algorithms are biased', without naming the mechanism, the affected group, or a plausible mitigation, and confusing patents, copyrights, and trademarks in intellectual-property items.
These questions read as opinion rather than analysis, so candidates write the first socially acceptable claim instead of constructing a cause-and-effect chain, and the three IP regimes blur together as 'legal protection'.
What to do instead
Use a fixed three-part structure: mechanism (what the system does), affected party (who bears the cost or benefit), and mitigation (policy, design, or access remedy). For IP, key on the object protected (invention, expression, brand identifier) rather than on the duration.
Using 'encryption' and 'hashing' as synonyms, calling a salted hash reversible, or treating authentication and authorization as the same check, so a question about password storage or access control is answered with the wrong primitive.
Both techniques transform data into an unreadable-looking string, and the candidate has memorized the word 'secure' instead of the direction of the mapping: encryption is reversible with a key, hashing is one-way.
What to do instead
Sort every scenario into a table with columns for reversible, key required, and purpose. Passwords are salted and hashed slowly; stored files are encrypted symmetrically; keys are exchanged asymmetrically. Then separate the two access questions: who are you (authentication) versus what may you do (authorization).
Treating the CIA triad as three interchangeable words and answering 'confidentiality' for any control that involves encryption or passwords, even when the scenario is about data being altered in transit or a system being unavailable.
Candidates memorise the acronym but never attach a decision test to each leg, so under time pressure they match on the surface keyword (encryption, password) rather than on the security property the scenario actually describes.
What to do instead
Before answering, write one line: what is the harm in the scenario - someone reading it (confidentiality), someone changing it (integrity), or nobody being able to use it (availability)? Then pick the control that addresses that harm. Practise with mixed scenarios where a hash protects integrity, a backup protects availability, and encryption protects confidentiality.