How Interviews Test Solidity
Solidity interviews rarely ask you to memorize syntax; they probe whether you understand the EVM's cost model and its security implications. Expect questions clustered around four themes: data location (storage vs memory vs calldata), function visibility and modifiers, gas optimization, and vulnerability patterns like reentrancy. A strong candidate explains not just what a keyword does but why it matters for gas or safety—for example, that storage writes are among the most expensive EVM operations, so minimizing them is central to good contract design.
Cricket analogy: A Solidity interview is like a selector watching not just whether you can bat, but whether you read the pitch and game situation—understanding the EVM cost model is knowing when to defend and when to attack.
The Questions You Will Almost Certainly Get
Data location is the classic opener: storage is persistent on-chain state (expensive), memory is a temporary, mutable region wiped after the call, and calldata is read-only input data that is the cheapest for function parameters, especially external functions. Visibility follows: public generates a getter and is callable anywhere, external is callable only from outside the contract, internal is accessible within the contract and its children, and private is limited to the declaring contract (though all data on-chain is publicly readable regardless). Interviewers also love the difference between require, revert, and assert: require validates inputs and conditions (refunding remaining gas), revert triggers a custom error, and assert checks invariants that should never be false.
Cricket analogy: Storage vs memory vs calldata is like the permanent record book (storage), the temporary over-by-over notepad (memory), and the read-only match rules handed to the umpire (calldata).
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract InterviewDemo {
uint256 public value; // storage: persists on-chain
// calldata is cheapest for external read-only array params
function sum(uint256[] calldata nums) external pure returns (uint256 total) {
for (uint256 i = 0; i < nums.length; i++) {
total += nums[i]; // 'total' lives in memory/stack
}
}
// require vs revert vs assert
function setValue(uint256 v) external {
require(v != 0, "zero not allowed"); // input validation
if (v > 1e30) revert("too large"); // custom failure path
value = v; // expensive storage write
assert(value == v); // invariant that must hold
}
}A frequent trick question: 'Are private variables actually private?' Answer: no—private only restricts access from other contracts at the Solidity level. All contract storage is publicly readable on-chain (anyone can inspect it via eth_getStorageAt), so never store secrets like passwords or keys in a contract.
Deeper EVM and Security Topics
Senior rounds go deeper: explain the difference between call, delegatecall, and staticcall (delegatecall runs another contract's code in your storage context—the basis of upgradeable proxies and a source of serious bugs if misused). Be ready to discuss the gas cost of storage (SSTORE), why events are a cheap way to log data that contracts cannot read back, how function selectors are the first four bytes of keccak256 of the signature, and how the proxy pattern enables upgradeability despite bytecode immutability. Above all, be able to walk through a reentrancy attack and its checks-effects-interactions fix, because it is the single most-asked security question.
Cricket analogy: delegatecall is like a substitute fielder playing under the home team's rules and using their kit—the DAO-style disasters happen when the borrowed player quietly rewrites the scorebook.
A common wrong answer: claiming 'internal' or 'private' hides data from users. It does not—it only restricts Solidity-level access. Another trap is confusing external and public: external functions cannot be called internally by name (you'd need this.func()), and external is slightly cheaper for large calldata arguments. Getting these distinctions right signals real EVM understanding.
- Interviews test EVM cost and security reasoning, not syntax memorization.
- Data location: storage persists (expensive), memory is temporary and mutable, calldata is cheap read-only input.
- Visibility: public (getter + anywhere), external (outside only), internal (contract + children), private (declaring contract) — but all storage is publicly readable on-chain.
- require validates inputs, revert triggers custom errors, assert guards invariants that should never fail.
- delegatecall runs external code in your storage context and underpins upgradeable proxies—and many exploits.
- Storage writes (SSTORE) are costly; events are cheap logs that contracts cannot read back.
- Reentrancy and its checks-effects-interactions fix is the single most-asked security question.
Practice what you learned
1. Which data location is cheapest for read-only array parameters in external functions?
2. Are private state variables hidden from users on-chain?
3. What is distinctive about delegatecall?
4. Which statement about require vs assert is correct?
5. What is a function selector?
Was this page helpful?
You May Also Like
Storage, Memory, and Calldata
Solidity keeps data in three places — persistent storage, temporary memory, and read-only calldata — and choosing correctly shapes both gas cost and correctness.
Reentrancy and Common Vulnerabilities
How reentrancy attacks drain contracts by re-entering functions before state updates, plus the defensive patterns and other common Solidity vulnerability classes.
Gas Optimization in Solidity
How the EVM prices computation and storage, and the practical patterns, storage packing, caching, calldata, unchecked math, that reduce transaction costs without sacrificing safety.
Solidity Best Practices
A practical checklist of security, gas, and maintainability practices for production Solidity: checks-effects-interactions, access control, safe external calls, custom errors, and reuse of audited libraries.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics