US Web3 startup interview: I blanked on EVM gas (SSTORE/SLOAD, warm vs cold, slot packing). What’s the mental model engineers use in real contracts?

I’m also curious about how gas is actually “mapped” to opcodes for storage operations in the EVM. In interviews, I’ve noticed the confusion isn’t just the numbers — it’s understanding what the cost represents.

For example, SSTORE is expensive when writing storage, but I never feel confident explaining the breakdown in a way that sounds like real engineering rather than “I memorized a chart.” And SLOAD is cheaper, but it still isn’t obvious why the difference is so large until someone ties it back to state changes and state proofs.

If anyone has a simple breakdown or a small example that connects “storage operation → what work the network/node does → why the gas exists,” that would help.

Here’s the cheat-sheet I give juniors, but the trick is how you say it in an interview.

Storage writes are expensive because they mutate persistent state.
Storage reads are cheaper because they don’t.
Warm access exists because first touch in a transaction is more costly than subsequent touches.

Where it matters: repeated user flows and mapping-heavy paths. Interviewers are checking if you understand that state design impacts long-term costs and that “micro-optimizing” can backfire if it hurts audits or upgrade safety.

My go-to interview framing:
“I optimize storage when it impacts repeated user-facing flows. I avoid micro-optimizations that reduce readability or increase upgrade risk unless measurement proves it matters.”

That signals maturity without reciting numbers.

The easiest way to survive these questions is to stop memorizing numbers and start explaining what kind of work the chain is paying for.

Why SSTORE is expensive (the “why behind the number”)
A storage write changes Ethereum’s persistent global state. That state isn’t “your app database” — it becomes part of what every full node has to maintain and prove. Updating storage means updating the state trie, and that has knock-on costs (state growth, proof/hashing work, and long-term network burden). The protocol prices it high to discourage careless state growth.

A line that works well in interviews:
“Reads look at state. Writes expand or mutate global state that everyone carries — so the protocol makes writes expensive.”

Explian warm vs cold access (EIP-2929) in plain terms. Use something like Cold is “first touch in this transaction,” warm is “you already touched it once.” Interviewers care because code structure can multiply cold touches. If you keep touching lots of unique slots (like mapping keys inside a loop), you pay that first-touch penalty repeatedly. If you reuse the same slot, you pay it once and then it’s effectively discounted.

Slot packing (when it works, when it’s a trap)
Packing helps when types are fixed-size and placed consecutively so they can share one 32-byte slot. It doesn’t help when a layout forces alignment jumps or when you mix in dynamic types that don’t pack cleanly. The “real engineer” point: packing is useful, but readability, auditability, and upgrade safety often matter more than shaving a little gas.

I think of gas as the EVM’s cost map for scarce resources, and the interview is really testing whether you can explain where the cost multiplies.

SLOAD vs SSTORE is easy if you frame it as “read vs mutate.” Reads don’t change state; writes do. That’s why SSTORE is the one you treat as “expensive and worth thinking about.”

Warm/cold example that’s interview-friendly
Warm/cold shows up when your code touches many unique storage locations in one transaction. The pattern where people get surprised is mapping-heavy logic or loops that pull data from different keys each time. If each iteration hits a new key, each one is a new cold touch. If you cache a struct once and reuse it, you pay the first touch and then you’re mostly warm.

Slot packing rule that keeps you safe
Solidity won’t magically fix your layout. Packing works best when you intentionally group fixed-size fields and keep the layout stable. The mature answer is not “always pack,” it’s: “I pack only where it’s a stable hot path and I can prove it matters. Otherwise I keep layout boring for audits and upgrades.”

That last sentence is usually what the interviewer is fishing for.

From a QA/security lens, gas-cost questions feel hard in interviews because most people study them as isolated numbers instead of looking at how they behave during state transitions.

In audits or serious testing, we don’t ask “What does SSTORE cost?” We ask: “Which paths expand state, cause repeated cold touches, or trigger unnecessary writes?” Because that’s where both cost and bugs concentrate.

A strong on-the-spot framework is to connect gas to correctness: writes are not just expensive — they are where you see wrong slot assumptions, accidental overwrites, unexpected refunds behavior, and state getting mutated inside loops. Warm/cold shows up as soon as you have nested loops or mapping lookups that touch many unique keys in a single transaction. Slot packing isn’t only “save gas”; it’s also about predictable layout, which matters for audits and upgrades.

If you explain it like that, you sound like someone who’s shipped and debugged real contracts, not someone doing trivia.

Very useful thread for anyone who blanks on gas-cost questions in smart contract interviews. What I’ve seen from US hiring managers is that candidates don’t get rejected for forgetting exact numbers — they get rejected when they can’t explain the reasoning behind storage costs, warm/cold behavior, and real-world trade-offs in production code.

If you’re doing web3 interview prep, these AOB resources can help you build that “why” muscle:

Smart Contract Fundamentals Hub — https://artofblockchain.club/discussion/smart-contract-fundamentals-hub

Gas Pitfalls Juniors Mention (what interviewers actually assess) — https://artofblockchain.club/discussion/gas-pitfalls-juniors-mention-what-interviewers-actually-assess

Smart Contract Interview Prep Hub — https://artofblockchain.club/discussion/smart-contract-interview-prep-hub

Emma’s point about SSTORE being “cost + bug surface” is underrated. In a review I did recently, the expensive part wasn’t the opcode trivia — it was accidental writes inside loops and repeatedly touching new slots.

When you’re performance-testing gas, what do you typically measure first: worst-case paths (many unique keys) or typical user flow? And do you treat “reduce writes” as the first lever before touching packing/layout?