Blockchain Developer interview questionsCode review — the upgrade you cannot roll back round

Purpose

Puts the candidate in the seat where a review decides something, and tells them what a real approval carries with it: passing tests and a colleague who has already agreed.

Purpose

Makes triage part of the task. A reviewer who blocks on everything has not told anyone what matters.

Purpose

Reads contract security in the shape upgrades give it: flaws that exist in neither contract alone, only in the move from one to the other and in the order two transactions run. The discriminator is whether the candidate reasons about the storage the proxy already holds and about the script's sequence, rather than about V2's source on its own.

Signals to score

• Sees that inserting `lockDuration` after `totalStaked` shifts every later variable, and says what V2 will read from each moved slot
• States the damage in stakers' terms: balances read out of the old reward-debt mapping, and reward accounting that restarts from a timestamp of zero
• Notices that the upgrade and `initializeV2` are separate transactions, and that anyone can call the unprotected initializer in between
• Says what a hostile `initializeV2` does — a duration near the `uint64` maximum locks every existing staker — and that `reinitializer(2)` then blocks a correction short of another upgrade
• Fixes the gap by passing the encoded `initializeV2` call as the data of `upgradeToAndCall`
• Flags the pause that stops `withdraw` but not `stake`, and the lockup that breaks the docs page's promise
• Explains why fourteen green tests prove nothing here: none of them upgrades a proxy that already holds state
• Gives the missing `_disableInitializers()` a low severity with a reason, rather than making it the headline
• Does not report the new parent contract as a layout shift, or drops the concern when asked where that parent keeps its state

Follow-up questions

• Take a staker with 10,000 tokens staked. After this upgrade, what does `stakedOf` return for them?
• The Safe executes the upgrade, and three blocks later it executes `initializeV2`. What can happen in those three blocks?
• `PausableUpgradeable` is a new parent. Does adding it move anything?
• A teammate says the missing `_disableInitializers()` is the critical finding. Do you agree?
• Suppose it shipped an hour ago. Can you roll back to V1?

Purpose

Moves from finding to preventing, and frames the deliverable as a check the next reviewer benefits from without being clever.

Purpose

Separates testing a contract from testing a change to a deployed contract. A candidate who has shipped upgrades reaches for a fork test that replays the deployment and compares state before and after; one who has not writes more unit tests against a fresh V2.

Signals to score

• Forks mainnet at a pinned block and tests the existing proxy address rather than a new deployment
• Runs the exact calls the script prints, as the Safe, in the same order and as separate transactions
• Chooses the stakers to compare on purpose — the largest, one with unclaimed rewards, one who has fully withdrawn — and says where the list comes from, since a mapping cannot be enumerated on chain
• Asserts that every V1 variable reads the same before and after the upgrade for those stakers, along with the contract-wide totals
• Performs a real withdraw and a real claim after the upgrade and checks the amounts received, not only that the calls succeed
• Adds a storage-layout comparison that fails CI on any moved or retyped slot, and says how: the upgrades tooling's validation against V1, or the compiler's layout output for both contracts diffed
• Asserts that an arbitrary address cannot call `initializeV2` at any point in the sequence, including between the script's transactions
• Re-runs V1's invariant tests against the upgraded fork state
• Pins the fork block and caches it, and says how an unavailable RPC provider is kept from blocking unrelated pull requests
• Says what a failure blocks: the merge, and the Safe transactions generated from the same script

Follow-up questions

• Your test deploys V2 behind a new proxy. What state is in that proxy?
• Which stakers do you check, and how did you get their addresses?
• Is the storage comparison something a person runs, or something that stops the merge?
• Your fork test calls `upgradeToAndCall` directly. Is that what will happen on the day?
• The RPC provider is down during CI. What happens to this pull request, and to one that only changes the docs?

Purpose

Tests whether the candidate reads a multisig as a threshold over people rather than as a number, and whether they design the power to change a contract as carefully as the contract itself. The deploy-bot signer is the discriminator: most candidates count three signers and stop.

Signals to score

• Counts the real threshold: with a bot key in CI, one human plus a compromised or careless pipeline can upgrade
• Takes the bot off the signer set, or limits it to proposing transactions that humans approve
• Puts a timelock on upgrades with a delay longer than stakers need to exit, and says what that delay protects
• Makes the timelock cover changes to itself and to the proxy's admin, not only upgrades
• Separates a fast guardian that can only pause from a slow owner that can upgrade, each with its own keys
• Bounds the pause: what it covers, that it expires unless renewed, and that exits stay open unless the incident runs through them
• Has signers check decoded calldata on their devices rather than approving a hash shown in a browser
• Monitors the proxy for queued and executed upgrades and admin changes, and announces queued upgrades publicly
• Considers removing the upgrade right once the contract stops changing, and says what the team gives up

Follow-up questions

• Three signers and a threshold of two. How many people have to be wrong for a malicious upgrade to go through?
• Why not keep the bot as a signer and move its key into a hardware security module?
• A critical bug is found on a Saturday and your timelock is 72 hours. How do stakers get protected?
• What does a signer actually see when they approve this transaction?
• Should this contract be upgradeable at all?

Purpose

A candidate who has shipped upgrades asks about signers, delays and the last emergency; one who has not asks which audit firm we use. Offering the topics keeps the choice meaningful.

Purpose

A concrete, current weakness is the best reason for the candidate this round is looking for to join, and an honest signal to one who is not. Confirm it is still accurate before saying it.