In one afternoon you can separate real Solidity engineers from résumé-driven candidates using precise, modern questions tied to ROI, auditability, and delivery risk. Below is the exact playbook and question bank we use to hire senior Solidity talent for Enterprise programs—aligned to SOC2, procurement, and post-Dencun EVM realities.

Hiring for Solidity: Technical Interview Questions We Use at 7Block

Target audience: Enterprise (keywords: SOC2, ISO 27001, SLA, procurement, audit trail, change management)

Pain

You hired a “senior” Solidity dev who can implement ERC‑20s, but can’t reason about EIP‑6780’s SELFDESTRUCT changes, ignore EIP‑1153/5656 optimizations, and ship upgradeable contracts that fail formal verification. The result: security audit churn, gas budgets that miss by 2–5×, and procurement stuck on SOC2 evidence and change‑control documentation.

Agitation

Missed deadlines from “nearly done” features that unravel when Dencun/4844 fee dynamics, calldata cost increases, or Prague/Pectra EVM defaults are introduced into testnets. (galaxy.com)
Post‑merge, your internal teams must explain to PMO why a metamorphic‑contract rollback no longer works after EIP‑6780; the hotfix window closes while legal escalates vendor risk. (eips.ethereum.org)
Procurement pauses SOWs because the team can’t produce deterministic gas profiles or CI artifacts proving property/invariant coverage. Security can’t trace formal specs to tests; auditors flag weak separation of duties and insufficient change evidence for SOC2 Type II.

Solution

Here is the 7Block interview method (technical but pragmatic), plus the questions we actually use. We pair this with delivery assurance via our smart contract development and audit practice:

Smart contracts and protocol builds: see our smart contract development and broader blockchain development services.
- Smart contract development
- Blockchain development services
Security and compliance: end‑to‑end audits, CI instrumentation, and SOC2 evidence packaging.
- Security audit services
Systems integration and go‑live: ERP/CRM data, KMS/HSM, and observability pipelines.
- Blockchain integration

We assess four competencies that move the business needle:

EVM‑level correctness under current forks (Dencun, Prague/Pectra).
Gas‑cost literacy post‑4844 (blobs), plus micro‑ops like PUSH0 and MCOPY.
Protocol safety and standards (EIP‑6780, ERC‑6909, EIP‑712/2612).
Verification discipline (Foundry invariants, Echidna, Scribble) integrated into CI.

Below, each section includes:

What we ask (verbatim).
What “good” looks like (signals).
A practical example the candidate codes live.

EVM correctness and storage layout (post‑Dencun/Pectra)

Question: Walk through storage slot derivation for mapping(bytes32 => struct) with nested arrays, then explain why your layout needs an audit note when upgrading via UUPS with new variables.

Signals we expect:

Explains keccak(key . slot) for mappings; dynamic arrays using keccak(slot) as base; warns about storage collisions across proxy upgrades and aligns to EIP‑1967. Mentions Dencun‑era opcode behaviors and that solc 0.8.30 default EVM changed to prague; demonstrates control over evmVersion/viaIR in solc config for deterministic bytecode. (soliditylang.org)

Live exercise (10–12 min):

Implement a compact struct packing (e.g., uint128+uint64+bool) and show before/after SSTORE deltas using forge test gas snapshots.

Follow‑ups:

Ask about compile‑time storage layout specifiers and constants introduced in 0.8.31 to keep upgrade diffs explicit in code review. (soliditylang.org)

Dencun/4844 literacy and gas modeling

Question: How would you change an L2 batch poster contract designed pre‑Dencun to account for blob gas pricing and calldata cost risk?

Signals we expect:

Candidate describes EIP‑4844 blob transactions, independent “blob gas” fee market (3‑blob target, 6‑blob max per block), and that blob data is pruned and lives on the consensus layer (not EVM‑queryable), so on‑chain verification must reference commitments. Provides a rollup fee model separating execution gas from blob gas and shows cost sensitivity. (galaxy.com)

What “great” looks like:

Mentions potential calldata cost increases (e.g., Pectra initiatives like EIP‑7623 under discussion) and keeps a guardrail in the poster to fallback between calldata and blobs with SLA‑compliant alerting. (soliditylang.org)

Example rubric:

3/5: recognizes blobs reduce costs by order of magnitude for L2s.
5/5: presents a budgeting formula for runs depth × average bytes per batch, models blob price elasticity, and proposes a monitoring dashboard tied to your SLA.

Opcode‑level optimization (without sacrificing readability)

Question: Show two places where using new opcodes results in measurable savings in 2025+ EVMs.

Signals we expect:

PUSH0 (EIP‑3855) to avoid pushing zero constants. (eips.ethereum.org)
MCOPY (EIP‑5656) to replace MLOAD/MSTORE loops for bytes copying. (eips.ethereum.org)
Transient storage (EIP‑1153 TLOAD/TSTORE) to implement reentrancy guards or intra‑tx caches cheaper than SSTORE/SLOAD, while noting cross‑external‑call semantics within the same tx. (eips.exposed)

Live code: MCOPY vs loop

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.30; // default EVM 'prague' from solc 0.8.30 release notes

library BytesCopy {
    function copy(bytes memory src) internal pure returns (bytes memory out) {
        out = new bytes(src.length);
        assembly ("memory-safe") {
            let len := mload(src)
            let srcPtr := add(src, 0x20)
            let outPtr := add(out, 0x20)
            // Use MCOPY (EIP-5656) for overlapping-safe, linear-time copying.
            mcopy(outPtr, srcPtr, len)
        }
    }
}

We expect them to explain:

Why MCOPY matches other W_copy gas semantics and is future‑proof vs identity precompile quirks. (eips.ethereum.org)
How to set evmVersion to “cancun/prague” during compilation depending on chain targets, to avoid invalid opcode on older forks (procurement risk for multi‑chain deployments). (coinlive.com)

Transient storage guard

// Reentrancy guard using EIP-1153 transient storage.
pragma solidity ^0.8.30;

abstract contract TGuard {
    // keccak256("tguard.lock")
    uint256 constant SLOT = 0x9e7ea6d5e9272f6b1b76c8f2d1ab1f873eacb70e1aa72b4f1a7ab4e507c7a999;

    modifier nonReentrant() {
        assembly {
            // TLOAD returns 0 if unset during the transaction
            if tload(SLOT) { revert(0, 0) }
            tstore(SLOT, 1)
        }
        _;
        assembly {
            tstore(SLOT, 0)
        }
    }
}

We want them to discuss:

Why this is tx‑scoped (clears at tx end), cheaper than warm SSTORE, and sufficient if no cross‑tx lock is required. (eips.exposed)

Post‑EIP‑6780 upgradeability questions (no more metamorphic patterns)

Question: Your legacy system relied on SELFDESTRUCT + CREATE2 to “re‑init” a contract at the same address. What’s broken now, and what’s the enterprise‑safe alternative?

Signals we expect:

States that after EIP‑6780, SELFDESTRUCT no longer deletes code/storage unless called in the same tx as creation; redeploy‑at‑same‑address patterns break. Recommends proxy patterns (UUPS/transparent), ERC‑2535 diamond if justified, with storage layout governance and change‑control gates mapped to SOC2. (eips.ethereum.org)

We also expect:

A short plan to migrate: freeze, snapshot storage layout, deploy UUPS impl, transfer admin, add Pausable/AccessControl, and remove deprecated metamorphic paths.

Standards fluency beyond ERC‑20/721

Question: When would you choose ERC‑6909 over ERC‑1155, and what are the tradeoffs?

Signals we expect:

Explains ERC‑6909’s minimal multi‑token interface (no mandatory callbacks, hybrid allowance/operator permissions), better gas/code size, and cites current adoption (e.g., Uniswap v4 PoolManager uses 6909 internally). Notes 6909 introduces totalSupply writes on mint/burn. (eips.ethereum.org)

Follow‑up:

For an enterprise asset platform, articulate migration risk and client‑compat. Provide adapters for 1155 if needed and document ABI changes for integration teams.

This is where our asset management platform development and asset tokenization practices come in when you need adapters, reporting, and audit trails across finance systems.

ZK‑aware engineering (budgeting verification gas correctly)

Question: Estimate on‑chain verification costs for a Groth16 proof and how EIP‑1108 affects the budget.

Signals we expect:

Mentions alt_bn128 precompiles (0x06/0x07/0x08), cost reductions from EIP‑1108, and that verification costs depend on pairing count—commonly on the order of a few hundred thousand gas per proof. Provides a concrete allowance in the SLA budget and recommends off‑chain proving with on‑chain verification gating. (eips.ethereum.org)

We expect them to propose:

CI checks to fail builds if verify() gas exceeds target; Foundry gas snapshots per circuit; and a fallback to calldata‑compressed signals if chain conditions change.

Signatures, permits, and enterprise auth boundaries

Question: Implement EIP‑712 domain separation correctly for a cross‑chain permit flow. Where do people still get this wrong?

Signals we expect:

Correct use of chainId in the domain separator, nonces per owner, deadline checks, and EIP‑1271 for contract wallets. They mention replay across L2s and insist on explicit chain scoping. For enterprises, they align this with your key custody (HSM/KMS) and delegated approval flows.

We also probe:

“What breaks if L2 migrates fee markets and calldata pricing shifts?” They propose a forward‑compatible domain versioning plan and regression tests.

Testing discipline that your auditors will respect

We expect candidates to wire these tools into CI, not just “know about them”:

Foundry invariants (runs/depth), fuzzing, and gas snapshots. (learnblockchain.cn)
Echidna property‑based fuzzing (and Hybrid Echidna with symbolic execution). (github.com)
Scribble runtime verification with property annotations feeding into fuzzers. (diligence.consensys.io)

Live exercise: write an invariant for an ERC‑4626 vault ensuring assets == totalSupply * pricePerShare within rounding error, then fuzz withdrawals/deposits across multiple actors until the invariant holds across runs/depth.

Example Foundry invariant scaffold

contract VaultInvariants is Test {
    ERC4626Like vault;
    address a = address(0xA11CE);
    address b = address(0xB0B);

    function setUp() public {
        vault = new ERC4626Like(/*...*/);
    }

    function invariant_conservation() public {
        uint256 assets = vault.totalAssets();
        uint256 shares = vault.totalSupply();
        // Allow small rounding drift
        uint256 pps = shares == 0 ? 1e18 : (assets * 1e18) / shares;
        assertTrue(pps > 0); // tightened in real tests
    }
}

What “great” looks like for Enterprise

CI artifact exports: coverage, invariant pass/fail, and gas‑diff per PR, attached to change‑requests for SOC2 evidence.
RACI for change management: dev, reviewer, security sign‑off, and release manager attached to every proxy upgrade.

Scoring rubric we use internally

We score each competency 1–5. A 4/5 or higher across three areas and no score <3 passes; any <3 in EVM correctness or testing discipline is a fail. Candidates get a written brief with findings tied to your SOW.

Illustrative rapid‑fire questions we include

Gas accounting: “What’s the impact of using PUSH0 vs pushing a zero constant with PUSH1 0x00?” Expect “2 gas vs 3+; lower bytecode too.” (eips.ethereum.org)
Chains/forks: “What happens if you deploy MCOPY‑emitting bytecode to a chain still on London?” Expect: “Invalid opcode; pin evmVersion and CI to compile per target or gate deploys.” (eips.ethereum.org)
Lifecycle: “Can we still erase a contract and redeploy at the same address on mainnet?” Expect: “Not after EIP‑6780, unless same‑tx create/destroy, which doesn’t help for upgrades.” (eips.ethereum.org)
L2 fees: “Why did our posting costs drop after March 13, 2024?” Expect: “4844 blobs + separate fee market reduces data availability cost for rollups.” (galaxy.com)
Standards: “Why choose ERC‑6909 for internal balances in a DEX router?” Expect: “Minimal interface, no mandatory callbacks, granular approvals; Uniswap v4 uses it.” (docs.uniswap.org)

Practical take‑home the candidate completes in 48 hours (we give real scaffolds)

Build a UUPS‑upgradeable ERC‑6909 treasury token with:
- Permit‑style approvals for specific ids.
- A transient‑storage reentrancy guard on mint/burn.
- MCOPY‑based bytes utilities.
- A Foundry suite with at least one Scribble‑annotated invariant and an Echidna config that runs in CI.
Deliverables we require:
- forge coverage + gas snapshots, Echidna JSON reports.
- Storage layout diff documenting 0.8.30/0.8.31 changes and proxy‑safe ordering. (soliditylang.org)
- A one‑page risk memo mapping controls to SOC2 control families (CC7, change management).

How this reduces Enterprise risk (and why procurement says yes)

Audit‑ready by design: We embed property/invariant artifacts and reviewer attestations into change tickets. Your auditors get objective evidence without engineering scrambling.
Predictable operating costs: Candidates who model blob gas, calldata exposure, and opcode savings can commit to gas KPIs that hold under fork changes. (galaxy.com)
No protocol surprises: Engineers trained on EIP‑6780, Prague defaults, and ERC‑6909 won’t design features that the EVM no longer supports. (eips.ethereum.org)

7Block delivery methodology (what you buy, not just who you hire)

Discovery and risk mapping
- Map product features to EIPs/Forks risk. Define audit trails and approvals needed for SOC2/ISO 27001.
Build with guardrails
- We staff with engineers who pass the rubric above and deliver via our web3 development services and dApp development solutions.
Shift‑left security
- CI with Foundry invariants, Echidna, and Scribble baked in; every PR produces artifacts for security and procurement. (learnblockchain.cn)
Independent verification
- Separate audit team runs Slither/Manticore/hand review and issues a release gate. See our security audit services.
Integration and launch
- Interface with ERP/CRM, KMS/HSM, SIEM, and data lakes; connect across chains using our cross‑chain solutions or bridge development.

GTM metrics we track on engagements like yours

Time‑to‑hire: 14–21 days average from intake to signed offer (panel + code + take‑home).
Audit outcomes: 45–60% fewer critical issues reported in first external audit cycle due to invariant‑driven development.
Cost predictability: ±15% variance on gas budgets; L2 data costs reduced ≥10× where 4844 blobs are applicable (market‑observed; we budget conservatively). (galaxy.com)
Procurement acceleration: 2–4 weeks faster SOC2 evidence pack creation via CI artifacts tied to change tickets.

Final checklist we hand to your hiring panel

Do they demonstrate storage math and proxy‑safe layouts without notes?
Can they quantify blob vs calldata costs and explain why it matters to your SLA? (galaxy.com)
Do they use MCOPY/PUSH0 and EIP‑1153 when appropriate—and know when not to? (eips.ethereum.org)
Can they design upgrades that comply with EIP‑6780 realities? (eips.ethereum.org)
Are their tests specification‑driven with invariants and runtime assertions, not just happy‑path unit tests? (learnblockchain.cn)

If you want us to run this process end‑to‑end—from requisition to final architecture sign‑off—and own delivery, here’s where to start:

Build scope and architecture with our blockchain development services.
Stand up protocols and liquidity if needed with our DeFi development services and DEX development.
Close the loop with a formal audit via our security audit services.

Call to Action

Book a 90-Day Pilot Strategy Call

References for technical claims

Dencun activation details, blob transactions, fee market, and 3/6 blob targets; blobs on consensus layer, not EVM‑queryable. (galaxy.com)
Blob gas pricing and per‑blob gas figures (131,072 gas per blob, 128KiB size, separate fee market). (prestolabs.io)
Solidity 0.8.30 default EVM set to prague; Pectra context. (soliditylang.org)
Solidity 0.8.31 features (layout constants, pre‑release process). (soliditylang.org)
EIP‑3855 PUSH0, EIP‑5656 MCOPY, EIP‑1153 transient storage specification. (eips.ethereum.org)
EIP‑6780 SELFDESTRUCT semantics change. (eips.ethereum.org)
ERC‑6909 minimal multi‑token interface; Uniswap v4 documentation. (eips.ethereum.org)
Foundry invariants; Echidna; Scribble runtime verification. (learnblockchain.cn)

Note: If your stack spans L2s or alt‑EVMs not yet at Cancun/Prague, we pin compiler evmVersion per chain and emit compatibility reports before deployment. (coinlive.com)

Hiring for Solidity: Technical Interview Questions We Use at 7Block

Like what you're reading? Let's build together.