Top 30 Senior Solidity Interview Questions & Answers (2026 Community Guide)
Senior Solidity interviews, as our members describe them, test reasoning about assumptions and trade-offs more than definitions. This guide lists 30 questions compiled from ArtofBlockchain community threads and public sources, notes what members say interviewers probe in each group, and adds short sourced reference notes on five topics.
How this guide was compiled
I moderate the ArtofBlockchain community. The questions come from member threads about Solidity interviews, hiring and debugging, and from public interview-prep material that I reworded. I did not survey hiring managers, so "members say" in this guide means what members posted in public threads, not an industry survey.
Each group below links to the threads it draws on. I paraphrase them and credit members by their forum names.
Technical statements that are not member reports link to primary sources: EIPs, the Solidity documentation, the consensus specifications and audit postmortems.
I am not an auditor and have not independently verified members' claims. Treat the probe notes as preparation hints, not rules.
This guide gives questions and pointers, not a complete answer key. Where a topic needs facts, a reference note near the end cites its sources.
A. Reentrancy, external calls and attacks
Q1. How do you prevent reentrancy across several functions and contracts, and where do Checks-Effects-Interactions (CEI) and a reentrancy guard each fall short?
Q2. When is a transient-storage reentrancy guard a good choice, and what can go wrong with transient storage? (Reference note 1)
Q3. What is read-only reentrancy, and how can it mislead a protocol that reads another protocol's view functions for prices?
Q4. How do you explain the risks of external calls (reentrancy, a reverting receiver blocking a loop, gas griefing, unchecked return values, upgraded dependencies) as engineering decisions?
Q5. How do flash loans and front-running (MEV) change how you design price oracles and auctions, and what do commit-reveal schemes and private RPCs actually protect against?
What AOB community members say interviewers probe
In our external-calls thread, members suggest opening with the fact that an external call hands control and gas to code you do not control, then walking through security, reliability and design trade-offs. My reply there adds a pattern: state the invariant, the expected failure mode (a revert, a false return or a callback) and the fallback plan.
Members also name dependency drift as a real risk: pausable or upgradeable tokens, proxy changes and non-standard return values (Anita Patel).
In our security-exam thread, members noted that CEI orders calls but does not by itself protect invariants that depend on external liquidity or oracle timing, and one suggested asking candidates which assumption they have changed their mind about recently (Smita Geaorge).
On commit-reveal, a member of our timestamp thread points out that it is mainly for bid privacy and front-running pressure and does not fix timestamp manipulation (SmartContractGuru).
More practice: our reentrancy interview thread.
B. Arithmetic, precision and time
Q6. Solidity 0.8 reverts on arithmetic overflow by default. Which risks remain? (Reference note 3)
Q7. How do you choose rounding directions in vault or AMM math, and how do you test that rounding cannot be exploited?
Q8. When is an unchecked block justified, and how do you defend it in code review?
Q9. Can proof-of-stake validators manipulate block.timestamp, and how do you design auctions and deadlines around it? (Reference note 4)
Q10. How do you design oracle freshness checks so they hold up when updates cluster during volatility?
What members say interviewers probe
In our overflow thread, members describe "0.8 reverts on overflow" as the starting line, not the finish. The follow-ups they report cover unchecked blocks, legacy code, upgradeable contracts, and decimal or reward changes (Sayali Bhandari, ChainPenLilly).
DeFiArchitect asks in the same thread whether a CV line such as "handled overflow and underflow" is a weak signal without boundary tests, and suggests tests for zero, max values, decimals, upgrades and unchecked.
In our timestamp thread, Abdil Hamid recommends using block.timestamp only for broad deadline checks, avoiding rules where the last second or two decides fairness, adding an anti-sniping extension, and testing the boundaries. AlexDeveloper summarizes the interview framing: manipulation impact is reduced, not fully prevented.
On oracles, Priya Gupta reports in our mainnet-versus-local thread that oracle updates cluster during volatility, which broke freshness checks that looked fine in calm tests.
C. Upgradeability, accounts and access control
Q11. How do storage collisions and uninitialized implementations arise in upgradeable contracts, and how do you prevent them, including across inherited contracts?
Q12. What does EIP-7702 change about how contracts should treat externally owned accounts? (Reference note 2)
Q13. How do call, staticcall and delegatecall differ in execution context, state changes and gas forwarding?
Q14. When is Ownable enough, and when do you need role-based access control or a timelock?
Q15. How do you manage compiler versions, EVM targets and dependencies across a project, and how do you follow compiler bug advisories?
What members say interviewers probe
In our security-exam thread, members asked candidates for concrete stories rather than definitions, such as a storage-layout problem in a proxy upgrade or a subtle tx.origin pitfall (Merry Thomas).
In our version-compatibility thread, members describe keeping the pragma consistent across files, locking dependency versions and auditing libraries before adding them. One member reports a deployment problem traced to a dependency built for an older compiler. A caret range such as ^0.8.0 allows any 0.8.x compiler, so many production projects pin an exact version.
Compiler advisories are fair game. In February 2026 the Solidity team published an advisory about a bug affecting delete on transient state variables when compiling with --via-ir, in versions 0.8.28 through 0.8.33 (Solidity blog). See Reference note 1.
Tooling changes quickly, so check that any tool you name in an interview is still maintained.
D. EVM internals and gas
Q16. How do TSTORE and TLOAD differ from SSTORE and SLOAD in gas and lifetime, and when would you avoid them? (Reference note 1)
Q17. How does struct packing reduce storage slot use, and when does it cost more than it saves?
Q18. How do cold and warm storage access change gas costs, and how do you profile where a function spends gas?
Q19. When should data go in events, storage, calldata or memory?
Q20. How do you decide when to optimize gas, and when is inline assembly (Yul) justified?
What members say interviewers probe
In our gas-pitfalls thread, Victor Anderson describes giving stock answers (avoid storage writes, use calldata, pack variables) and being unable to answer when a senior engineer asked how to decide when to optimize.
Replies suggest that juniors speak in absolutes while seniors talk about boundaries and measured results (ChainMentorNaina). They also suggest investigating first with a gas report such as forge test --gas-report or with traces, and tying each optimization to intent and invariants (DeFiArchitect). Re-run invariant and snapshot tests after each optimization (Andria Shines).
In our security-exam thread, Merry Thomas values candidates who will give up gas savings for readability.
E. Layer 2, standards and observability
Q21. What is sequencer centralization risk on a Layer 2, and what do L1 force-inclusion mechanisms do about it?
Q22. How do optimistic fraud proofs and ZK validity proofs differ in finality, capital efficiency and trust assumptions?
Q23. How do you secure cross-chain messages, including L1-to-L2 address aliasing?
Q24. What are the trade-offs between ERC-20, ERC-721 and ERC-1155 for a given product?
Q25. How do you design events as a stable interface, and how do you monitor reverted transactions, which emit no logs?
What members say interviewers probe
In our Layer 2 logging thread, members suggest treating events as an interface: a few stable state-transition events, with events for facts, errors for failure classes and traces for deep forensics (Smita Geaorge).
Another member suggests logging money movement, position changes, admin or config changes and upgrades (SmartContractGuru). The original post asks how to monitor reverted transactions, which emit no logs.
We do not have a member thread yet on Q21 to Q23. If you were asked these in an interview, tell us in the community discussions.
F. Testing, audits and operations
Q26. Which differences between a local fork and mainnet can break tests that passed, and how do you test for them before deployment? (Reference note 5)
Q27. What is the difference between stateless fuzzing and stateful invariant testing, and which bugs does each find?
Q28. How do static analysis, symbolic execution and formal verification differ, and what makes a protocol worth formally verifying?
Q29. What do you complete before handing a codebase to an external audit firm?
Q30. How do you design emergency pause and incident response without creating a single point of failure, and how do you behave in the first hour of a production incident?
What members say interviewers probe
In our mainnet-versus-local thread, members report concrete differences. Priya Gupta saw a 3 to 5 second broadcast-to-inclusion delay reorder dependent transactions and a function that cost 110k gas locally and 135k on mainnet. ChainMentorNaina saw a test pass on one RPC provider and fail on another. Abdil Hamid found that evm_snapshot resets hid state-accumulation bugs, including rounding drift from accumulated dust. BlockchainMentorYagiz hit an EIP-155 chain-ID mismatch that broke every signature in a relayer flow.
In our production-incidents thread, SmartContractGuru describes a three-step habit: freeze and review logs and state, say what you see, and avoid writes until the diagnosis is confirmed. Abdil Hamid describes mistaking a stalled off-chain keeper script for a broken contract, and checking Etherscan, storage slots and read-only calls first. The thread leaves open whether restarts or feature-flag toggles count as writes.
Our debugging and tooling hub lays out a six-step workflow: define the invariant, reproduce deterministically, isolate the boundary, read the trace, replay under realistic conditions, and turn the fix into proof.
On formal verification, Certora's own post on the Balancer incident says its 2022 verification of Balancer v2 stable pools proved high-level solvency properties that were not strong enough to catch the rounding bug (Certora). That is a useful answer to what formal verification does not guarantee.
For audit preparation, see our security audits hub and interview prep hub.
Reference notes
These five topics came up repeatedly in member threads. Each note states what the linked sources say and nothing more, so read the sources for detail.
Note 1. How do transient-storage reentrancy guards work, and what are the risks?
What it is. EIP-1153 adds TSTORE and TLOAD, which behave like storage but are discarded at the end of every transaction (EIP-1153).
Gas. The EIP sets TSTORE and TLOAD at 100 gas each. A guard performs one TLOAD and two TSTOREs, so about 300 gas. One developer who compared OpenZeppelin's two guards measured savings of about 2,000 gas or less per call (OpenZeppelin forum), so measure in your own gas report.
Support. Solidity 0.8.24 added the opcodes for the Cancun upgrade (Solidity release notes), and 0.8.28 added full support for transient state variables of value types (Solidity 0.8.28). OpenZeppelin v5 includes ReentrancyGuardTransient, and the target chain must support EIP-1153.
A cheaper lock, not a different defense. A transient guard blocks the same reentrant calls a storage guard blocks. Its advantage is gas, so "use transient storage" is not by itself a complete answer to reentrancy.
Hazard 1: values persist across calls. Transient values stay set across external calls within a transaction. The SIR.trading exploit was caused by a mistake in a gas optimization using transient storage: a value written in one call was read back as something else when the callback ran again in the same transaction (Verichains analysis).
Hazard 2: a compiler bug. In Solidity 0.8.28 through 0.8.33 compiled with --via-ir, delete on a transient state variable could write to persistent storage instead, so a lock was never released (Solidity advisory). Version 0.8.34 patches it.
A recent incident to study. In March 2026, depositing an ERC-3525 token into a Solv Protocol vault triggered a mint, and the ERC-721 onERC721Received callback minted again. The attacker repeated this 22 times for about 38 SolvBTC (about $2.7 million), and fewer than 10 users were affected (Halborn, Verichains). A researcher quoted by Rekt said following basic security best practices could likely have prevented it. The interview lesson is to know what inherited token standards call back into.
Note 2. What does EIP-7702 change about externally owned accounts?
What it is. EIP-7702 went live with the Pectra upgrade on May 7, 2025. It adds transaction type 0x04, which carries signed authorizations that make an externally owned account (EOA) point to deployed contract code (Chainstack, EIP-7702).
Delegation persists. It lasts across transactions until the account replaces or clears it (Foundry docs). Delegating to the zero address restores the original state (EIP-7702). While delegated, the account's code is 0xef0100 followed by the implementation address (Foundry docs).
Storage is not cleared. Changing the delegation does not clear the account's storage, so collisions between delegate contracts remain a risk (Chainstack). The EIP recommends storage layouts that avoid collisions, such as ERC-7201, and clearing storage first when in doubt.
tx.origin guards can break. The EIP's security considerations warn that delegation can break reentrancy guards of the style require(tx.origin == msg.sender).
Two common misconceptions. That a delegation lasts for one transaction, and that it removes storage-collision risk. Both contradict the sources above.
Note 3. What does Solidity 0.8 checked arithmetic cover, and what does it miss?
Covered. Since 0.8.0, arithmetic operations revert on overflow and underflow by default (Solidity 0.8.0 announcement).
Not covered. Operations inside unchecked { ... } use wrapping arithmetic. Explicit conversions from larger to smaller integer types are not checked (0.8.0 announcement). Overflow checks are never performed for shift operations, whose results are truncated to the type (Solidity docs: types).
Precision loss is not overflow. On November 3, 2025, Balancer V2 composable stable pools and forks of them lost more than $120 million (OpenZeppelin). Per OpenZeppelin, _upscale always rounded down (mulDown), independent of swap direction. That became exploitable after the pool code began applying non-unit scaling factors derived from token exchange rates. The attacker pushed pool balances very low and used batchSwap in repeated sequences. The vulnerable override was added after OpenZeppelin's second audit of earlier versions.
What reviewers recommend. Trail of Bits recommends documenting invariants and using explicit rounding strategies, and says it now rates codebases without comprehensive rounding strategies as having "weak" arithmetic maturity (Trail of Bits). Certora says Balancer v3 added explicit rounding directions for all calculations (Certora).
Note 4. Can validators manipulate block.timestamp after the Merge?
The docs still say miners. The Solidity documentation says the timestamp and block hash "can be influenced by miners to some degree," that the timestamp must be strictly larger than the previous block's, and that you should not rely on block.timestamp or blockhash as a source of randomness (Solidity docs). The proof-of-work term "miners" can confuse candidates preparing for post-Merge interviews.
After the Merge, the slot fixes the timestamp. The consensus specification asserts that an execution payload's timestamp equals the time of its slot, payload.timestamp == compute_time_at_slot(state, state.slot) (consensus specs). Ethereum divides time into twelve-second slots with one proposer per slot (ethereum.org). A proposer therefore cannot pick an arbitrary timestamp.
What can still vary. Slots can go empty when a validator is offline (ethereum.org). Because the timestamp follows the slot, the next block's timestamp is then at least 24 seconds after its parent's. This follows from the slot rule, so do not assume consecutive blocks are exactly 12 seconds apart.
Design guidance. Use the timestamp for coarse deadlines, avoid rules where the last second or two decides fairness, add an anti-sniping extension for auctions, test the boundaries, and avoid using it as a source of randomness (members' advice in our timestamp thread; the randomness warning is in the Solidity docs).
The old rule. You may see a "~15 seconds" tolerance quoted for timestamp manipulation. Post-Merge, the slot rule above sets the timestamp, so do not quote that tolerance as a current rule.
Other chains. Layer 2s and other networks set timestamps under their own rules, so check the chain's documentation.
Note 5. Why do tests pass on a fork and fail on mainnet?
A fork reproduces state, not live conditions. It copies chain state at a chosen block. Our debugging and tooling hub advises pinning a block to reproduce a failure, then replaying under realistic conditions.
Differences members report in our mainnet-versus-local thread: RPC provider behavior, transaction broadcast delay and ordering, clustered oracle updates, state accumulation that snapshot resets hide, and chain-ID configuration.
Practices members use. A nightly suite against mainnet RPC without snapshots (Priya Gupta), a weekly "dirty chain" run of 300 to 400 transactions without resets (Abdil Hamid), running the suite against more than one RPC provider (ChainMentorNaina), and running with several environment files to catch hardcoded chain IDs (BlockchainMentorYagiz).
Caveat. These are member reports, not benchmarks. Members' explanations for gas differences vary, so measure before concluding.
Showing this in your resume and portfolio
Members describe the same pattern in hiring that they describe in interviews: show reasoning, not volume.
In our portfolio-site thread, members suggest two layers per project: a short card that can be scanned in 30 seconds, linked to a fuller case study (ChainPenLilly).
Prefer verifiable metrics: severity reasoning, reproducible proof-of-concept steps, patch summaries, regression tests, gas before and after, and time to detect. If you cannot honestly claim funds protected, state what you can prove, such as a reduced attack surface or an added invariant.
Short "what went wrong" notes under each project show debugging thinking, and auditor portfolios and forensics portfolios need different evidence (amanda smith).
Our portfolio article expands on this. It reflects our community's observations and does not cite hiring data.
Service from the publisher. ArtofBlockchain offers a paid Web3 CV review and rewrite. If you want a second reader on how your resume presents work like the above, see the service announcement.
Sources
Checked October 2026.
Specifications, documentation and advisories
Solidity advisory: transient storage clearing helper collision bug
OpenZeppelin forum: ReentrancyGuard vs ReentrancyGuardTransient gas saving
Incident analyses
ArtofBlockchain community threads and hubs
