ICT-Platform Dev Specialist FA common mistakes
ICT-Platform Dev Specialist FA · Understand the traps and how to avoid them.
When a scenario describes an integration that must survive downstream outages, the candidate proposes synchronous request/response calls for every step and omits retry, queueing, or dead-letter handling, then argues the design is 'simple'.
Candidates default to the REST call-per-step pattern they use daily and read 'must not lose orders' as a functional requirement rather than a reliability requirement, so they never evaluate decoupling, backpressure, or idempotency under failure.
What to do instead
Before designing, extract every reliability phrase in the prompt (no data loss, tolerate downstream downtime, duplicate delivery) and map each to a mechanism: asynchronous messaging or outbox, retries with exponential backoff and jitter, idempotency keys, and a dead-letter queue. State explicitly which component absorbs the failure and what the recovery path is.
The candidate lists technologies (API gateway, Kubernetes, Kafka, Redis) as the architecture answer without showing component responsibilities, data flow, or where state lives, and treats the diagram-free description as sufficient.
Tool names feel like architecture and are easy to recall under time pressure, while articulating boundaries, ownership of state, and failure domains requires deliberate structuring that candidates skip.
What to do instead
Answer in layers: first the logical components and their single responsibility, then the request/data flow step by step, then state ownership and consistency model, and only then the concrete products. If a choice is named, justify it against one alternative and one constraint from the prompt.
On a coding or pseudocode item, the candidate writes a solution that passes the happy path but ignores the stated edge conditions (empty input, duplicate keys, concurrent updates, pagination boundaries) that the prompt explicitly calls out.
Candidates optimize for producing working-looking code quickly and skim the requirement list, so boundary conditions mentioned in the last sentence of the prompt are dropped.
What to do instead
Before writing code, list the constraints and edge cases from the prompt in one line each, then implement and mentally trace at least the empty, single-element, and duplicate cases. Reserve the final minutes to re-read the prompt and tick off each stated condition against the code.
The candidate chooses a data model or index without connecting it to the access pattern, for example normalizing everything to third normal form for a read-heavy reporting workload or adding indexes on every column 'for speed'.
Academic normalization rules are strongly memorized, while the discipline of deriving schema from query patterns and write/read ratios is practiced less and is harder to verbalize.
What to do instead
Start from the queries: list the top read and write operations, their frequency, and their consistency needs. Choose normalization versus denormalization, index columns, and partition keys from that list, and state the write-amplification or storage cost each index introduces.
When asked to design an API, the candidate returns only successful-response shapes and omits error contracts, status-code semantics, pagination, versioning strategy, and idempotency for retried writes.
Candidates picture the consumer's happy path and treat error handling as implementation detail, so the contract-level decisions that distinguish a robust API are never surfaced.
What to do instead
Structure the answer as a contract: resources and verbs, request/response schemas, a table of error conditions mapped to status codes with a stable error body, pagination and filtering conventions, versioning approach, and idempotency mechanism for unsafe methods. Mention at least one backward-compatibility rule.
The candidate describes a deployment pipeline that jumps from commit to production without environment promotion, automated gates, rollback, or a migration strategy for stateful changes.
Deployment questions are read as 'how do containers get built and shipped', and candidates answer the build mechanics while overlooking promotion, approval, and reversibility, which are the actual risk controls.
What to do instead
Describe the path as stages (build, test, stage, canary or blue-green, production) with the automated check and approval at each gate. Include rollback for both stateless and stateful components, and specify how schema migrations are backward compatible during the rollout window.
The candidate treats authentication as authorization, answering a permissions question with 'the user logs in with SSO and gets a token' and never defines who may perform which action on which resource.
Login flows are concrete and familiar, while authorization models (roles, scopes, policy evaluation, resource ownership) require a separate mental step that candidates collapse into the authentication answer.
What to do instead
Separate the two explicitly: identify the identity provider and token format for authentication, then define the authorization model (RBAC roles or ABAC policies), where enforcement happens (gateway versus service), and how the service validates scope and resource ownership on each call.
Asked how to detect a degradation, the candidate lists dashboards and 'monitor the logs' without naming the signals, thresholds, or the user-facing indicator that would page someone.
Monitoring is associated with tooling rather than with measurement design, so candidates name products instead of defining what is measured and what action a breach triggers.
What to do instead
Answer with the four golden signals or equivalent (latency percentiles, error rate, saturation, traffic), the specific metric and threshold for each, the alert routing and severity, and one synthetic check tied to the user journey. Distinguish symptom-based paging from cause-based debugging dashboards.
The candidate describes testing as 'unit tests plus some integration tests' without stating what each level covers, where the boundary sits, or how the change would be gated in CI.
Test pyramid vocabulary is recalled as a slogan, and candidates do not translate it into coverage responsibilities, test data strategy, or pipeline enforcement for the scenario given.
What to do instead
Assign each level a responsibility: unit for pure logic and branches, integration for contracts and persistence against real dependencies via containers, end-to-end for critical journeys only. State the CI gate (coverage of changed lines, contract tests passing) and how flaky or slow suites are handled.
On governance or lifecycle items, the candidate answers with process words such as 'code review' and 'documentation' but cannot say what artifact is produced, who owns it, or which decision it records.
Governance feels like common sense, so candidates give generic practices instead of the concrete artifacts (decision records, review checklists, dependency and change policies) that the question is testing.
What to do instead
For each practice, name the artifact, its owner, and the trigger: architecture decision records for irreversible choices, a review checklist tied to the risk areas, dependency update and vulnerability policy with SLAs, and a change approval path for production-impacting releases. Tie each to a scenario detail.