IBM Full Stack Software Developer common mistakes
IBM Full Stack Software Developer · Understand the traps and how to avoid them.
Choosing a Git operation that discards work (hard reset, forced checkout, deleting a branch) when the scenario asks to undo a commit while keeping changes or to recover a lost commit.
Candidates memorize command names without mapping each command to its effect on the working tree, staging area, and commit history, so 'undo' is treated as a single concept rather than a choice among revert, reset --soft/--mixed/--hard, and reflog recovery.
What to do instead
Build a one-page matrix of Git commands by state affected (working tree, index, HEAD, history) and rehearse three scenarios: revert a pushed commit, unstage a file, and recover a dangling commit with reflog. Before answering, state aloud which state must be preserved, then pick the command that touches only the other states.
Treating a REST API status code as interchangeable with a similar one (200 vs 201 vs 204, 401 vs 403, 400 vs 422) when asked what a correct endpoint should return for a given situation.
Candidates learn status codes as a list to memorize rather than as semantics tied to resource creation, authentication versus authorization, and malformed versus semantically invalid input, so plausible-sounding codes get selected.
What to do instead
Learn codes in contrast pairs: 401 means identity unproven, 403 means identity known but not permitted; 400 means the request is malformed, 422 means well-formed but fails validation; 201 must accompany a created resource and often a Location header; 204 means success with no body. Practice by writing the handler for each case and naming the code you would emit.
Confusing Python list mutability and aliasing, predicting that a function which appends to a list argument leaves the caller's list unchanged, or mixing up shallow and deep copy behaviour.
Candidates coming from pass-by-value languages assume arguments are copied, and they skim code instead of tracing object identity, so shared references and in-place methods like sort versus sorted are misjudged.
What to do instead
Trace small snippets by drawing references: name the object, draw arrows from each variable, and mark which operations mutate in place. Memorize that list methods such as append, sort, and extend mutate and return None, while sorted, slicing, and copy return new objects, and that copy.copy is shallow. Run each snippet mentally against that drawing before choosing.
Answering SQL questions by pattern-matching keywords instead of reasoning about join type and NULL semantics, for example using INNER JOIN when unmatched rows must be preserved or assuming WHERE col != 'x' includes NULL rows.
Candidates memorize syntax but not set semantics, so they miss that LEFT JOIN keeps unmatched left rows, that COUNT(col) skips NULLs while COUNT(*) does not, and that comparisons with NULL yield unknown rather than true.
What to do instead
For each query, first write in words which rows must survive, then choose the join. Test edge cases explicitly: rows with no match, NULL in the filtered column, and duplicates. Remember NULL requires IS NULL or IS NOT NULL, and use COUNT(*) when all rows should count. Sketch the two tables as sets and shade the required result before writing SQL.
Mishandling JavaScript asynchronous behaviour, assuming code after a fetch or await runs before the response is available, or mispredicting output order for promises, timers, and synchronous code.
Candidates read async code as if it were sequential and do not hold a clear model of the event loop, microtasks, and macrotasks, so output-order questions and error-handling questions are answered by intuition.
What to do instead
Memorize the ordering rule: synchronous code first, then promise callbacks (microtasks), then timers (macrotasks). Practice predicting output for snippets mixing console.log, Promise.resolve().then, and setTimeout, and remember that await pauses only its own async function. For errors, wrap awaited calls in try/catch or attach .catch, and never assume data exists immediately after initiating a request.
Conflating React state and props or mutating state directly, and misjudging when a component re-renders or when useEffect runs relative to render.
Candidates learn component syntax before the data-flow model, so they treat props as writable, push into state arrays in place, or expect a state update to be visible on the next line.
What to do instead
Internalize one rule: props flow down and are read-only, state is owned locally and changed only through the setter, and updates are batched and asynchronous, so read the new value in the next render or inside the updater function. Replace in-place mutation with new objects or arrays. For effects, state the dependency array and whether cleanup is needed before deciding what the effect does.
Confusing container image build-time with container run-time, for example expecting ENV or RUN changes made after a container starts to persist, or believing a Dockerfile COPY of local files works without a build context.
Candidates treat a Dockerfile like a script that executes at launch, so they mix build instructions, runtime configuration, and orchestration concerns such as port publishing and volume mounts.
What to do instead
Separate the three layers explicitly: build (FROM, COPY, RUN, build context), run (CMD, ENTRYPOINT, published ports, mounts, environment overrides), and orchestration (replicas, services, health checks). Remember each RUN creates a layer at build time and each container start begins from the image, so runtime changes vanish unless stored in a volume. For any question, first ask whether it happens at build or at run.
Treating Kubernetes objects as interchangeable, such as expecting a Deployment to provide stable pod identity or a Service to schedule pods, and misreading which object owns scaling, networking, or configuration.
Candidates learn object names as vocabulary without the responsibility boundaries, so Deployments, Services, ConfigMaps, Secrets, and Ingress blur together, and questions about stable DNS or rolling updates get answered with the wrong object.
What to do instead
Map each object to one job: Deployment manages replicated stateless pods and rolling updates, Service gives a stable virtual IP and load-balances to pods selected by labels, Ingress routes external HTTP by host and path, ConfigMap and Secret inject configuration, and StatefulSet provides stable identity. When reading a scenario, name the requirement (identity, discovery, configuration, exposure) and select the object that owns it.
Answering cloud questions by service name association rather than by responsibility model, for example describing IaaS as including managed runtime patching or assuming a managed database removes the need to design backups and access control.
Candidates memorize product labels and marketing categories, so they misplace the split between provider-managed and customer-managed concerns, which is exactly what the responsibility-model questions test.
What to do instead
Anchor every answer to the shared responsibility split: the provider secures the physical layer and, for managed services, the underlying platform; the customer always owns data, identity and access configuration, and application code. For each service, ask what the provider patches and what remains yours. Practice classifying the same workload as IaaS, PaaS, and SaaS and listing who handles OS patching, runtime, and data in each.
Describing a CI/CD pipeline as a single step or reversing build and deploy order, for example claiming tests run after deployment or that continuous delivery means every change is automatically released to users.
Candidates conflate continuous integration, continuous delivery, and continuous deployment, and they have not pictured the pipeline stages, so ordering and gating questions are answered from the acronym rather than the flow.
What to do instead
Memorize the stage order and its gates: commit triggers build, then automated tests and static checks, then artifact packaging, then deploy to staging, then approval-gated production release. Distinguish delivery (always releasable, release is a decision) from deployment (release is automatic). When a scenario asks where a failure should stop the pipeline, place it at the earliest stage that can detect it.