ArtOfBlockChain
ArtOfBlockChain

  • How to Explain External Call Risks in Solidity Interviews?

    SmartContractGuru

    SmartContractGuru

    @SmartContractGuru
    Updated: Sep 10, 2025
    Views: 1.8K

    In my last Solidity developer interview, I got asked: “What are the risks of using external calls in smart contracts, and how do you mitigate them?”

    I answered with the usual points—reentrancy attacks, gas inefficiency, and the fact that you’re relying on the reliability of another contract. But now I’m wondering if I missed some angles.

    For those of you who’ve faced this question, how did you approach it? Did you use a particular structure or highlight specific risks that made your answer stand out?

    I’m trying to fine-tune my response for future interviews and would really appreciate any insights or tips from your own experience.

    6
    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

  • MakerInProgress

    @MakerInProgress • 7mos

    I’ve been on both sides of this question, asking it in interviews and answering it. Beyond reentrancy and gas, interviewers often look for whether you understand state assumptions and control flow risks.

    For example, when you make an external call, you’re essentially handing control to another contract. That means:

    • Unexpected state changes: The external contract might update storage you depend on, leaving your assumptions invalid.

    • Denial of Service (DoS): If the external call consumes excessive gas or reverts, it can block your function entirely.

    • Oracle manipulation: If you depend on external data feeds, an attacker might exploit the timing of those calls.

    What I’ve seen stand out in interviews is when candidates also explain mitigation hierarchy:

    1. Checks-Effects-Interactions pattern

    2. Reentrancy guards (e.g., OpenZeppelin’s modifier)

    3. Pull over push payments

    4. Using try/catch with external calls (>=0.6.0)

    If you can lay it out this way, it shows structured thinking rather than just listing buzzwords.

  • Shubhada Pande

    @ShubhadaJP • 4mos

    For more Solidity questions, read our blog https://artofblockchain.club/article/top-30-interview-questions-for-senior-solidity-developers-in-2025

    Other discussion threads to read are 

    https://artofblockchain.club/discussion/how-to-handle-integer-overflowunderflow-in-smart-contracts

    https://artofblockchain.club/discussion/struggling-with-solidity-pitfalls-in-interviews-need-help

    https://artofblockchain.club/discussion/how-should-i-prepare-for-an-interview-as-a-solidity-or-smart

    https://artofblockchain.club/discussion/have-you-encountered-issues-with-solidity-version-compatibility-how-do-you-manage

  • AnitaSmartContractSensei

    @SmartContractSensei • 2d

    One thing I always add and it’s often missed that is the business logic impact of external calls. Even if you handle reentrancy, the external dependency might break because of an upgrade, paused contract, or simply because it doesn’t follow the same assumptions about return values.

    In interviews, I usually structure my answer like this:

    Category 1: Security risks (reentrancy, delegatecall misuse, malicious fallback)

    Category 2: Reliability risks (unreliable external contracts, gas griefing, unhandled reverts)

    Category 3: Design risks (tight coupling, upgrade/migration hazards, loss of composability if the dependency changes)

    Mitigation isn’t just technical (guards, try/catch, CEI), it’s also architectural: minimize reliance on external state in critical paths, prefer well-audited interfaces, and consider circuit breakers in case the external dependency fails.

    Interviewers notice when you show awareness that risk isn’t only at the code level, it’s also at the system design level. That’s often what separates “good” from “great” answers.

Home Channels Search Login Register