The interviewer asks: "Explain the reentrancy attack. How did it affect The DAO, and what is the correct fix at the code level?" Which answer is most precise?
Option B is strongest. It explains the attack with a step-by-step operation order (check → send → update state), making the race condition precise. The DAO context (2016, $60M) anchors the severity. The code example for CEI shows the pattern in actual Solidity syntax — most candidates describe CEI without demonstrating it in code. The three fixes are presented in order of preference with specific implementation details: CEI with code, OpenZeppelin ReentrancyGuard with gas cost (~2200 gas for SSTORE — showing EVM-level awareness), and pull payments with the security rationale. The cross-function reentrancy section is the crucial advanced point: CEI alone does not protect against attacks that span two functions, requiring ReentrancyGuard on all affected functions. Reentrancy vocabulary:Checks-Effects-Interactions (CEI) — the pattern of checking conditions, updating state, then making external calls. Mutex (ReentrancyGuard) — a boolean lock preventing re-entry into protected functions. Fallback / receive function — the Solidity function called when a contract receives ETH. Cross-function reentrancy — a reentrancy attack that exploits two functions sharing state. Pull payments pattern — letting users withdraw funds themselves rather than pushing ETH to them. Options C and D are accurate but lack the code-level CEI example and the cross-function reentrancy nuance.
2 / 5
The interviewer asks: "What is a flash loan attack and how do attackers use them to manipulate price oracles?" Which answer is most complete?
Option B is strongest. The flash loan definition precisely captures the key property: atomicity — if not repaid, the entire transaction reverts, making them risk-free to offer. The oracle attack mechanism is explained step-by-step (5 steps) with the constant product formula reference (x*y=k) explaining WHY the AMM price moves dramatically from a large swap. The bZx hack is the correct reference (2020, $350K, two transactions) — a real example demonstrating real impact. The three defences are presented with the exact protection mechanism: TWAP uses a 30-minute window, and a flash loan only affects one block (12 seconds), so manipulating the TWAP requires sustained capital across many blocks (quantified economic infeasibility). Chainlink's defence is explained as architectural (off-chain aggregation), not just "use a better oracle." Flash loan vocabulary:Atomic transaction — a transaction where all operations succeed or all revert. AMM (Automated Market Maker) — a smart contract that maintains liquidity using a mathematical formula (x*y=k). Spot price — the current instantaneous price from an AMM based on current pool reserves. TWAP (Time-Weighted Average Price) — an oracle price computed as the average over a time window. bZx — a DeFi lending protocol exploited in the first major flash loan attack in 2020. Options C and D are accurate but lack the step-by-step attack mechanism and the TWAP economic infeasibility explanation.
3 / 5
The interviewer asks: "What are the most common access control vulnerabilities in smart contracts and how do you audit for them?" Which answer is most systematic?
Option B is strongest. It presents four categories with detection methods for each — the correct audit workflow framing. The missing modifiers section gives specific admin function examples (pause, mint, upgrade, setFee) and names the specific Slither detectors. The unprotected initialisation section uses the Parity Multisig Wallet hack as a real example ($280M frozen in 2017) — one of the most important Ethereum history events for a security auditor to know. The delegatecall section explains the storage slot 0 mechanism precisely (delegatecall runs in the calling contract's storage context, so malicious code can overwrite the owner variable which is typically at slot 0). The tx.origin section explains the phishing path (victim → malicious contract → victim contract) step-by-step. The audit workflow closes with the correct three-phase approach: Slither automated → manual matrix → Echidna fuzzing. Smart contract access control vocabulary:onlyOwner modifier — an access control restriction limiting calls to the contract owner. UUPS (Universal Upgradeable Proxy Standard) — a proxy pattern for upgradeable contracts using an initializer. delegatecall — a low-level call that executes code in the calling contract's storage context. tx.origin — the original transaction signer, as opposed to msg.sender (the immediate caller). Echidna — a smart contract fuzzer for property-based testing. Options C and D name the categories correctly but lack the Parity example and the delegatecall storage slot mechanism.
4 / 5
The interviewer asks: "What is formal verification for smart contracts and when is it worth the cost?" Which answer is most complete?
Option B is strongest. The opening definition distinguishes formal verification from testing precisely: ALL inputs vs. tested inputs only. The two-approach section correctly distinguishes Certora (model checking, complete for specified properties) from Echidna (fuzzing, not complete but practical), with an example CVL property showing what specifications look like. The "when worth the cost" section is the most operationally valuable part: it gives the $100M TVL threshold as a rule of thumb and explains the insurance logic (Certora engagement < $100M potential loss), which is how actual security teams make the ROI calculation. The post-audit hardening use case is a practical scenario many candidates miss. The limitations section is important: formal verification only proves specified properties — it cannot catch oracle manipulation (an economic attack that is formally valid) or business logic that is unspecified. Formal verification vocabulary:Certora Prover — a model checker for smart contracts using Certora Verification Language. CVL (Certora Verification Language) — the specification language for writing properties verified by Certora. Invariant — a property that must always hold true across all contract states. Echidna — a property-based fuzzer for Solidity smart contracts. TVL (Total Value Locked) — the total value of assets deposited in a DeFi protocol, used as a risk proxy. Options C and D are accurate but lack the example CVL property and the ROI insurance framing.
5 / 5
The interviewer asks: "How do you structure a smart contract audit report, and how do you classify finding severity?" Which answer is most complete?
Option B is strongest. The report structure section is specific: commit hash (a detail many candidates omit, but critical because the audit applies to a specific code version), four sections with their contents, and the exact fields in each finding. The PoC requirement is the most important professional standard: "an attacker could..." without code is insufficient — working PoC code in Foundry proves exploitability and justifies Critical/High severity. This is a real standard at top firms (Spearbit, Trail of Bits) that separates professional reports from amateur ones. The severity classification maps to CVSS criteria (impact severity × exploitability), which is the correct framing. The Informational level is often omitted by candidates. The firm names (Trail of Bits, OpenZeppelin, Spearbit) show industry knowledge. Audit report vocabulary:Commit hash — the exact git revision to which the audit findings apply. Proof of Concept (PoC) — working exploit code demonstrating that a finding is genuinely exploitable. CVSS (Common Vulnerability Scoring System) — a framework for classifying vulnerability severity. Scope — the exact set of contracts and files covered by the audit. Informational finding — a code quality or gas optimisation note with no direct security impact. Options C and D are accurate but lack the PoC requirement rationale and the commit hash importance.