Process & Methodology
Agile methodologies (Scrum, Kanban), coding conventions, and code review practices.
7 questions
MiddleTheoryVery commonExplain DRY, KISS, and YAGNI principles.
Explain DRY, KISS, and YAGNI principles.
DRY: every piece of knowledge has a single authoritative representation. KISS: prefer the simplest design that works. YAGNI: avoid speculative abstractions.
Common mistakes
- ✗Applying DRY too aggressively — accidental similarity is not the same as the same concept; merging them couples unrelated concerns (WET — Write Everything Twice — is sometimes right)
- ✗Confusing KISS with 'no abstractions' — appropriate abstractions reduce complexity; KISS targets accidental complexity, not necessary complexity
- ✗Using YAGNI to justify skipping tests or error handling — YAGNI applies to features and design flexibility, not to correctness and robustness
Follow-up questions
- →When does WET (Write Everything Twice) code lead to better outcomes than aggressive DRY?
- →How do you balance DRY and YAGNI when designing a public API for a library?
JuniorTheoryCommonWhat is code quality? Name a few measurable indicators.
What is code quality? Name a few measurable indicators.
Code quality is how easily code can be understood, modified, and verified. Measurable indicators include cyclomatic complexity, test coverage, defect density, static-analyser warnings per kloc, and code-review turnaround time.
Common mistakes
- ✗Treating code quality as a single number — it is a basket of dimensions (readability, testability, performance, robustness)
- ✗Optimising one metric only — high coverage but weak test quality, or low complexity but unreadable code
- ✗Ignoring qualitative signals — pain points raised in reviews are real even when no metric flags them
Follow-up questions
- →How do you balance code-quality metrics against shipping deadlines?
- →What is the difference between code quality, technical debt, and maintainability?
MiddleTheoryCommonWhat are the principles of iterative methodologies (Scrum/Kanban)?
What are the principles of iterative methodologies (Scrum/Kanban)?
Agile delivers value incrementally and adapts. Scrum uses fixed sprints with roles and ceremonies; Kanban uses continuous flow with WIP limits.
Common mistakes
- ✗Treating Agile as 'no planning' — Agile values responding to change, not ignoring plans; long-horizon planning with adjustment points is still valuable
- ✗Daily standup becoming a status report — it should surface blockers and sync team members, not be a progress report to the manager
- ✗Treating sprint velocity as a performance metric — velocity measures capacity for planning, not productivity; comparing teams' velocities is meaningless
Follow-up questions
- →How does the Definition of Done (DoD) differ from acceptance criteria?
- →When is a Kanban system more appropriate than Scrum for a development team?
MiddleTheoryCommonWhat are side effects, idempotency, and pure functions?
What are side effects, idempotency, and pure functions?
A side effect is any observable change outside a function. A pure function is deterministic and side-effect-free; easy to test and cache. Idempotency means f(f(x))==f(x) (HTTP PUT).
Common mistakes
- ✗Treating
constmember functions as pure — aconstmethod can still callstd::rand(), do I/O, or write tomutablemembers;constonly prevents modifyingthis - ✗Assuming idempotent = pure — idempotent operations may have side effects (deleting a resource is idempotent: the second call is a no-op, but the first changed state)
- ✗Ignoring idempotency in retry logic — retrying a non-idempotent operation (e.g., charging a credit card) on network failure causes double-execution
Follow-up questions
- →How does memoisation work in C++ and when is it beneficial?
- →What are the benefits of a purely functional design for concurrent code?
SeniorTheoryCommonWhat to look for when doing a code review?
What to look for when doing a code review?
A code review checks correctness, memory and thread safety, error handling, performance, readable names, design fit, and adequate test coverage.
Common mistakes
- ✗Focusing only on style — formatting is for linters; reviewers should focus on correctness, design, and maintainability
- ✗Approving large PRs without understanding all changes — break PRs into smaller reviewable units; if you can't understand it, say so
- ✗Being overly prescriptive — suggest improvements with reasoning, not commands; 'consider X because Y' is better than 'do X'
Follow-up questions
- →How do you handle a PR where you disagree with the author's design approach?
- →What is the ideal PR size and why does it matter for review quality?
MiddleTheoryOccasionalAdvantages and disadvantages of coding conventions.
Advantages and disadvantages of coding conventions.
Conventions reduce cognitive load, make code searchable, can be auto-enforced (clang-format), and end style debates. Drawbacks: upfront agreement cost, rigidity, and legacy migration effort.
Common mistakes
- ✗Debating tabs vs spaces in code review instead of in a one-time team decision — commit to
.clang-formatonce and automate it in CI - ✗Having a convention document nobody reads — put a
.clang-formatand.clang-tidyfile in the repo root; enforcement beats documentation - ✗Applying conventions retroactively in a mix with logic changes — style changes should be separate commits to make diffs readable
Follow-up questions
- →How do you configure clang-format to enforce your team's style and run it in CI?
- →What is the Google C++ Style Guide's stance on exceptions and why is it controversial?
MiddleTheoryOccasionalAdvantages and disadvantages of the functional approach vs OOP.
Advantages and disadvantages of the functional approach vs OOP.
OOP encapsulates mutable state but suffers from shared state and brittle hierarchies. FP uses pure functions and immutable data — easy to test, but expensive copies. C++ commonly blends both.
Common mistakes
- ✗Treating FP and OOP as mutually exclusive — most production C++ code is a mix; the dichotomy is artificial
- ✗Applying FP patterns blindly (e.g., deep chains of
std::transform) when a simple loop is clearer — readability matters more than paradigm purity - ✗Ignoring performance differences — immutable data in FP means copies; in C++ this has real cost; use move semantics and views (
std::ranges::views) to avoid copies
Follow-up questions
- →How does the ranges library in C++20 bring functional pipelines to C++ without copying?
- →What is monadic error handling (
std::expected,std::optionalchaining) and how does it compare to exceptions?
