Blockchain Quiz

A blockchain developer project becomes recruiter-readable when it shows what was built, why it matters, what tradeoffs were made, how the contract or dApp was tested, and what problem the candidate actually solved. A polished demo is useful, but proof-based Web3 hiring signals become stronger when GitHub commits, tests, deployment notes, architecture choices, and failure handling are easy to verify. For deeper proof-based Web3 hiring signals for blockchain developers, continue with AOB’s Web3 Hiring Signals hub.

Unbounded loops can make a function exceed block gas limits as state grows, permanently preventing execution. This becomes a real denial-of-service risk in airdrops, reward claims, holder iteration, governance cleanup, and array clearing logic. In smart contract developer interviews, this question tests whether a candidate can connect gas limits, production scale, and secure contract design instead of only writing code that works in a small test case. If this topic appears in interviews, use AOB’s Smart Contract Interview Prep Hub to connect gas limits, denial-of-service risk, Solidity reasoning, and production-scale smart contract design into a clearer interview answer.

A happy-path-only focus is a strong smart contract audit warning because it shows the developer tested normal user behavior but ignored attacker behavior, edge cases, abuse paths, oracle manipulation, permission mistakes, and failure modes. For blockchain security careers, this is also a hiring signal: strong candidates can explain what can go wrong, not only what should work. For deeper smart contract audit readiness signals for blockchain security hiring, connect this concept with AOB’s Smart Contract Security Audits Hub. If your hiring team is unsure how to screen for threat modeling in a Solidity, DeFi, or smart contract security role, AOB’s JD Review can help convert vague requirements into clearer proof-based screening signals.

Verified GitHub commits, deployed smart contracts, test coverage, audit notes, debugging trails, and role-aligned project explanations create stronger hiring proof than a polished CV alone. In proof-based Web3 hiring, recruiters and founders are not only checking whether a blockchain developer knows Solidity, Rust, EVM, or DeFi concepts. They are checking whether the candidate can show readable evidence of how they think, build, test, and fix real problems. If your GitHub, CV, or portfolio does not clearly show proof-based Web3 hiring signals for blockchain developer roles, use AOB’s Web3 Hiring Signals hub to understand what recruiters actually verify. If the gap is already visible in your applications, AOB’s Web3 CV Review can help you turn scattered blockchain experience into clearer hiring proof.

In upgradeable contracts, the proxy holds storage while the implementation code changes. If developers reorder variables or change types, storage slots map incorrectly—corrupting balances, roles, or critical pointers. This is a high-severity issue in audits. Interviewers expect candidates to mention append-only storage layout, storage gaps, and standards like EIP-1967 for proxy slots.

tx.origin authorization can be bypassed if a user is tricked into calling an attacker contract, which then calls the target contract—tx.origin remains the user. This is a known insecure pattern in Ethereum security. Interviewers like it because it tests whether candidates understand call chains and why msg.sender + explicit access control is the correct boundary.

immutable variables are assigned once (typically in the constructor) and then become read-only. They are stored in bytecode rather than regular storage slots, which can reduce gas compared to storage reads. This matters in Solidity interviews because immutables are common in optimized contracts (e.g., router addresses) and in secure configuration patterns.

Minimal proxy clones (EIP-1167) keep logic in an implementation and rely on proxy bytecode forwarding calls, making deployment cheap. In practice, immutables in the implementation help keep runtime reads efficient and reduce repeated storage reads for configuration-like values. Candidates are often tested on why clones save gas and how configuration is safely handled.

The Checks-Effects-Interactions (CEI) pattern reduces reentrancy by making you validate inputs and update internal state before any external call (like ETH transfer or token transfer). If a malicious contract re-enters, state has already moved forward, limiting exploitability. Many interviewers treat CEI as a must-know Solidity security habit for production contracts

Low-level CALL (and friends like DELEGATECALL) returns a success flag rather than automatically bubbling a revert. If you don’t check that boolean (or decode return data properly), your contract may continue in a “success-looking” state while the external call actually failed. This is a classic Solidity audit finding tied to unsafe external interactions.

Front-running is often downgraded incorrectly in smart contract audits because teams underestimate MEV and mempool-based exploitability. In DeFi security, transaction ordering attacks can cause repeated economic loss even without a classic code exploit.

Access control bugs often have the highest real-world exploit probability in smart contracts because attackers can directly call privileged functions when role checks fail. In blockchain security audits, broken authorization logic is a common cause of fund loss and protocol takeover.

CALLCODE is deprecated due to unsafe context handling. It remains callable for backward compatibility but should never be used in new designs.

EXTCODESIZE returns zero for EOAs and non-zero for deployed contracts. This distinction is commonly used for contract detection, though it has edge cases.

GASLEFT returns the amount of gas remaining in the current execution context. It is commonly used for gas-aware logic and debugging.

bytes32 always occupies a full 32-byte storage slot. Smaller types may be packed together, but bytes32 always stands alone.

Solidity packs struct variables tightly into storage slots based on declaration order. Reordering fields can change slot boundaries and break upgrade compatibility.

The base slot of a mapping is derived using keccak256(key . slot). This hashing ensures unique storage locations per key without collisions.

Changing variable types alters how Solidity packs them into storage slots. This can shift offsets and corrupt existing storage layouts in upgradeable contracts.

Calldata is immutable and cannot be modified by the callee. This makes it gas-efficient and safe for external function inputs