ICT-App Dev Specialist FA common mistakes
ICT-App Dev Specialist FA · Understand the traps and how to avoid them.
When asked to design a data model, the candidate lists entities and attributes but never defines primary keys, foreign keys, or the cardinality of each relationship, so the schema cannot be implemented without further decisions.
Candidates memorize entity-relationship vocabulary and assume naming the entities is the deliverable. Exam prompts often describe a scenario in prose, and translating prose into a normalized schema with explicit keys requires deliberate practice that many candidates skip in favor of reviewing definitions.
What to do instead
For every data-modelling prompt, produce a table of entities with a primary key column, then a relationship list written as 'A 1..* B via foreign key B.a_id'. State cardinality in both directions and note any junction tables for many-to-many relationships. Practise converting three-paragraph scenarios into this format under time pressure.
The candidate writes pseudocode for an algorithm that handles the happy path only, ignoring empty input, duplicate records, or a requested operation that cannot be completed, and loses marks on the error-handling criteria.
Exam scenarios usually embed edge conditions in a sentence or two of the stem, and candidates under time pressure code the obvious flow first and run out of time to revisit. Many also treat error handling as boilerplate rather than a graded requirement.
What to do instead
Before writing pseudocode, underline every condition word in the stem (empty, duplicate, invalid, exceeds limit, not found). Build a short checklist of at least three boundary cases and show explicit handling for each in the pseudocode. Reserve the final few minutes to re-read the stem against the answer.
Asked to choose between approaches such as a relational database versus a document store, or client-side versus server-side validation, the candidate names a technology and asserts it is 'more scalable' or 'best practice' without tying the choice to the stated constraints.
Candidates revise technology pros and cons as generic lists and then pattern-match a keyword in the stem to a memorized answer. They do not extract the actual constraints (data volume, consistency needs, offline use, team skills) that should drive the decision.
What to do instead
Answer in a fixed structure: list the two or three constraints the stem actually states, state which option satisfies each, name the trade-off accepted, then give the recommendation. If a constraint is unstated, say the decision depends on it and state what you would assume. Practise writing this in four sentences.
The candidate describes a testing strategy as 'unit tests, integration tests, and user acceptance testing' without saying what each level covers for the specific feature described, who runs it, or what a pass looks like.
Testing questions reward specificity, but candidates recall the vocabulary from general reading and reproduce the pyramid as a label list. They have rarely written a test plan for a described feature, so they lack concrete examples to draw on.
What to do instead
For each test level, write one sentence naming the component under test, the input, and the expected observable result. Include at least one negative test case and one boundary value. Anchor everything to the feature in the stem rather than describing testing in the abstract.
When a question involves state management or data flow, the candidate describes the mechanism (for example, a shared store) but never states where the single source of truth lives, when it is updated, or how the UI reflects the change.
Modern frameworks make state handling implicit, so candidates who build apps casually have never had to articulate the flow. Exam stems often describe a multi-screen scenario where stale or duplicated state is the actual problem being tested.
What to do instead
Draw a three-line flow: event, state update, re-render. Explicitly name the owner of each piece of state and mark which components read versus write it. For multi-screen scenarios, state which screen owns the data and how the others receive it, and call out what happens on refresh or back navigation.
The candidate answers an API design question with endpoint names only, omitting request and response shapes, status codes for failure cases, and how authentication or pagination is handled.
Endpoint naming feels like the substance of API design, and candidates stop once they have produced plausible URLs. They underestimate how much of the mark allocation sits in contract details and error semantics.
What to do instead
For each endpoint, write method, path, request body fields with types, success response with status code, and at least two error responses with codes. Add one line on auth and one on pagination or filtering. Keep a reusable template and apply it to every API question.
Given a performance or reliability symptom, the candidate proposes a fix such as caching or adding a queue immediately, without first stating how they would confirm the cause or what evidence would change their diagnosis.
Candidates study remedies as a list of patterns and jump to the pattern that matches a keyword. Troubleshooting questions are usually graded on the diagnostic sequence, and skipping it forfeits the reasoning marks even when the final suggestion is reasonable.
What to do instead
Structure the answer as: symptom, hypotheses ranked, cheapest diagnostic for each, then the fix contingent on the finding. Include one measurement (latency percentile, error rate, log signal) that would confirm or rule out each hypothesis before naming a remedy.
The candidate treats security as a separate checklist item and fails to mention input validation, output encoding, or authorization checks at the point in the design where user-supplied data enters the system.
Security is often revised as a standalone topic, so it stays detached from design questions. Under time pressure, candidates answer the functional question and forget to weave security controls into the data flow they just described.
What to do instead
After drafting any design answer, run a two-minute pass asking where untrusted input enters and where sensitive data leaves. Add one sentence per point covering validation, encoding, and the authorization check. Keep this as a standard closing paragraph in every design response.
The candidate describes deployment or version control practice only in general terms ('use branches, do code review, deploy through CI') and never addresses rollback, environment configuration, or how a failed release is detected.
These topics are usually learned by absorption on the job rather than studied, so candidates can describe the normal path but have not reasoned about failure paths. Exam stems about release process usually hinge on exactly those failure paths.
What to do instead
For any release question, cover four things explicitly: how configuration differs per environment, what automated gate blocks a bad build, how a failure is detected in production, and the concrete rollback step with its time bound. Write these four lines once and adapt them per prompt.
The candidate writes long narrative answers that bury the decision, so the marker must infer the recommendation, and any partially correct reasoning is lost inside prose that also contains contradictions.
Candidates equate length with thoroughness and write stream-of-consciousness under exam pressure. Without a visible structure, an early incorrect assumption contaminates the rest of the answer and the candidate never returns to reconcile it.
What to do instead
Lead with a one-sentence recommendation, then give numbered justification, then a short risks section. Cap each justification at two sentences. Before finishing, re-read only the first sentence of each paragraph to confirm the argument is consistent and the recommendation is unmistakable.