Blockchain Mock Interview: 20 Questions in 50 Minutes

Halving cuts the Bitcoin block reward in half every 210,000 blocks, roughly every four years, which caps total supply at 21 million BTC. After the April 2024 halving the reward is 3.125 BTC per block. Difficulty adjustment happens every 2016 blocks: if blocks came faster than ten minutes on average, difficulty rises, and if slower, it falls. Together they make issuance predictable regardless of how much mining power joins or leaves.

A Layer 2 is a network that executes transactions off the main chain and inherits security from it by posting data or proofs back to Layer 1. Ethereum Layer 1 handles only around 15 to 30 transactions per second at higher fees, so L2s batch thousands of transactions into one L1 submission, cutting fees to cents or less. Rollups are the main type. Users bridge assets from L1 to the L2 and can withdraw back.

It is an ordering rule for functions. First do checks: validate inputs, permissions and balances with require. Then apply effects: update all state variables, such as reducing the user's balance. Only then do interactions: external calls, token transfers or ETH sends. Because state is already updated, a re-entering call sees the new state and cannot repeat the action. Combine it with a nonReentrant modifier for defence in depth, especially in functions calling unknown contracts.

A hash function maps any input to a fixed-size output, such as 256 bits. For blockchain it must be deterministic, fast to compute, pre-image resistant (you cannot find the input from the hash), second pre-image resistant, and collision resistant (finding two inputs with the same hash is infeasible). It should also show the avalanche effect, where a one-bit change gives a completely different hash. Blocks, addresses, Merkle trees and proof of work all depend on these properties.

The mempool is each node's waiting area for valid transactions that have been broadcast but not yet included in a block. Block producers usually pick transactions paying the highest fees or priority tips. Every node has its own mempool, so contents can differ slightly. Because pending transactions are public, bots can watch the mempool and front-run trades, which is why private transaction relays and order-flow auctions are used for sensitive transactions.

Upload the image to IPFS using a node or a pinning service, which returns a CID. Create a metadata JSON file whose image field is ipfs://<imageCID>, then upload the metadata folder to get a folder CID. Set the contract's base URI to ipfs://<folderCID>/ so tokenURI(5) resolves to the file for token 5. Pin the content with more than one provider, and use a gateway URL only for display in the front-end.

Since 0.8.0, arithmetic is checked by default: overflow or underflow reverts with a Panic, so SafeMath is no longer needed. Checks cost a little gas. Wrapping code in an unchecked block disables them, which is safe when you have proven the value cannot overflow, such as a loop counter bounded by an array length, or subtracting after a require that a is at least b. Using unchecked carelessly reintroduces the old overflow bugs.

It starts with scoping: fixed commit, documentation, threat model and test coverage. Auditors run automated tools like Slither and fuzzers, then do manual line-by-line review, checking business logic, access control, economic attacks and integrations. They write findings rated critical, high, medium, low and informational with fixes. The team fixes issues, auditors review the fixes, and a final report is published. Audits reduce risk but do not guarantee safety, so add bug bounties and monitoring.

ECDSA is the Elliptic Curve Digital Signature Algorithm. It gives strong security with short keys: a 256-bit key is roughly as strong as a 3072-bit RSA key, which keeps transactions small. Bitcoin and Ethereum use the secp256k1 curve, whose simple structure allows efficient computation. A signature has values r and s plus a recovery id v, which lets nodes recover the signer's public key from the signature, so the sender address need not be included separately.

BIP-39 encodes random entropy as a 12 or 24 word mnemonic, which is turned into a binary seed. BIP-32 defines hierarchical deterministic wallets that derive a tree of key pairs from that seed. BIP-44 standardises the derivation path, for example m/44'/60'/0'/0/0 for the first Ethereum account. So one backed-up seed phrase can restore unlimited addresses across chains. Whoever knows the phrase controls every derived account, so it must never be stored online.

Short term, add a fallback transport with multiple providers so requests fail over automatically, and use retries with backoff. Reduce load: batch calls with multicall, cache read results, use WebSockets instead of tight polling, and move history queries to an indexer. Long term, upgrade the plan, spread traffic across providers or run your own node for critical paths, and monitor error rates and latency with alerts so you learn of issues before users do.

Spot prices from a single pool can be moved within one transaction by a flash-loaned swap, letting an attacker inflate collateral value and borrow far more than it is worth, or trigger unfair liquidations. Replace it with a robust oracle such as Chainlink price feeds, or a long-window TWAP from deep pools, check staleness and deviation between sources, cap borrow amounts per block, and add circuit breakers for extreme price moves.

The UI is probably reading cached results or a lagging RPC node. After tx.wait() resolves, explicitly refetch or invalidate the relevant queries, for example with wagmi or TanStack Query invalidation. Show optimistic updates while pending. If you use an indexer, it may lag by a few blocks, so poll until it reaches the receipt's block number. Use the same RPC endpoint for writes and immediate reads, and avoid long caching for balances.

Track on-chain activity in real time: alert on admin actions, large transfers, unusual withdrawal rates, paused states, oracle deviations and failed transactions. Use monitoring services or custom bots reading events, with alerts to on-call channels. Monitor invariants, such as total assets matching total shares, and automate responses like pausing through a guardian. Also watch the front-end, RPC health and DNS for hijacking. Review alerts weekly to reduce noise and test the incident runbook.

Avoid a first-come public rush. Use an allowlist phase with Merkle proofs or signatures, per-wallet limits, and staggered time slots. Consider a Dutch auction or raffle so price, not gas, decides allocation. Use ERC-721A or efficient batch minting to cut gas. Reveal traits later with Chainlink VRF so bots cannot snipe rare items. Load-test the front-end and RPC, and keep pause functions ready in case something goes wrong.

Situation: a business head wanted 'blockchain' in a vendor portal because competitors mentioned it. Task: help him decide. Action: I compared it to a shared online spreadsheet that nobody can secretly edit, then showed cost, speed and privacy trade-offs against a normal database with audit logs. Result: we agreed to keep the portal on a database and anchor monthly hashes of invoices on a chain for proof, saving months of work while meeting the trust goal.

Situation: we planned a token reward feature for Indian users, and legal raised VDA tax and securities concerns. Task: as tech lead I had to find a compliant design. Action: I ran workshops to understand their constraints, proposed non-transferable points that convert to vouchers, and documented the data flow for compliance. Result: we launched a month later than planned but with sign-off from all teams, and avoided a costly redesign after launch.

Situation: a senior reviewer rejected my pull request for a staking feature, saying the storage layout would break future upgrades. Task: fix it and learn. Action: I thanked him, asked him to explain the risk, read about EIP-1967 and storage gaps, rewrote the contract with namespaced storage, and added a storage-layout check to CI. Result: the PR merged, and that check later caught a teammate's layout change before an upgrade.

Situation: I shipped a rewards contract where a rounding error let users claim slightly more than earned when claiming very often. Task: fix it and prevent repeats. Action: I owned the mistake in the team call, wrote a failing test reproducing it, changed the division order to round down in the protocol's favour, and added fuzz tests on claim frequency. Result: losses were tiny, and I now always fuzz any maths involving division.