Ruankao System Analyst (Senior) common mistakes
Ruankao System Analyst (Senior) · Understand the traps and how to avoid them.
In the afternoon essay (论文), the candidate writes a general essay about the topic (e.g., microservices, requirements management) built from textbook definitions, with only one or two vague sentences about a real project, and never states the candidate's own role, project scale, or measurable results.
Candidates prepare by memorizing topic knowledge and treat the essay as a knowledge test. Under time pressure they default to definition-dumping because it feels safe, and they are reluctant to invent or disclose project detail. The essay actually tests whether you can apply method to a concrete practice, so a knowledge-only essay scores low on the application and practice dimensions even when the theory is correct.
What to do instead
Before the exam, prepare two or three real projects in a reusable template: background and scale (users, transaction volume, team size, duration), your exact role and responsibilities, the problem, the method you applied with concrete steps and parameters, the obstacles, quantified outcomes, and lessons learned. In the essay, allocate roughly the first 10 percent to project context, 60-70 percent to how you applied the method with specifics, and the rest to results and reflection. Every claim about a technique should be tied to a decision you made in that project.
In case-study questions (案例分析), the candidate answers from general knowledge instead of extracting constraints from the scenario text, producing answers that are plausible in the abstract but contradict stated facts such as budget limits, legacy interfaces, regulatory requirements, or team skill levels.
Case studies are long and time-constrained, so candidates skim and pattern-match to a familiar problem type. They then write the standard answer for that pattern without checking whether the scenario's constraints rule it out. The marking scheme awards points for constraints explicitly honored, so generic answers lose the differentiating marks.
What to do instead
Read the questions first, then read the case with a pen, underlining every constraint, number, stakeholder, and stated pain point. Before writing, list the constraints in the margin and check each proposed answer against them. Where a trade-off exists, state the trade-off explicitly and justify the choice using the scenario's own numbers. Practice by re-answering past cases and marking whether each sentence cites a fact from the text.
The candidate confuses similar architecture-quality concepts and their measurement, for example treating availability, reliability, and maintainability as interchangeable, or asserting that adding redundancy automatically improves all quality attributes without discussing cost, complexity, and failure modes.
Fundamentals material is often memorized as lists of quality attributes without the underlying definitions, metrics, and tactics. Under exam pressure, candidates reach for the most familiar buzzword (usually availability) and apply it to every scenario, missing that the question asked about modifiability, testability, or performance.
What to do instead
Build a one-page table mapping each quality attribute to its definition, its measurable metric (e.g., availability as uptime percentage and MTBF/MTTR; performance as response time and throughput; modifiability as cost and effort of a defined change), its architectural tactics, and its trade-offs. For each past question, first identify which attribute the scenario actually stresses, then select tactics and state the cost of each.
When asked to design a database schema or normalize relations, the candidate produces tables without declaring primary keys, foreign keys, and cardinality, or stops at third normal form without checking whether the resulting design still satisfies the stated query and performance requirements.
Candidates learn normalization as a mechanical procedure and treat reaching 3NF as the finish line. They omit key and constraint declarations because the procedure focuses on functional dependencies, and they do not connect the schema back to the workload described in the scenario, so the design is theoretically clean but practically unjustified.
What to do instead
Adopt a fixed output order: entities and relationships with cardinality, then relations with primary keys underlined and foreign keys annotated, then normalization justification, then denormalization or indexing decisions tied to the stated query patterns and data volumes. Always include a sentence on integrity constraints and one on performance implications. Rehearse with timed exercises where the marking criteria include keys and constraints.
In requirements engineering questions, the candidate lists requirements as a flat bullet list mixing business goals, functional requirements, non-functional requirements, and design constraints, with no traceability, priority, or acceptance criteria.
The exam often asks for 'the requirements of the system', and candidates respond with whatever features come to mind. They have not internalized the classification and traceability discipline, and under time pressure a flat list looks complete. Markers, however, look for classification, verifiability, and traceability links, so the answer loses structure marks even when the features are right.
What to do instead
Always structure requirement answers by layer: business requirements, stakeholder needs, functional requirements, non-functional requirements with measurable targets, and constraints. Give each requirement an identifier and, where relevant, a trace link to a goal or a design element. Write non-functional requirements with numbers (e.g., response time under a stated load, availability percentage). Add acceptance criteria for the highest-priority items.
On network and security questions, the candidate answers with a single control (e.g., 'use a firewall' or 'encrypt the data') without identifying the threat, the asset, the trust boundary, or the residual risk, and without distinguishing authentication from authorization or confidentiality from integrity.
Security is often studied as a list of technologies rather than as risk reasoning. Candidates memorize controls and deploy them by association with keywords. The exam increasingly asks for threat analysis and defense-in-depth reasoning, where a single control is by definition an incomplete answer.
What to do instead
Answer security scenarios in a fixed sequence: assets and data classification, threat and attacker model, trust boundaries and attack surface, then controls mapped to each threat across prevention, detection, and response, then residual risk and monitoring. Explicitly separate authentication, authorization, auditing, confidentiality, integrity, and non-repudiation. Cite the relevant mechanism (e.g., TLS for transport confidentiality, digital signatures for integrity and non-repudiation) and its limitation.
When a question involves project scheduling or estimation, the candidate computes a critical path or earned value figure but omits the interpretation, or applies a formula without checking units and dependencies, producing a numerically correct but contextually wrong conclusion.
Candidates drill formulas in isolation and then rush the arithmetic under time pressure. They also treat the calculation as the answer rather than as evidence for a management decision, so they fail to state schedule status, variance meaning, or corrective action.
What to do instead
For every quantitative question, write the formula, substitute values with units, compute, then write one or two sentences interpreting the result in management terms (ahead or behind schedule, over or under budget, which activities are critical and which have float). Sanity-check magnitudes (e.g., a schedule performance index far from 1 should prompt a recheck). Practice with past papers and verify against worked solutions.
The candidate treats emerging-technology questions (cloud native, big data, AI/ML, blockchain, IoT) as vocabulary tests, giving a definition and a list of benefits with no architecture pattern, data flow, or adoption risk, and no link to the enterprise application context in the scenario.
These topics change quickly, so candidates rely on marketing-level familiarity. They lack hands-on architecture experience with the technology and therefore fall back on definitions. The exam expects the candidate to reason about fit, integration, governance, and risk, which a definition cannot demonstrate.
What to do instead
For each major emerging technology, prepare a compact card: core mechanism, typical reference architecture and data flow, when it is and is not appropriate, integration points with legacy systems, security and compliance concerns, cost and operational model, and one concrete failure mode. In answers, always connect the technology to the scenario's business goal and state at least one adoption risk and mitigation.
In the English section, the candidate translates word by word, leaves technical terms in Chinese inside an English sentence, or writes long ambiguous sentences that obscure the subject and the action, and misreads English question stems that contain negation or conditionals.
Candidates with adequate reading ability but limited production practice default to literal translation. They also skim English stems quickly and miss words such as 'except', 'not', or 'most appropriate', which flips the required answer. Technical writing conventions (one idea per sentence, active voice, defined terms) are rarely practiced.
What to do instead
Practice reading English stems slowly and marking negation and conditional words before answering. For production, use a fixed pattern: subject, verb, object, one idea per sentence, defined acronyms at first use, and consistent terminology. Keep a glossary of standard English terms for architecture, requirements, and testing so you never code-switch mid-sentence. Review past English items and rewrite your answers for concision.
The candidate manages time poorly across the paper: spending too long on early multiple-choice items, leaving the essay unfinished or without a conclusion, and skipping the review step that would catch misread questions and arithmetic slips.
The exam is long and mentally taxing, and candidates do not rehearse under realistic timing. Anxiety about difficult early items causes over-investment, and the essay, which carries large marks, is left with insufficient time. Without a review pass, avoidable errors survive.
What to do instead
Rehearse full papers under strict timing with a written time budget per section (e.g., a hard cap per multiple-choice item, a fixed block for case analysis, and a protected block for the essay including a conclusion). Mark uncertain items and move on. Reserve the final minutes for a review pass focused on question stems, units, and completeness of the essay's structure. Track your time splits after each practice run and adjust.