HKIE Professional Assessment - Information Discipline common mistakes
HKIE Professional Assessment - Information Discipline · Understand the traps and how to avoid them.
Answering written questions in a purely narrative, essay style - describing what a good engineer would do in general terms - instead of structuring the answer as a problem definition, options considered, chosen approach with justification, and verification method, so that assessors cannot map the response to the competency being tested.
Candidates carry over habits from academic or management writing where prose breadth signals competence; the HKIE assessment scores against explicit competency attributes and expects evidence of engineering judgement traceable to each attribute, which flowing prose obscures.
What to do instead
Before writing, list the competency attributes the question touches and allocate a labelled paragraph to each: situation and constraints, engineering analysis, alternatives with trade-offs, decision and rationale, standards/regulatory basis, and how the outcome would be validated. Practise rewriting past answers into this skeleton and time yourself so the structure becomes automatic.
Citing standards, codes of practice, or ordinances by vague reference ("in accordance with the relevant IEC standard", "as required by the Ordinance") without naming the document, clause, or the obligation it imposes.
Day-to-day engineering communication often relies on shorthand because colleagues share context; in the assessment the examiner has no such context and cannot credit an unnamed reference, and vague citation also signals shallow familiarity.
What to do instead
Build a personal one-page reference sheet of the instruments you actually use - for example the relevant IEC 62305 parts for lightning protection, IEC 60364 / local wiring regulations for electrical installations, the PDPO for personal data, the Copyright Ordinance for software licensing, and the Buildings Energy Efficiency Ordinance for energy audits - and in every answer name the document and the specific requirement it drives.
Treating the Information Discipline as general IT project management and answering with schedule, budget, and stakeholder-management content while omitting the engineering of the information system itself - architecture, interface definition, data integrity, availability, and security controls.
Candidates from a delivery or consultancy background default to the vocabulary they use daily, and the discipline's breadth tempts them into generic management answers that feel safe but score nothing against technical attributes.
What to do instead
For every scenario, force at least one paragraph on system engineering substance: the reference architecture, the interfaces and their protocols, the failure modes and redundancy, the data model and integrity rules, and the security zoning. Keep a checklist of these five items and confirm each answer covers at least three.
Presenting a single solution with no alternatives, no quantified comparison, and no statement of the assumptions or constraints under which it is valid.
Practitioners often arrive at a workable design quickly and write it up as though it were the only option; the assessment rewards demonstrable engineering judgement, which is only visible when options are compared and assumptions are made explicit.
What to do instead
Adopt a fixed comparison format: state the constraints first (budget order of magnitude, availability target, regulatory limits, legacy interfaces), then two or three viable options scored against those constraints in a short table or bullet list, then the recommendation with the decisive reason and the conditions that would change it.
Ignoring the Hong Kong statutory and regulatory layer - omitting the Personal Data (Privacy) Ordinance, the Copyright Ordinance, the Telecommunications Ordinance and licensing regime, or the Buildings Energy Efficiency Ordinance - and answering as if only international good practice applied.
Many candidates trained or working mainly with overseas or vendor frameworks apply generic GDPR-style or ISO-only reasoning, and the local instruments that actually bind a Hong Kong engineer are not always front of mind.
What to do instead
Maintain a short local-compliance map: for each scenario identify the data protection, licensing, safety, and energy obligations that attach, and state the specific duty (for example the six data protection principles, or the requirement for a licence to operate a radiocommunications installation). Rehearse this mapping on three or four sample scenarios until it is reflexive.
Giving qualitative hand-waving where the question calls for calculation or sizing - saying a link is "sufficiently fast", a UPS "adequately sized", or a backup "adequate" without showing the load, the diversity factor, the growth allowance, or the resulting figure.
Under time pressure candidates avoid arithmetic they fear they will get wrong, and in practice sizing is often delegated to vendors or tools; the assessment is checking whether the engineer can defend a number.
What to do instead
Practise a small set of recurring calculations to fluency: bandwidth and throughput with protocol overhead, storage capacity with RAID and backup retention, UPS and battery autonomy from load and efficiency, and availability from MTBF/MTTR. Always show the formula, the inputs with units, the assumption for growth, and the result with a sanity check.
Describing security as a list of products (firewall, antivirus, IDS) rather than as a risk-based control set tied to identified threats, assets, and a defence-in-depth architecture with zoning and least privilege.
Product-list answers are common because procurement and vendor conversations are framed that way, and candidates without a security engineering background mistake tool names for a security argument.
What to do instead
Structure security answers as asset and threat identification, then controls mapped to each threat across prevention, detection, and recovery, with the network zoning and trust boundaries drawn explicitly. Reference a recognised framework by name (for example ISO/IEC 27001 control areas or IEC 62443 zones and conduits for operational technology) and state the residual risk accepted.
Writing answers that never state a professional or ethical judgement when the scenario contains a conflict - pressure to ship with known defects, a request to reuse licensed software beyond its terms, or a demand to hand over personal data - and instead resolving it purely technically.
Candidates read such scenarios as technical puzzles and answer the engineering question, missing that the assessment is also testing professional conduct and the willingness to advise, escalate, and record a position.
What to do instead
When a scenario contains a conflict, add an explicit professional-judgement paragraph: identify the duty owed and to whom, state the advice you would give in writing, the escalation path, the record you would keep, and the line you would not cross. Keep it concise and concrete rather than moralising.
Failing to close the loop on verification and handover - no acceptance criteria, test strategy, commissioning plan, as-built documentation, or operational support model - so the answer stops at design and implementation.
Design work is the visible, interesting part and candidates run out of time or attention before the verification stage, yet the assessment expects the full engineering lifecycle including proving the system works and can be operated.
What to do instead
Reserve the final section of every answer for verification: acceptance criteria tied to the requirements, the test levels (unit, integration, performance, security, failover), the commissioning and cutover steps, the documentation set handed over, and the support and maintenance arrangements. Write this section first if time is short, then fill in design.
Misallocating time across the paper - over-writing the first question until it becomes a treatise, then producing thin or incomplete answers to later questions that carry equal weight.
Early questions feel safest and candidates keep polishing them, while the marking scheme gives comparable credit per question; the result is a strong first answer and several failed ones.
What to do instead
Before starting, convert the paper into a time budget with a hard stop per question and a reserve for review. Write to a target length per question based on marks, use bullet structure to control sprawl, and if a question stalls, write the skeleton headings and move on so every question has a complete, if brief, answer.