Bhutan Civil Service Main Examination (ICT Category) common mistakes
Bhutan Civil Service Main Examination (ICT Category) · Understand the traps and how to avoid them.
Writing generic textbook definitions of e-Government and governance without citing Bhutan's specific initiatives (e-GIF, G2C services, Dzongkhag ICT infrastructure, national digital identity), so answers read as if they could apply to any country.
Candidates prepare from foreign textbooks and generic online notes, and treat the Bhutan-specific policy paper as an optional add-on rather than the core of the answer.
What to do instead
Build a one-page reference sheet of named Bhutanese initiatives with dates and responsible agencies, and practise attaching at least two concrete Bhutanese examples to every policy answer before writing the recommendation section.
Producing a normalisation answer that lists 1NF, 2NF, 3NF definitions but never actually decomposes the given relation into tables with keys, so the examiner cannot see the result.
Candidates memorise definitions and freeze when asked to transform a concrete schema under time pressure.
What to do instead
Drill a fixed five-step routine on paper: list attributes, identify candidate keys, find partial dependencies, find transitive dependencies, then draw the final relations with primary and foreign keys marked. Do ten full decompositions timed at eight minutes each.
Writing code answers in prose or pseudocode when the question asks for a program, or writing code with no comments and no stated complexity.
Candidates are anxious about syntax errors and default to describing the algorithm instead of committing to code, and they underestimate how much marks come from complexity justification.
What to do instead
Practise writing complete, compilable solutions in one chosen language (usually C or Java) with a one-line comment per logical block, and always end with an explicit time and space complexity statement plus a short edge-case note.
Answering network questions with layer names only, never computing anything: no subnet masks, no host counts, no CIDR block arithmetic, no step-by-step packet flow.
Subnetting is avoided during preparation because it feels arithmetic-heavy, so candidates hope for descriptive questions and panic when numbers appear.
What to do instead
Do a daily ten-minute subnetting drill covering mask-to-prefix conversion, usable host counts, and splitting a /24 into required subnets, and rehearse one standard packet-flow narrative (DNS lookup, ARP, TCP handshake, HTTP request) until it can be written from memory.
Treating security answers as a list of buzzwords (firewall, IDS, encryption, VPN) without mapping each control to a specific threat, asset, or layer.
Security topics are learned as vocabulary lists from summaries rather than as threat-and-control reasoning.
What to do instead
For every control named, force the sentence pattern 'this mitigates [specific threat] against [specific asset] at [layer or stage]', and practise the CIA triad plus defence-in-depth framing on three past scenario questions per week.
In system analysis and design answers, skipping the feasibility study, requirement elicitation, and alternative comparison, and jumping straight to a DFD or ER diagram.
Candidates equate SDLC with drawing diagrams and forget that methodology marks come from the process narrative and justification.
What to do instead
Use a fixed answer skeleton: problem statement, stakeholders, elicitation methods, functional and non-functional requirements, feasibility (technical, economic, operational, legal), chosen methodology with justification, then models. Practise the skeleton until it is automatic.
Defining operating system concepts abstractly (paging, deadlock, scheduling) without a worked example, calculation, or comparison table.
These topics are memorised as definitions, and candidates never practise the numeric or comparative forms the question actually rewards.
What to do instead
For each core topic prepare one worked numeric example (average waiting time for a scheduling algorithm, page-fault walk-through, Banker's algorithm safety check) and one comparison table, and write them out from memory weekly.
Giving vague, unbalanced answers on emerging technology questions, either pure hype with no limitations or pure scepticism with no use case, and never linking to Bhutanese context such as cloud hosting constraints, connectivity, or AI in public service delivery.
Candidates rely on news headlines rather than structured understanding, so they cannot weigh benefits against risks.
What to do instead
Answer every emerging-tech question in four fixed blocks: definition and mechanism, concrete use case, limitations and risks (including data sovereignty, bandwidth, skills, cost), and a Bhutan-relevant recommendation. Prepare one example per technology in advance.
Losing marks in General Aptitude by leaving data interpretation and logical reasoning sets unfinished, or by attempting them last with no time budget.
Candidates spend disproportionate time on a single tough puzzle or calculation and run out of time for easy marks elsewhere.
What to do instead
Adopt a fixed paper strategy: allocate a hard time cap per section, do a first pass taking only questions solvable in under ninety seconds, mark and return later, and practise full-length timed mocks weekly with a written time log to find where minutes are lost.
Writing web and mobile development answers that describe a stack at a high level but omit validation, authentication, session handling, and accessibility, and give no code or architecture sketch.
Candidates learn frameworks by name and skip the cross-cutting concerns that examiners use to separate strong from average answers.
What to do instead
Prepare a reusable answer template covering client, server, database, API contract, authentication and authorisation, input validation, error handling, and accessibility, and include a short code snippet or component diagram in every such answer.