Solidity interview question: external call risks — how do you structure the answer (reentrancy, revert/DoS, gas griefing, try/catch)?

SmartContractGuru · 2025-01-31T10:58:02+00:00

In my last Solidity developer interview, I got asked something like: “What are the risks of making an external call in a smart contract, and how would you mitigate them?”I said the usual (reentrancy, gas issues, relying on another contract), but later I felt my answer was still a bit “checklist-y”.If you’ve handled this in interviews: how do you explain external call risks in a way that sounds like real engineering judgment — not just buzzwords?Do you explicitly talk about cases like external call reverts causing DoS, gas griefing, or the “control flow” problem (you hand execution to unknown code)? And do you mention Checks-Effects-Interactions, ReentrancyGuard, pull over push payments, or try/catch for external calls (>=0.6) as your mitigation structure?Basically: what’s your go-to answer framework that actually stands out in Solidity interviews?

Solidity interview question: external call risks — how do you structure the answer (reentrancy, revert/DoS, gas griefing, try/catch)?

SmartContractGuru
@SmartContractGuru

Updated: Jan 15, 2026

Views: 2.0K

In my last Solidity developer interview, I got asked something like: “What are the risks of making an external call in a smart contract, and how would you mitigate them?”
I said the usual (reentrancy, gas issues, relying on another contract), but later I felt my answer was still a bit “checklist-y”.
If you’ve handled this in interviews: how do you explain external call risks in a way that sounds like real engineering judgment — not just buzzwords?
Do you explicitly talk about cases like external call reverts causing DoS, gas griefing, or the “control flow” problem (you hand execution to unknown code)? And do you mention Checks-Effects-Interactions, ReentrancyGuard, pull over push payments, or try/catch for external calls (>=0.6) as your mitigation structure?
Basically: what’s your go-to answer framework that actually stands out in Solidity interviews?

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 • 11mos

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.

AnitaSmartContractSensei

@SmartContractSensei • 4mos

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.

MakerInProgress

@MakerInProgress • 2h

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.