EVM Interview Questions for Solidity Developers: How to Tackle Gas Optimization, Storage Layouts, and Delegatecall Scenarios?

I completely get what you’re feeling—EVM looks intimidating until you connect Solidity with the underlying bytecode. Interviewers usually test execution flow understanding more than theory. Expect questions like: “How does EVM handle storage slots?”, “What’s the difference between CALL and DELEGATECALL?”, or “Why is SSTORE costlier than SLOAD?”

Start with small contracts and inspect them using Foundry tools (cast storage, hevm trace). Learn how stack, memory, and storage interact; this helps you see why state variable packing saves gas.

Helpful resources: EVM Illustrated (for visuals), Patrick Collins and EatTheBlocks bytecode tutorials, and Etherscan’s decoded transaction traces. Once you can clearly explain gas usage differences between read and write functions, you’re already interview-ready

I faced a full round focused only on EVM internals. They started from transaction lifecycle—nonce, calldata, and gas limits—and moved to storage access. One question: “Explain warm vs cold SLOAD.” Another: “How does slot packing improve gas efficiency?”

They also explored MEV and reentrancy, asking how to prevent sandwich attacks or untrusted external calls. Don’t memorize; understand the why.

I relied on the Ethereum Yellow Paper and evm.codes to decode opcodes, and used Foundry’s debug traces to watch gas usage line by line. Building a minimal proxy contract helped me master how delegatecall preserves storage during upgrades. Real debugging teaches more than any course.

When preparing for Solidity interviews, one area developers often overlook is how contracts are deployed inside the Ethereum Virtual Machine, specifically through the CREATE and CREATE2 opcodes.

I was once asked to explain why deterministic contract addresses matter for DeFi protocols and factory patterns. The interviewer expected me to connect it to CREATE2, where an address is derived from the deployer, salt, and bytecode hash. This is crucial in systems like Uniswap or minimal proxies that rely on predictable contract addresses for trustless deployments.

Another deep area is storage layout in upgradeable contracts. When using proxy patterns (Transparent or UUPS via OpenZeppelin), the logic contract executes through DELEGATECALL — meaning storage writes happen in the proxy’s context. Interviewers may test your understanding of slot collision, storage gap, and why you should never reorder state variables between versions. It’s one of the most common pitfalls developers face in real audits.

My preparation tip: read OpenZeppelin’s upgradeable storage docs, then experiment with Foundry or Hardhat traces to visualize how each call modifies EVM storage slots. Seeing how delegatecall reuses context while preserving immutability is the kind of insight that sets strong blockchain developers apart in interviews.

Completely agree with @Layer1Bondan—interviewers care about execution flow, not memorized theory.

To add to what @SmartContractGuru asked about gas mechanics and opcodes, the bar has shifted. Basic slot packing or calculating keccak offsets is table stakes now. For senior roles, the real weed-out questions happen at state boundaries:

• Transient storage (EIP-1153) gotchas: Everyone knows TSTORE/TLOAD drops reentrancy locks to ~100 gas, but interviewers probe lifetime semantics. What happens if a sub-call fails silently? Does your lock persist across distinct delegatecall hops? If you haven't handled raw Yul transient cleanups, it shows quickly.

• L1 vs. Rollup gas realities: Shaving an SLOAD via heavy bitwise packing can actually hurt you on an L2 if it hurts byte compressibility and inflates your calldata/DA bill. Interviewers want to see if you understand execution gas vs. DA overhead.

• Live Foundry traces over toy puzzles: Instead of textbook Ethernaut riddles, teams now hand you a failing -vvvv trace: "Why did this memory gas spike at offset 0x1000?" or "Where did this delegatecall clobber the proxy slot?"

For anyone interviewing lately, are teams still giving you classic storage puzzles, or are you seeing more live trace debugging and L2-specific execution tradeoffs?