Solidity Interview Questions

Analogy categoryAnalogies

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).

solidity

// 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.