ArtOfBlockChain
ArtOfBlockChain

  • I Know Solidity, but Interviews Now Feel Like Security Exams — What Advanced Questions Should I Really Prepare For?

    Amanda Smith

    Amanda Smith

    @AmandaS
    Updated: Nov 26, 2025
    Views: 1.6K

    I’ve been writing Solidity for a few years now — mostly production contracts, not tutorials — but the interviews I’m getting lately feel completely different. They used to be about language basics, visibility, memory vs storage, inheritance order… the usual checklist.

    Now it feels like I’m being tested on whether I can think like someone who’s about to ship something that might get attacked tomorrow morning.

    I don’t mind tough interviews. What I’m trying to understand is what questions actually reveal “real” Solidity experience versus shallow knowledge. The kind of questions where the interviewer knows in 30 seconds whether you’ve debugged something painful in production.

    If you’ve done senior-level Solidity interviews — on either side — I’d love to hear examples of the deeper questions that forced you to think, not recite. Things around:

    • state assumptions breaking mid-transaction

    • error-handling choices (require, revert, assert)

    • tricky msg.sender / tx.origin chains

    • CEI not being enough

    • storage layout pitfalls during upgrades

    • gas trade-offs in real systems

    • oracle drift, timing issues, inconsistent state

    If possible, please share what the interviewer was actually trying to test underneath the surface.

    I want to prepare properly, not memorize another glossary.

    13
    Replies
Howdy guest!
Dear guest, you must be logged-in to participate on ArtOfBlockChain. We would love to have you as a member of our community. Consider creating an account or login.
Replies

  • SmartChainSmith

    @SmartChainSmith • 1yr

    As an auditor, I don’t test if someone knows Solidity. I test if they can hold a mental model of a system where everything is happening at once and nothing behaves nicely.

    Here’s the question that separates the good from the great:

    “Which assumption have you changed your mind about recently?”

    People who’ve actually audited or debugged real protocols always have an answer.
    Rookie developers don’t.

    Other questions I use:

    1. “What’s the last false sense of safety you had in a contract?”
    Many talk about CEI. Few mention that CEI doesn’t protect you if your invariants rely on external liquidity or oracle timing.

    2. “Give me an example of a bug that wasn’t an exploit but was still dangerous.”
    Like griefing vectors, stale oracles, or unexpected callbacks.

    3. “Where do people misuse require() in a way that hides deeper issues?”
    I want to hear about upstream state, not syntax.

    Auditing isn’t really code reading.
    It’s assumption breaking.
    So I check whether your assumptions are stable.

  • Merrythetechie

    @Merrythetechie • 1yr

    I’ve been interviewing Solidity devs for years, and the biggest shift happened after teams got burnt in 2021–2023. We realised solid coding skills don’t matter much if your mental model of the EVM collapses under pressure.

    I stopped asking “definition questions” long ago. Now my filters look more like this:

    1. msg.sender vs tx.origin
    I don’t ask “explain the difference”.
    I ask:
    “Describe one subtle bug caused by tx.origin that isn’t an obvious exploit.”
    Only people who’ve touched older contracts or meta-tx flows have good answers.

    2. CEI pattern
    I ask:
    “Where does CEI fail even if you apply it correctly?”
    People who’ve dealt with AMMs or multi-leg operations instantly mention shifting external state.

    3. Storage layout in proxy upgrades
    The real filter.
    Anyone who’s lived through a storage-slot corruption incident explains it with a different tone.

    4. Gas optimisation
    I don’t want a lecture on memory vs storage.
    I want to hear:
    “I avoided optimising here because readability mattered more than 5k gas.”

    The best engineers don’t say perfect lines.
    They say things shaped by scars.

  • AnitaSmartContractSensei

    @SmartContractSensei • 4mos

    I’m roughly at your experience level, and I learned the hard way that Solidity interviews aren’t about remembering anything — they’re about explaining how you think when your mental model breaks.

    A few questions that surprised me:

    1. “What happens if your oracle freezes during a critical function?”
    I had never designed graceful degradation paths until then.

    2. “Explain a situation where require() is technically correct but misleading.”
    For me it was a liquidity check that passed, but the underlying AMM state shifted by the time the calculation was used.

    3. “Can CEI fail without reentrancy?”
    Yes. When the external state your logic relies on changes faster than your assumptions.

    The first time I got these, I froze.
    Not because they were hard — but because I’d never thought beyond the happy path.

    Once I started breaking my own assumptions intentionally, interviews got easier.

  • Shubhada Pande

    @ShubhadaJP • 4mos

    What you’re describing is exactly what many Solidity devs are feeling — interviews have shifted from “show me syntax” to “show me your thinking under risk.” Across discussions on AOB, the devs who stand out aren’t the ones reciting patterns; they’re the ones who can unpack assumptions and explain why something broke.

    If you want to explore how other candidates are preparing, the Smart Contract Interview Prep Hub is a good starting point 

    (https://artofblockchain.club/discussion/smart-contract-interview-prep-hub). You’ll find the deeper interview patterns hiring managers use.

    To sharpen fundamentals behind these questions, the Smart Contract Fundamentals Hub helps connect language concepts to real protocol behaviour (https://artofblockchain.club/discussion/smart-contract-fundamentals-hub). 

    And if you want to see what teams actually look for during audits, the Security Audits Hub captures the recurring weaknesses across projects

     (https://artofblockchain.club/discussion/smart-contract-security-audits-hub).

    Since a lot of these interviews now include “explain this vulnerability clearly,” this reentrancy thread is also worth reading:
    https://artofblockchain.club/discussion/how-do-you-explain-reentrancy-in-interviews-without-sounding-like-you-memorized

    If your interview answers start sounding closer to the thinking in these threads, you’ll walk into conversations far more confident.

  • ChainPenLilly

    @ChainPenLilly • 2w

    I’ll be direct. When I’m hiring a Solidity dev, I’m not checking if you “know the language.” I assume you do. I’m checking if you’re safe to trust with mainnet.

    Here are my filters:

    1. “Tell me something you were completely wrong about in smart contracts.” Strong candidates always have a story. Weak ones hide behind theory.

    2. “Show me a bug you shipped that made it to staging or prod.” If someone tells me they’ve “never shipped a bug,” that’s an instant no.

    3. “Why would you intentionally NOT optimise gas somewhere?” The answer reveals whether you understand readability, auditing and future risk.

    4. “What’s a risk you knowingly accepted?” Senior engineers talk in trade-offs, not absolutes.

    Hiring in Web3 is me repeatedly asking: “Will this person accidentally blow up the protocol someday?”

  • Abdil Hamid

    @ForensicBlockSmith • 2w

    Smart contract security isn’t just finding exploits. It’s predicting when the world stops behaving the way you expect.

    The question I use most often:

    “What happens when your invariants only hold on a per-block basis, not intra-block?”

    I’m checking whether you understand:

    miner ordering asynchronous oracle updates liquidity moving mid-transaction multi-chain bridge delays reorg behaviour

    These aren’t “advanced topics.” They’re real issues protocols face daily.

    If your mental model stops at the function level, not the system level, it shows instantly.

Home Channels Search Login Register