Software Construction
What to know
Construction is coding, unit-level verification, and integration. Candidates should understand coding standards, naming and readability, defensive programming, error handling vs exceptions, resource management, and concurrency basics (race conditions, deadlock, atomicity). Know integration strategies: big-bang, top-down, bottom-up, and continuous integration. Understand refactoring as behavior-preserving restructuring, and code smells (duplicated code, long method, god class, feature envy).
Construction quality tools include static analysis, linters, code review, and automated tests. Pair programming and code review are construction-phase practices that catch defects early, when they are cheapest to fix.
Traps in questions
- Refactoring vs rewriting: refactoring does not change external behavior; adding a feature is not refactoring.
- Exception misuse: using exceptions for normal control flow, or swallowing exceptions silently, are classic anti-patterns.
- Concurrency: "it works on my machine" often signals a race condition; adding sleeps hides, not fixes, the bug.
- Integration order: bottom-up needs drivers, top-down needs stubs. Questions swap the helper artifacts.
- Premature optimization: optimizing before profiling is a known trap; measure first.
Rule of thumb
Write code so the next reader needs no explanation: intention-revealing names, small functions, one responsibility, and explicit error paths. Handle every resource with deterministic cleanup (try-with-resources, RAII, context managers).
Worked example
A method opens a file, parses, and writes results. If parsing throws, the handle leaks. Fix: wrap the handle in a scoped resource construct so cleanup runs on every exit path, and let the exception propagate with context rather than being swallowed.