Solidity Interviews: Explaining External Call Risks Without Sounding Textbook (Reentrancy, Reverts, Gas Griefing)

I’ve had this asked in Solidity interviews too, and the thing that usually gets you “extra points” is not listing reentrancy first — it’s showing you understand what an external call actually does: you’re handing control + gas to unknown code.

My structure is:

Security: reentrancy (obvious), but also “any callback can run before your function finishes.”

Reliability: external call can revert and block your flow (DoS), or burn gas (gas griefing), or return weird values.

Design: you’ve coupled your core path to someone else’s contract behavior + upgrade choices.

Then I close with mitigations as a hierarchy: Checks-Effects-Interactions, ReentrancyGuard, pull over push payments, and when you must call out, use try/catch (>=0.6) + fail-soft patterns (emit event, queue payout, circuit breaker). That “answer structure” is what makes it sound like engineering judgment, not a security checklist.

One angle interviewers quietly test is: “Do you understand that external call risk isn’t only ‘hacks’?”

Even if you’re safe on reentrancy, external dependencies fail in boring ways: contract paused, upgraded, proxy changed, a token with non-standard behavior, or a protocol changing return values. In production those show up as random reverts, stuck funds, or payouts that silently fail. So in external call risks I always mention “revert/DoS” + “dependency drift”.

Mitigation isn’t only nonReentrant. Sometimes the best mitigation is design: don’t do the external call in the critical path, store intent, let users claim (pull), and put a timeout / retry window. In interviews, saying “I’d rather queue the payout than revert the whole function because of one failing receiver” usually lands well.

Also watch the “gotcha” variations of this question. Some interviewers aren’t asking about call{value:} at all — they’re fishing for whether you understand which external call is dangerous and why.

If the code uses delegatecall, that’s a different beast: you execute their code in your storage context. That’s where people bring up upgradeable proxy risks, storage collisions, and why you must trust the implementation address and guard upgrades. Even with a plain external call, the subtler risk is state assumptions: you might assume balances/flags are unchanged, but the callee can re-enter or cause side-effects before your function finishes.

What I say in interviews: “I treat any external call as an untrusted boundary. I isolate it, minimize what happens after it, and I make failures non-fatal where possible.” Then I name the patterns (CEI, pull payments, try/catch, reentrancy guard) and give a tiny example like “payout loop becomes DoS if one receiver reverts.” That tiny example is what makes your answer feel real.

A pattern I keep seeing in Solidity interviews is that candidates name external call risks correctly, but they don’t describe the decision boundary: what invariant you’re protecting, what failure mode you expect (revert/false/callback), and what your fallback plan is. That’s usually the difference between “knows the terms” and “can ship safely.”

If you’re prepping for smart contract security interviews, you’ll probably like these related threads/resources:

Smart Contract Interview Prep Hub: 

Smart Contract Interview Prep: Solidity, Security, Debugging, Take-Home Tests & Hiring Signals | ArtofBlockchain

Common Smart Contract Security Mistakes (how interviewers probe depth):

How Do I Explain ‘Common Smart Contract Security Mistakes’ in Auditor Interviews Without Sounding Generic? | ArtofBlockchain

Quick sanity check on callback surfaces: 

Why are fallback functions dangerous? | ArtofBlockchain

Debugging framework (because many “external call” answers collapse under follow-ups):

A Clear Framework for Debugging Solidity Errors That Keep Reappearing in Interviews | ArtofBlockchain

One thing I like from the first reply is the framing: an external call isn’t a “line of code”, it’s handing control + gas to unknown code — that’s the mental model. On US DeFi team loops (especially for remote web3 jobs), I’ve noticed interviewers want you to say what you do when the call fails in production (queue, emit, partial progress), not just “use nonReentrant”.

For folks interviewing with US protocol teams: do you lean into failure-mode stories (like revert-in-loop DoS), or do you keep it more “framework-y” because that’s closer to what recruiters look for in crypto jobs?

What usually lands best in protocol loops is demonstrating the boundary in code rather than just quoting CEI.

Here is a clean pattern to show how to prevent an external call from poisoning the rest of your transaction:

// Checks-Effects-Interactions with isolated call boundary

function safeWithdraw(address payable recipient, uint256 amount) external {

require(balances[recipient] >= amount, "Insufficient balance");

// 1. State update BEFORE external execution

balances[recipient] -= amount;

// 2. Explicit gas ceiling prevents callee gas griefing

(bool ok, ) = Recipient{value: amount, gas: 10000}("");

require(ok, "Transfer failed");

}

In the interview, I wrap it up by explaining:

"I prioritize pull payments because an external address should never dictate whether a core state transition succeeds. By zeroing the balance first and setting an explicit gas ceiling, we neutralize reentrancy and prevent the receiver from griefing transaction execution."