Software Construction and Implementation
Construction turns design into working code. The exam tests judgment about code quality, not syntax trivia. Core concepts: coding standards and consistent naming; defensive programming (validate inputs, fail fast, avoid silent failure); error handling versus exceptions versus return codes and when each fits; resource management (release files, connections, locks deterministically); and concurrency hazards - race conditions, deadlock, and the discipline of immutability and minimal shared state.
Understand refactoring as behavior-preserving restructuring, always backed by tests, distinct from rewriting. Know code smells - duplicated code, long methods, god classes, primitive obsession - as signals, not verdicts. Appreciate unit vs. integration construction concerns: dependency injection and seams make code testable; global state and hidden dependencies make it hostile. Be fluent in version control hygiene: small commits, meaningful messages, branches for isolation.
Traps abound. One is treating "it compiles" or "it runs" as correctness. Another is confusing refactoring with adding features - a refactor that changes observable behavior is not a refactor. Questions may present a subtle defect (e.g., a resource leaked on an exception path, or a check-then-act race) and ask for the best fix; the strongest answer addresses the root cause, not a symptom patch. Also watch for premature optimization: correctness and clarity first, measure before tuning.
Rule of thumb: code is read far more than written - optimize for the next reader, and let tests, not hope, prove behavior.
Worked example: Two threads check if (!map.containsKey(k)) map.put(k, v); - a classic check-then-act race. The fix is an atomic operation (putIfAbsent or a lock), not a retry loop around the same non-atomic sequence.