Blockchain Developer interview questionsSmart Contract Coding Test round

Purpose

Sets reading as the first task, so a candidate who prepared to write a contract from a blank file spends the opening minutes on the code in front of them.

Purpose

Gives permission to read in silence and says nothing about what kind of caller to imagine, so whether the candidate thinks of a contract on the far side of a `call` is their own act.

Purpose

Separates candidates who trace what an attacker controls at each external call and each signature check from candidates who scan for familiar patterns. The ordering is scored as much as the list: the easiest finding to name is not the most expensive one.

Signals to score

• Names the write-back after the `call` in `withdraw`, and says an attacker needs only one share and a contract with a `receive` function
• Sees the cross-function path — calling `transfer` inside the callback so the stale balance is written back over shares already moved — not only re-entering `withdraw`
• Names all three things the withdrawal signature fails to bind — the receiver, a nonce, the chain and contract — and what each gap allows
• Notices that a signature already submitted stays replayable from public calldata until its 30-day deadline
• Finds the missing `onlyOwner` on `setFeeBps`, and says a value above 10,000 freezes every withdrawal rather than paying the attacker
• Explains the empty-vault case: a direct transfer raises the share price until the next deposit rounds to zero shares, and `deposit` does not refuse it
• Orders the list by money lost and by what the attacker needs, and can defend putting the reentrancy or the signature first
• Says why the nine tests could never have caught any of it: one depositor, externally owned accounts only, every signature used once
• Leaves the correct parts alone — the `msg.value` subtraction, the round-down in `deposit`, the burn before the send in `withdrawWithSig` — or withdraws the concern when asked

Follow-up questions

• Who is on the other end of that `call`, and what can it do before the next line runs?
• A user signed a withdrawal last week and the relayer submitted it. What is that signature worth today?
• Nobody makes money by calling `setFeeBps`. Why is it still on your list?
• `deposit` subtracts `msg.value` from the balance before pricing. Is that a bug?
• Suppose the vault already holds 1,200 ETH. Does the empty-vault finding still matter?

Purpose

Makes a failing test the first deliverable, so the fix is measured by something written before it, and asks for the property separately so the candidate cannot stop at the one scenario they already know.

Purpose

The load-bearing exercise. A scenario test proves what the candidate already knows; an invariant test is how a team finds the next bug, and it only works if the handler can do what an attacker can — including be a contract. Many candidates who have used fuzzing have only written handlers whose actors are all externally owned accounts.

Signals to score

• Writes an attacker contract whose `receive` calls back into the vault, and asserts on value extracted or shares created rather than on a revert message
• Makes the test fail on the unmodified contract and reads the failure back before changing `ShareVault.sol`
• Fixes `withdraw` by writing the balance, `totalShares` and `accruedFees` before any ETH leaves, rather than by adding a guard and keeping the order
• Says whether a reentrancy guard is still worth having after the reordering, on which functions, and roughly what it costs per call
• States the invariants in plain words before coding them: shares held add up to `totalShares`; the ETH balance covers `accruedFees`; redeeming every holder's shares one at a time never pays out more than `totalAssets()`
• Builds a handler that bounds inputs, draws callers from a fixed list of actors, and includes at least one contract actor that calls back into the vault
• Explains why an invariant run whose actors are all externally owned accounts passes against the original contract
• Rejects `payable(msg.sender).transfer` and its 2,300-gas stipend as the fix, and says what it breaks for recipients that are smart-contract wallets
• Checks what else the change touches — `withdrawWithSig`, `transfer`, and what a view returns if another contract reads it mid-call
• Says where the suite runs, with a number of runs and a call depth, and what a failing invariant blocks

Follow-up questions

• Your invariant run passed a thousand times against the original contract. Who were the callers?
• You added `nonReentrant` to `withdraw`. Walk the `transfer` path again — does it still work?
• Why not send with `payable(msg.sender).transfer` instead?
• Which invariant fails first against the original code, and roughly how many calls does it take?
• What does your guard cost per withdrawal, and is there a cheaper one on a chain that has transient storage?

Purpose

Tests whether the candidate knows the mechanism behind typed signatures rather than the name of the standard. The separator is whether every signed field is justified by an attack it closes, and whether they remember owners who cannot produce an ECDSA signature at all.

Signals to score

• Moves to EIP-712 typed data with a domain of name, version, chain id and verifying contract, and says what the domain closes
• Puts receiver, shares, nonce and deadline in the signed struct, and says the submitter can then choose nothing except whether to submit
• Uses a per-owner nonce that increments on use, and says why it beats a map of used digests: the owner can cancel
• Gives the owner a way to invalidate outstanding signatures before their deadlines
• Verifies smart-contract wallet owners through ERC-1271, and says a check built only on signature recovery shuts them out
• Keeps a library's recovery, which rejects malleable signatures, rather than raw `ecrecover`, which returns the zero address on garbage
• Says that copying a correctly bound withdrawal out of the mempool gains nothing, because only the submitter's gas changes
• Says a fixed contract does not invalidate signatures still valid on the old one, and ties the danger's length to the deadline
• Shortens the deadline and says what the relayer's users lose by it

Follow-up questions

• Once the receiver is signed, what can someone who copies the transaction still do?
• Why a nonce rather than marking each digest as used?
• An owner holds their shares in a multisig wallet. Can they use this function after your change?
• The chain id is in the domain. What should happen to a cached domain separator if the chain forks?
• The new vault is live. What are last week's signatures worth against the old one?

Purpose

Turns the findings into a live problem without saying anyone has used them, so the candidate has to decide what urgent means before acting.

Purpose

Reads order of operations, discretion and judgment under a clock nobody can see yet. Candidates who have been through this worry first about what their own fix will tell an attacker.

Signals to score

• Stops the relayer submitting signed withdrawals at once, and says why that step reveals nothing to anyone watching the chain
• Checks the chain before planning: re-entrant calls into `withdraw`, a signature used twice, any change to `feeBps`
• Keeps the finding to named people, and pushes no fix to a public repository and publishes no verified source for a replacement before users are safe
• Accepts that with no pause and no upgrade path the only protection is ETH leaving the vault, and names the ways: depositors withdraw, or the team moves funds in a planned rescue
• Treats a rescue that relies on the flaw itself as a decision for leadership and legal counsel, not an engineering call
• Plans the move to a reviewed replacement, and knows the old contract's 30-day signatures set how long it stays dangerous
• Writes the message to depositors so it says what to do and by when, without describing the flaw
• Gets an outside reviewer on the replacement despite the clock, rather than trading review for speed
• Says when the full disclosure is published: after funds are safe, with a date

Follow-up questions

• What is the first thing you do that someone watching the chain could not notice?
• Your fix is ready. Where does the code live, and when does it become public?
• Could the team move the funds out itself, and who decides whether it should?
• What does the message to depositors say, and what does it leave out?