Cyclomatic & Cognitive Complexity — Interview Questions¶

Roadmap: Code Quality Metrics → Cyclomatic & Cognitive Complexity A complexity interview rarely asks "what is cyclomatic complexity." It hands you a function and asks "what's the V(G), and how many tests does that buy you?" — then watches whether you can count decision points correctly, tell cyclomatic from cognitive, and resist treating a number as a verdict. This page is the question bank, with model answers and a note on what each question is really probing.

How to Use This Page¶

Each question carries three things: Q (the prompt), what the interviewer is really testing, and A (a model answer at the depth a strong candidate gives). Don't memorize the answers — internalize the distinctions they keep returning to:

counting vs understanding (the number of paths vs the difficulty of following them)
cyclomatic vs cognitive (a testability lower bound vs a readability estimate)
diagnostic vs oracle (a signal that points at risk vs a defect verdict)
essential vs accidental complexity (irreducible domain difficulty vs the kind you can refactor away)

Nearly every question in this bank is one of those four distinctions wearing a costume. The candidates who do well are the ones who compute the number correctly, then immediately say what it does and doesn't mean.

Theme 1 — Cyclomatic Basics¶

Q1.1 — What is cyclomatic complexity, and what does the number actually mean?¶

Testing: Whether you know it's a graph property with a precise definition, not a vague "how complex it is" score.

A. Cyclomatic complexity, V(G), is a count of the linearly independent paths through a function's control-flow graph, defined by Thomas McCabe in 1976. You model the function as a graph where nodes are blocks of sequential code and edges are transfers of control (branches, loops, jumps). V(G) is the number of independent paths through that graph — equivalently, one plus the number of decision points. A straight-line function with no branches has V(G) = 1: exactly one path through it. Each if, each loop, each case, each &&/|| adds one, because each one creates a new way for control to fork. So the number isn't a feeling — it's the dimensionality of the function's branching, computed from its structure.

Q1.2 — Give me the three equivalent formulations of V(G).¶

Testing: Whether you understand it from the graph up, not just one memorized shortcut.

A. They all yield the same number for a single connected function:

Edges minus nodes: V(G) = E − N + 2P, where E is edges, N is nodes, and P is the number of connected components (for one function, P = 1, so it reduces to E − N + 2). This is the original graph-theoretic definition.
Decision points plus one: V(G) = D + 1, where D is the number of decision points (binary branch points). This is the practical counting rule — it's what every tool effectively does.
Regions of the planar graph: for a connected planar control-flow graph, V(G) equals the number of enclosed regions plus one (the outer region). Less used in practice but it's why McCabe drew the graphs.

The "+1" in formulations (1) and (2) is the same thing: the single baseline path that exists even with zero branches.

Q1.3 — Walk me through `V(G) = E − N + 2P`. Why those terms?¶

Testing: Whether the formula is mechanical to you or actually understood.

A. It comes from graph theory's cyclomatic number. For a graph, the number of independent cycles is E − N + P. McCabe adds an extra P (so E − N + 2P) by conceptually adding an edge from each exit node back to the entry, turning the program into a strongly connected graph where independent paths and independent cycles line up. For one function, P = 1, so it's E − N + 2. Concretely: take a simple if/else — entry node, the branch node, two arms, a join node. That's roughly 5 edges and 4 nodes, giving 5 − 4 + 2 = 3... but the cleaner way to sanity-check is the decision-point rule: one if = one decision = V(G) of 2. When the graph formula and the decision count disagree, you've miscounted the graph — the decision-point rule is the reliable one for hand calculation.

Q1.4 — What does V(G) bound? Why do people say it equals "the number of tests you need"?¶

Testing: The single most important practical fact — and whether you state the bound precisely.

A. V(G) is the size of a basis set of paths — the maximum number of linearly independent paths through the function. The practical consequence: V(G) is the minimum number of test cases required to achieve branch (decision) coverage, hitting every edge of the control-flow graph at least once. It's a lower bound on test effort for full branch coverage and an upper bound on the basis-path set size. Two cautions a careless candidate drops: it covers branch coverage, not path coverage (the number of complete end-to-end paths can be exponential, since loops and independent branches multiply); and it tells you how many tests to write structurally, not whether those tests assert anything meaningful. So "V(G) tests" gets you every branch executed once — necessary, nowhere near sufficient.

Theme 2 — Counting It¶

Q2.1 — Compute V(G) for this function.¶

Testing: Can you actually count, including the boolean operators most people miss?

int classify(int x, int y) {
    if (x > 0 && y > 0) {        // (1) if  + (2) &&
        return 1;
    } else if (x < 0 || y < 0) { // (3) else-if + (4) ||
        return -1;
    }
    return 0;
}

A. V(G) = 5. Start at the baseline 1, then add one per decision point. The decision points are: the first if (+1), the && inside it (+1, because short-circuit evaluation forks control — y > 0 only runs if x > 0), the else if (+1), and the || inside it (+1). That's 1 + 4 = 5. The trap is reading two ifs and answering 3. Each short-circuiting boolean operator is its own decision point because it creates its own branch in the control-flow graph — && and || are sugar for nested ifs. Most tools (SonarQube, gocyclo, radon, lizard) count them; a candidate who forgets them will be consistently low.

Q2.2 — Now this `switch`. What's V(G)?¶

Testing: Whether you count each reachable case as a decision, and handle default correctly.

String name(int day) {
    switch (day) {
        case 1: return "Mon";
        case 2: return "Tue";
        case 3: return "Wed";
        case 4: return "Thu";
        case 5: return "Fri";
        default: return "?";
    }
}

A. V(G) = 6 under the standard rule that each case is a decision point: 1 + 5 for the five non-default cases. (default is the fall-through baseline, so most tools don't add for it; the five case labels each fork control once.) Note this is the headline example of where cyclomatic overstates perceived difficulty — a flat dispatch switch like this is trivial to read, yet V(G) = 6 looks "complex." That's the gap cognitive complexity was designed to close: it treats a flat switch as cheap. So the correct answer is two-part — "V(G) = 6, but this is exactly the case where the number misleads, and I'd report cognitive complexity here instead."

Q2.3 — What about loops, ternaries, and exception handling — what counts?¶

Testing: Breadth of the counting rules, and the edges people argue about.

A. The reliable rule is: anything that forks control adds one. - Loops (for, while, do/while): +1 each, for the enter-vs-skip / continue-vs-exit branch. - Ternary ?:: +1 — it's an if in expression form. - catch clauses: +1 each, since each is a conditional control path. The try itself usually doesn't add; each catch does. - && / ||: +1 each (Q2.1). - case labels: +1 each (Q2.2). - Null-coalescing / optional-chaining (?., ??): tool-dependent; many modern analyzers count them as they short-circuit.

What does not add: sequential statements, a plain else (the alternative was already paid for by the if), and a bare try. The grey areas (does ?. count, does default count) are exactly why two tools can report slightly different numbers for the same function — so when comparing, hold the tool and its configuration fixed.

Q2.4 — A reviewer says your 40-line function "has complexity 1." Is that possible, and what would it tell you?¶

Testing: Whether you connect V(G) = 1 to "no branches" and resist conflating length with complexity.

A. Yes — entirely possible and not a contradiction. V(G) = 1 means zero decision points: 40 lines of straight-line, top-to-bottom code with no if, loop, boolean operator, or case. It's long but has exactly one path, so one test exercises all of it. This is the clean demonstration that cyclomatic complexity measures branching, not size. A 40-line linear function and a 5-line function with four nested conditionals are opposite shapes: the first is long-but-simple (low V(G)), the second short-but-tangled (high V(G)). If anything, V(G) = 1 on a long function is a hint to check cohesion (is it doing several unrelated things in sequence?), which is a different smell that V(G) is blind to.

Theme 3 — Cognitive Complexity¶

Q3.1 — How does cognitive complexity differ from cyclomatic complexity?¶

Testing: The core distinction — testability vs readability — and that they answer different questions.

A. They measure different things. Cyclomatic counts independent paths — it's about testability (how many tests for branch coverage). Cognitive complexity (G. Ann Campbell / SonarSource, 2017) estimates how hard the code is for a human to read and reason about. Three design rules capture the difference: (1) it ignores shorthand that doesn't add mental load — notably it does not penalize each case in a flat switch, treating the whole switch as one increment, because a human reads a dispatch table at a glance; (2) it increments for each break in linear flow (if, loop, catch, &&/|| sequences); and (3) crucially, it adds a nesting penalty — a branch nested three levels deep costs more than the same branch at the top level. Cyclomatic treats all decisions as equal weight; cognitive says depth hurts. So cyclomatic answers "how many tests," cognitive answers "how painful to maintain."

Q3.2 — Explain the nesting penalty with a concrete example.¶

Testing: Whether you understand the most distinctive mechanic of cognitive complexity.

A. Each level of nesting adds an increasing increment to nested structures. A top-level if costs 1. An if inside a loop inside an if costs more because each enclosing control structure adds to the increment of what's nested inside it. Concretely:

for item in items:          # +1 (nesting level now 1)
    if item.active:         # +1 base, +1 nesting = +2 (level now 2)
        for tag in item.tags:   # +1 base, +2 nesting = +3
            if tag.valid:       # +1 base, +3 nesting = +4
                process(tag)

That's a cognitive score of roughly 1 + 2 + 3 + 4 = 10 for four nested structures. Flatten it — early-continue guards, extract the inner loop into a function — and the same logic might score 3–4 because nothing is deeply nested anymore. The penalty encodes a real cognitive cost: tracking four levels of "we're inside X, which is inside Y" is what actually fatigues a reader. Cyclomatic would score this same code around 5 and be indifferent to the nesting, which is the whole point of having a second metric.

Q3.3 — Give me a case where cyclomatic is high but cognitive is low, and the reverse.¶

Testing: The flat-switch-vs-nested-ifs comparison — whether you can name when the two metrics disagree.

A. High cyclomatic, low cognitive: a flat switch with 15 cases, each a one-line return (a dispatch table). Cyclomatic ≈ 16 (each case forks the graph), so it trips a typical V(G) ≤ 10 gate — but it's trivial to read top to bottom, and cognitive complexity scores it low (the switch is one increment, no nesting). A pure threshold on V(G) would wrongly flag clean dispatch code.

Low cyclomatic, high cognitive: deeply nested conditionals with few total branches — say three ifs nested four deep with some boolean logic and a nested loop. Cyclomatic might be 5–6 (few decision points), but cognitive is high because the nesting penalty compounds and a human has to hold the whole stack of conditions in their head.

The lesson: they disagree precisely on shape. Flat-and-wide reads easy but counts many paths (cyclomatic high); narrow-and-deep counts few paths but reads hard (cognitive high). Reporting both catches code each one alone would miss — which is why mature setups track them together rather than picking one.

Q3.4 — Does cognitive complexity have the testability guarantee that cyclomatic does?¶

Testing: Whether you know cognitive is a heuristic, not a mathematical bound.

A. No — and that's the key limitation to state. Cyclomatic complexity has a provable relationship to control-flow structure: V(G) is exactly the basis-path count and the branch-coverage test minimum. Cognitive complexity has no such theorem; it's a deliberately heuristic score, a sum of hand-chosen increments (base + nesting) tuned to correlate with human-perceived difficulty. It's not derived from graph theory and doesn't bound anything you can prove. That's fine — it's meant to be a readability proxy, not a coverage tool — but it means you can't say "cognitive complexity N requires N tests." Use cyclomatic when you need the testing relationship; use cognitive when you want a better readability signal. Conflating the two — quoting a cognitive number as a test count — is a tell that someone learned the buzzword without the basis.

Theme 4 — Evidence and Limits¶

Q4.1 — Studies show V(G) correlates strongly with lines of code. So is it telling us anything new?¶

Testing: Whether you know the most damaging critique of the metric and can answer it honestly.

A. This is the central empirical critique, and it's real: across many studies, cyclomatic complexity correlates very strongly with LOC (correlations often above 0.9), which means that on a per-function basis it carries little information beyond "this function is big." A larger function tends to have more branches almost mechanically. So the honest answer is: V(G) is weakly additive over raw size for predicting defects. But two things keep it useful. First, the ratio V(G)/LOC (complexity density) does discriminate — it separates the long-but-linear function from the short-but-tangled one, which raw LOC can't. Second, V(G)'s real, non-redundant value isn't prediction at all — it's the testability bound (branch-coverage minimum), which LOC genuinely does not give you. A senior answer concedes the correlation rather than pretending it away, then points to where the metric is not redundant.

Q4.2 — Why do you call it a "diagnostic, not a defect oracle"?¶

Testing: Whether you understand the correct epistemic status of any code metric.

A. Because the relationship between complexity and bugs is correlational and noisy, not causal or deterministic. A high V(G) doesn't mean there's a defect — plenty of high-complexity functions are correct and battle-tested (a mature parser, a hardware abstraction layer), and plenty of bugs live in V(G) = 2 functions with an off-by-one. What V(G) reliably tells you is: this function has many independent paths, so it is harder to test exhaustively and more likely to hide an untested path. That's a risk signal that directs attention — "look here first, make sure these paths are covered" — not a verdict. Treating the number as an oracle ("V(G) > 10 = broken, refactor now") produces both false alarms (clean dispatch tables) and false confidence (the metric was green, so it's fine). The discipline is: use it to prioritize human review and testing, never to replace it.

Q4.3 — What is essential complexity in McCabe's original sense, and why does it matter?¶

Testing: Whether you know the lesser-known second metric McCabe defined, and what unstructuredness means.

A. McCabe defined a companion metric, essential complexity (sometimes ev(G)), to measure how unstructured a function's control flow is. You compute it by repeatedly collapsing well-structured, single-entry/single-exit control constructs (a clean if/else, a clean loop) down to a single node, then taking the cyclomatic complexity of what remains. If the function is fully structured, everything collapses and essential complexity is 1. If it's 1, the logic is cleanly decomposable into nested structured blocks. A value above 1 means there's irreducible spaghetti — control flow that can't be expressed with clean nested constructs, typically from jumping into the middle of a loop, multiple tangled exits, or goto-like patterns. This matters because it separates "complex but well-structured" (high V(G), essential 1 — refactorable, decomposable) from "genuinely tangled" (high essential complexity — the dangerous kind that resists clean extraction). It's the original formalization of the intuition that structure, not just branch count, is what makes code maintainable.

Q4.4 — Name a concrete failure mode where chasing a low complexity number makes code worse.¶

Testing: Whether you've seen the metric misused in the wild.

A. The classic one: someone splits a cohesive 30-line function with V(G) = 12 into five tiny functions each under the gate, but the logic is now scattered across five places that are only meaningful in sequence and share a tangle of parameters. Per-function complexity dropped; system complexity rose. The reader now has to chase five hops to understand one operation, and the real complexity moved into the call graph where no per-function metric sees it (this is the gaming problem — Theme 5). A second failure mode: introducing a lookup table or polymorphic dispatch purely to flatten a switch and dodge a V(G) gate, when the switch was perfectly readable — trading a clear, local construct for indirection that's harder to follow. In both, the number improved and the code got worse, which is the canonical sign the metric was being treated as the goal instead of the signal.

Theme 5 — Aggregation and Gaming¶

Q5.1 — Should complexity be measured per-function or per-file, and why does it matter?¶

Testing: Whether you know what aggregation hides and reveals.

A. Per-function is the meaningful unit — V(G) is defined on a single function's control-flow graph, and that's where the testability bound and the refactoring decision live. Per-file (or per-class) numbers are aggregates, and how you aggregate changes the story: a sum over a file rewards splitting files and conflates "one monster function" with "fifty simple ones" (same total, wildly different risk); an average dilutes a single dangerous function among many trivial ones, hiding it; a max surfaces the worst function but ignores the long tail. The right reporting is per-function for action (which functions to fix) plus distribution-aware file/module rollups (max and the count over threshold, not just a mean) for trend and triage. Quoting a single average-complexity-per-file number is a near-useless metric precisely because it smears the outliers you actually care about.

Q5.2 — Someone splits a complex function into helpers purely to get under the gate. What just happened to the complexity?¶

Testing: The headline gaming problem — that complexity is conserved, just relocated.

A. It moved into the call graph rather than disappearing. Per-function metrics see only one function's body at a time, so extracting decisions into helpers reduces every individual function's V(G) while the total branching of the operation is unchanged — you've just spread it across more nodes and added the edges that connect them. If the helpers are genuine, cohesive abstractions with clear names, this is good refactoring and the lower numbers reflect real readability gains. If they're arbitrary slices made only to satisfy the gate — passing flags around, named partTwo, meaningful only when called in order — it's gaming: the metric is green and the code is worse, because understanding now requires traversing the call graph that no per-function complexity metric measures. The tell is whether each extracted piece is independently nameable and understandable. This is the fundamental limit of function-local metrics, and it's why complexity gates must be paired with code review, not trusted alone.

Q5.3 — How would you detect or discourage that kind of gaming?¶

Testing: Whether you can move past "the metric is fooled" to "here's the control."

A. A few complementary moves. Pair the complexity gate with review — a human catches partTwo-style splits that the number can't. Track complementary metrics that don't drop when you shatter a function: fan-out / call-graph depth, the number of parameters threaded between the new helpers (high coupling is the fingerprint of fake extraction), and cognitive complexity at the module level. Watch the trend, not just the snapshot — a sudden bloom of tiny single-caller helpers around the time a gate was introduced is a smell. And gate on the right thing: gating on new and changed code's complexity (Theme 7) reduces the incentive to game, because the goal becomes "don't add tangle," not "drive an arbitrary number to zero." Ultimately you accept that any single metric can be gamed and design the policy so the easiest way to pass the gate is to actually write simpler code.

Theme 6 — Scenario and Judgment¶

Q6.1 — A function has V(G) = 45. What do you do, and what do you check first?¶

Testing: Calm triage and prioritization instead of a reflexive "refactor it."

A. First, I don't reflexively rewrite it — 45 is a strong signal to investigate, not an order to refactor. My checks, in order: 1. What is it? Read it. A 45 in a generated parser, a state machine, or a giant-but-flat dispatch over an enum can be essential and fine; a 45 in business logic with deep nesting is a different animal. Compute cognitive complexity alongside — if cognitive is also high, the nesting confirms genuine reading difficulty; if cognitive is low (flat switch), the cyclomatic number is overstating the pain. 2. Is it tested? V(G) = 45 means ~45 paths for branch coverage — check the actual coverage. A high-V(G) function with low coverage is the genuinely dangerous quadrant; that's where bugs hide. 3. Is it churning? Cross-reference change frequency (hotspot analysis). High complexity that never changes and has no bugs is low priority; high complexity that's edited every sprint is where refactoring pays back. 4. Essential vs accidental? Can the tangle be expressed as clean nested structures (low essential complexity), or is it irreducibly knotted? That decides whether a refactor will even help.

Only after that do I decide: leave it (essential, stable, tested), add characterization tests first then refactor (complex, churning, risky), or extract genuine sub-abstractions. The number started the conversation; the context decides the action.

Q6.2 — Is high complexity always bad?¶

Testing: The essential-vs-accidental distinction — the most important judgment in the topic.

A. No. The right frame is essential vs accidental complexity (Brooks). Some problems are irreducibly complex — a tax calculator, a physics solver, a protocol parser, a scheduler — and a faithful implementation will have high V(G) because the domain has that many cases. That's essential complexity: you can reorganize it, but you can't make it go away without lying about the problem. Accidental complexity is the tangle we add — needless nesting, duplicated branches, a hand-rolled state machine that should've been a table, conditionals that exist because of a bad earlier decision. That kind is what high-complexity warnings should drive you to remove. So high V(G) is "bad" only when it's accidental; when it's essential, the goal isn't to lower the number (which would just hide the difficulty) but to contain it — isolate it behind a clean interface, test it thoroughly, and keep it out of code that doesn't need to know. A candidate who says "high complexity is always bad, always refactor" fails this question; the senior move is to ask which kind.

Q6.3 — Two functions: one with V(G) = 8, one with V(G) = 8. Are they equally risky?¶

Testing: Whether you know the number is context-free and equal numbers can mean very different risk.

A. Not necessarily — the number is context-free, and equal V(G) can carry very different risk. Differentiators: test coverage (one fully covered, one untested — the untested one is far riskier); cognitive complexity (one a flat switch reading easily, one deeply nested and dense); essential complexity (one cleanly structured, one genuinely tangled); churn (one stable for years, one edited weekly); and blast radius (one a leaf utility, one called everywhere). V(G) measures one specific thing — branching — and is deliberately blind to all of those. That's not a flaw to apologize for; it's why you combine V(G) with coverage, cognitive complexity, and churn rather than ranking functions by V(G) alone. Equal numbers, different stories.

Q6.4 — Your linter flags a function at V(G) = 11 against a limit of 10. The author argues it's fine. How do you resolve it?¶

Testing: Whether you treat thresholds as conversation-starters, not laws — and avoid both rubber-stamping and bureaucratic rigidity.

A. The threshold is a tripwire, not a law — 11 vs 10 is not a meaningful difference in risk; it's a prompt to look. So I look, with the author: is the eleventh decision point essential (one more genuine case in a domain switch) or accidental (a nested guard that an early-return would flatten)? If it's essential and the function is otherwise clear and tested, the right outcome is often a documented suppression with a one-line reason — the metric did its job by making us check, and forcing a worse refactor just to hit a round number is the gate gaming us. If a quick early-return or guard-clause flattens it under the limit with no loss of clarity, do that. What I avoid is both extremes: blindly rubber-stamping every override (the gate becomes noise) and bureaucratically demanding a refactor for a +1 (engineers learn to hate and route around the gate). The number opens the conversation; engineering judgment closes it.

Theme 7 — Tooling and Policy¶

Q7.1 — You're introducing complexity gates to a large legacy codebase with thousands of violations. How?¶

Testing: Whether you know the "gate on new code" / ratchet pattern instead of a doomed big-bang cleanup.

A. Never gate the whole existing codebase at once — thousands of pre-existing violations means either an impossible cleanup sprint or a gate everyone disables on day one. The pattern is gate on new and changed code only (the "clean as you code" / ratchet approach): set a complexity threshold that applies to code in the current diff, so new functions must come in under the limit and touched functions can't get worse, while the existing backlog is tracked but not blocking. Tools support this directly — SonarQube's "new code" period, or a CI step that diffs complexity against the base branch and fails only on regressions. This makes the trend monotonically improving without a flag day, aligns the incentive with normal work (you fix complexity in the files you're already editing), and avoids the gaming pressure of an arbitrary global cleanup. Optionally add a ratchet that lowers the allowed maximum as the worst offenders get fixed, so the codebase can't backslide.

Q7.2 — Which threshold would you set, and would you gate on cyclomatic or cognitive?¶

Testing: Whether you have a defensible default and know the two metrics serve different gate purposes.

A. Common defaults: cyclomatic ≤ 10 per function as a warning (McCabe's original suggestion, with 15–20 as a harder ceiling), and cognitive ≤ 15 per function (SonarSource's default). But the value of the number matters less than (a) gating on new code and (b) treating it as a flag, not a hard fail. On which metric: I lean on cognitive complexity for the readability gate that developers see day to day, because it doesn't false-alarm on flat switches and its nesting penalty tracks actual maintenance pain — it produces fewer "the metric is being dumb" arguments. I keep cyclomatic for the testability conversation — when deciding how many tests a function needs, or auditing coverage adequacy, V(G)'s branch-coverage bound is the relevant number. Reporting both and gating primarily on cognitive (for readability) while using cyclomatic (for test planning) gets the best of each. The anti-pattern is a single hard cyclomatic gate that fires on clean dispatch code and trains people to game it.

Q7.3 — Name some tools and what they report.¶

Testing: Practical fluency — have you actually run these?

A. Across ecosystems: SonarQube / SonarLint report both cyclomatic and cognitive complexity (and pioneered the cognitive metric); lizard is a fast multi-language CLI (C/C++, Java, Python, JS, Go…) reporting cyclomatic complexity, token count, and parameter count per function; radon and mccabe (the flake8 plugin) for Python; gocyclo and gocognit for Go (cyclomatic and cognitive respectively); ESLint's complexity rule for JavaScript/TypeScript; PMD and Checkstyle for Java. They differ in the edge-case counting rules (Theme 2) — whether ?. counts, how they treat default — so the practical discipline is to fix one tool and one configuration as the source of truth for a codebase rather than comparing absolute numbers across tools. Most also expose per-function output suitable for the new-code gating and hotspot cross-referencing the policy questions describe.

Q7.4 — How does complexity fit alongside the other metrics in a quality dashboard?¶

Testing: Whether you see complexity as one input among several, not the whole picture.

A. Complexity is one leading indicator that's most powerful when combined with others rather than read alone. The highest-signal combinations: complexity × test coverage (high complexity + low coverage = the genuinely dangerous quadrant, your top refactoring target); complexity × churn / hotspots (high complexity that changes often is where refactoring pays back — stable complex code rarely needs it); and complexity feeding the maintainability index, which folds cyclomatic complexity together with volume and LOC into a single rolled-up score (with the caveat that the rollup hides which factor is bad, so you keep the components visible). So in a dashboard I'd never show complexity as a lone gauge — I'd cross it with coverage and churn to prioritize, and treat the maintainability index as a coarse trend line, not an action item. Complexity tells you where the branches are; coverage and churn tell you whether that's a problem worth fixing now.

Rapid-Fire Round¶

Short questions to check breadth. One or two sentences each.

Q: V(G) of a function with no branches? A: 1 — one path, one test for full coverage.
Q: Does && add to cyclomatic complexity? A: Yes — each short-circuiting boolean operator is a decision point.
Q: Does a plain else add to V(G)? A: No — the branch was already counted at the if.
Q: What does V(G) bound, exactly? A: The minimum tests for branch (decision) coverage, and the basis-path set size.
Q: The one-line formula? A: V(G) = E − N + 2P, or equivalently decision points + 1.
Q: Who defined cyclomatic complexity, and when? A: Thomas McCabe, 1976.
Q: The one mechanic that most distinguishes cognitive complexity? A: The nesting penalty — deeper code costs more.
Q: Does cognitive complexity penalize a flat switch per case? A: No — it treats the whole switch as one increment.
Q: Does cognitive complexity have a testability theorem like cyclomatic? A: No — it's a heuristic readability proxy, not a proven bound.
Q: What does essential complexity (ev(G)) of 1 mean? A: Fully structured control flow — it collapses to a single node.
Q: V(G)'s biggest empirical weakness? A: It correlates ~0.9 with LOC, so per-function it adds little beyond "this is big."
Q: Diagnostic or oracle? A: Diagnostic — it directs attention to risk; it doesn't verdict a defect.
Q: Where does complexity go when you split a function to dodge a gate? A: Into the call graph — it's relocated, not removed.
Q: Best practice for gating a legacy codebase? A: Gate on new and changed code, not the whole backlog.
Q: Highest-signal metric to pair complexity with? A: Test coverage — high complexity + low coverage is the danger zone.

Red Flags and Green Flags¶

What interviewers infer from how you answer, not just whether you're right.

Red flags: - Miscounting V(G) by forgetting && / || / case decision points. - Treating the number as a defect oracle — "V(G) > 10 means broken, refactor." - Saying "high complexity is always bad" with no essential-vs-accidental nuance. - Confusing cyclomatic and cognitive, or quoting a cognitive number as a test count. - Not knowing V(G) correlates strongly with LOC (or denying it when pressed). - Splitting functions to game a gate and calling that "reducing complexity." - Proposing a big-bang complexity cleanup of an entire legacy codebase.

Green flags: - Computing V(G) correctly and immediately stating what it bounds (branch-coverage minimum). - Naming the distinction (cyclomatic vs cognitive, essential vs accidental, diagnostic vs oracle) before reaching for a number. - Conceding the LOC correlation honestly, then pointing to where V(G) is not redundant (the testability bound, the V(G)/LOC ratio). - Reaching for cognitive complexity on the flat-switch case unprompted. - Cross-referencing complexity with coverage and churn to prioritize. - Knowing complexity is conserved — splitting relocates it to the call graph. - Treating thresholds as conversation-starters and gating on new code.

Summary¶

The bank reduces to four distinctions, repeated in costumes: counting vs understanding, cyclomatic vs cognitive, diagnostic vs oracle, essential vs accidental. Compute the number, then say what it means.
Cyclomatic basics: V(G) = independent paths = E − N + 2P = decision points + 1. It bounds the minimum tests for branch coverage — that's its non-redundant value. Count if, loops, case, ternaries, catch, and every &&/||.
Cognitive complexity answers a different question — readability, not testability. It ignores flat shorthand, increments on flow breaks, and adds a nesting penalty. It has no testability theorem; it's a tuned heuristic.
They disagree on shape: flat-and-wide (dispatch switch) reads easy but scores high cyclomatic; narrow-and-deep scores few paths but high cognitive. Report both.
Evidence and limits: V(G) correlates ~0.9 with LOC, so it's a diagnostic that directs attention, never a defect oracle. McCabe's essential complexity measures unstructuredness — a value above 1 means irreducible tangle.
Aggregation and gaming: measure per-function for action; aggregates hide outliers. Complexity is conserved — splitting to dodge a gate relocates it into the call graph. Pair gates with review and coupling metrics.
Judgment and policy: for V(G) = 45, check what it is, whether it's tested, whether it churns, essential vs accidental before acting. High complexity is bad only when accidental. Gate on new code, lean on cognitive for readability and cyclomatic for test planning, and cross with coverage and churn.