CSC-210 common mistakes
CSC-210 · Understand the traps and how to avoid them.
When a question describes an iterative, feedback-driven process with short fixed-length cycles and a prioritized backlog, the candidate labels it 'Waterfall' or 'incremental' simply because requirements were documented up front, instead of distinguishing the iteration cadence and the role of customer collaboration.
Candidates memorize methodology names as slogans and match on a single keyword ('documentation' or 'plan') rather than on the defining mechanics: who owns scope, how often a working increment is produced, and how change is handled. Many have only seen one methodology in practice.
What to do instead
Build a comparison table with four columns: scope ownership, iteration length, deliverable cadence, and change-handling policy. For each practice question, write down which of the four columns the stem actually constrains before choosing an answer. Drill on contrast pairs (predictive vs. adaptive, iterative vs. incremental) until you can justify a rejection, not just a selection.
On requirements questions, the candidate classifies every stated need as a 'functional requirement' and misses that the stem is describing a quality attribute or constraint (e.g., response time under load, regulatory retention period, platform restriction), or accepts a solution-shaped statement as a requirement.
Functional requirements are the most familiar category, and nonfunctional requirements are often phrased in the same 'the system shall...' form. Candidates also conflate design decisions with requirements because both mention technology.
What to do instead
Practice rewriting each stem sentence into one of four buckets: function (what it does), quality attribute (how well), constraint (what it must comply with or run on), and assumption. Test for solution-shaping by asking 'does this name a specific technology or component?' If yes, it is design, not requirement. Do 20 short classification drills until the bucket is automatic.
The candidate applies a design principle by name (single responsibility, open/closed, dependency inversion, interface segregation) to a code snippet without checking the actual dependency direction or the reason-for-change, and picks the principle whose label sounds most aspirational.
Principle names are memorable but their operational tests are not. Candidates recognize vocabulary (e.g., 'abstraction') and assume the code embodies it, ignoring that the snippet may still instantiate concrete classes or bundle unrelated responsibilities.
What to do instead
For each principle, write a one-line operational test. Dependency inversion: do high-level modules compile without referencing concrete low-level classes? Single responsibility: can you name one actor who would request a change? Open/closed: can a new variant be added without editing existing files? Apply the test to the snippet before looking at the options.
In data-structure and complexity questions, the candidate answers with the average-case cost when the stem specifies worst-case (or vice versa), or confuses the cost of a single operation with the amortized cost over a sequence, such as a dynamic array append or a hash-table rehash.
Textbook tables are often memorized as a single column, and the average/worst distinction is dropped under time pressure. Amortized analysis is conceptually harder because the expensive step is rare, so candidates either ignore it or over-apply it.
What to do instead
Recreate the complexity table yourself with explicit average and worst columns for search, insert, and delete on arrays, linked lists, hash tables, balanced trees, and heaps. Then annotate which entries are amortized and why (occasional resize or rehash spread over many cheap operations). Before answering, underline the case word in the stem.
The candidate treats 'testing' and 'debugging' as interchangeable, or picks 'unit testing' as the answer whenever a defect is found late, instead of mapping the defect's origin and the level of the test that should have caught it (unit, integration, system, acceptance).
Both activities involve finding faults, and candidates learn the test levels as a list without associating each level with the class of defect it targets. The V-model's correspondence between test level and development artifact is rarely internalized.
What to do instead
Draw the V-model and, next to each test level, list the defect class it targets and the artifact it validates: unit against code units, integration against interfaces and contracts, system against requirements, acceptance against user needs. For any defect scenario, first name the artifact that was wrong, then the level that would have caught it.
When asked which branching strategy or workflow fits a scenario, the candidate chooses the most sophisticated option (e.g., full GitFlow with release and hotfix branches, or mandatory pull-request gates on every change) rather than matching branch lifetime and review overhead to team size, release cadence, and risk tolerance.
Candidates equate 'more process' with 'better engineering' and have seen advanced workflows praised online. They also overlook that long-lived branches increase merge conflict cost and delay integration feedback.
What to do instead
Frame each branching question around three variables: release cadence, number of concurrent releases to support, and team size. Short-lived feature branches plus trunk-based integration suit frequent releases; release branches suit parallel supported versions. State the tradeoff (integration frequency vs. release isolation) explicitly in your reasoning before selecting.
On estimation questions, the candidate treats story points as a time unit and converts them directly to hours, or computes an estimate from a single optimistic number without applying historical velocity, buffer, or the distinction between effort and duration.
Points feel like a proxy for time, and many teams misuse them that way. Candidates also skip the arithmetic step of dividing total effort by team capacity, so they under-account for parallelism and non-development time.
What to do instead
Practice the full chain: relative size in points, historical velocity per iteration, number of iterations, then calendar duration including capacity losses (leave, meetings, support). For any estimate question, write the formula you are applying and check whether the stem supplies velocity or capacity; if it does not, the correct answer is usually a range or a re-estimation request, not a precise date.
On security questions, the candidate confuses authentication with authorization, or selects encryption as the control for a threat that encryption does not address (e.g., injection, broken access control, or insider misuse of legitimate privileges), and overlooks input validation and least privilege.
Encryption is the most familiar security control, so it becomes a default answer. Authentication and authorization are often taught together, and the distinction blurs under exam pressure.
What to do instead
For each threat, ask two questions: is the attacker trying to prove identity (authentication), reach resources they should not (authorization), or inject data interpreted as code (validation/encoding)? Then match the control to the question. Memorize that encryption protects data in transit and at rest, not the logic of an application, and that least privilege limits blast radius rather than preventing injection.
The candidate answers professional-ethics scenarios by choosing the option most protective of the employer or the project deadline, rather than the option that satisfies the public-interest obligation, disclosure to the appropriate authority, and documented professional judgment.
Workplace norms reward loyalty and delivery, and candidates transfer that instinct to exam scenarios. Codes of ethics are read once and rarely rehearsed against concrete dilemmas.
What to do instead
Rehearse a fixed decision sequence for ethics stems: identify the affected public, identify the professional obligation, identify the least harmful action that still discloses the issue to someone able to act, and check whether the chosen option requires documented evidence. Practice on scenarios involving concealed defects, pressure to ship, and conflicts of interest until the sequence is reflexive.
The candidate answers questions about requirements traceability, change control, or configuration identification by describing the tool (a ticket tracker, a repository, a CI pipeline) instead of the artifact and linkage the question asks for, and so misses that traceability links requirements to design, code, and tests, not just to commits.
Modern tooling blurs the line between process and product, and candidates equate 'we use a tracker' with 'we have traceability'. The exam asks about the information model, not the software used to store it.
What to do instead
Define the traceability chain explicitly: stakeholder need, requirement, design element, code unit, test case, defect. For each question, identify which link is missing or broken and answer in terms of that link. Separately list what configuration identification, control, status accounting, and audit each require as records, so tool names never substitute for the artifact.