Blockchain Interview Q&A Mastery

Category Introduction: Blockchain Fundamentals (1-100)

This section covers questions about the core mechanics you have to reason about in every interview: how data is represented on-chain, how consensus works, how validators and nodes actually fit together, what forks and finality mean in practice, and how transactions move through the mempool and get priced via gas. These show up constantly when people are explaining designs, debugging incidents, or arguing about “why the chain did that.”

If you can answer these cleanly - and connect the dots between consensus, cryptography, and execution - you’re already ahead of most candidates who only memorize definitions.

---

Core Blockchain Concepts for 4+ Years: Blockchain Data Model

Q1: What does a blockchain “store” in practical terms?

A: A blockchain stores an append-only sequence of blocks, where each block contains a set of transactions plus metadata that links it to the previous block. The key practical point is that the chain is not a database you query casually; it’s a verifiable history where every new block must be consistent with the chain state rules. If you’re building or auditing anything on top, you care about how transaction data becomes state transitions and how that transition is validated by consensus.

In interview terms, you should describe the data model as: block → transactions → state transition → resulting state root (or equivalent commitment). Even when the “state” lives elsewhere (like Ethereum’s state trie), the chain still commits to it using cryptographic commitments so nodes can verify correctness without trusting any single party.

Ask yourself: “If I replay the chain from genesis, can I deterministically reach the same state?” That’s the bar.

Related: See also Q7 about Merkle Trees and Q8 about Digital Signatures for the verification pieces.

---

Q2: What’s the difference between a block and a transaction in the data model?

A: A transaction is a signed instruction (or set of instructions) that proposes a state change under some protocol rules. A block is the container that bundles many transactions together and provides ordering and a reference to the previous block so the history is tamper-evident. Ordering matters because state transitions depend on prior transitions.

Practically, you’ll see blocks include: references to parent block(s), a list of transactions, and usually commitments (like state roots) that let other nodes validate efficiently. Transactions alone don’t prove they were executed - blocks and consensus rules are what make them part of canonical history.

If you’re debugging: “Did the transaction get included?” is a different question than “Did it execute correctly?” Inclusion is block membership; execution is deterministic validation by the protocol.

Related: See also Q12 about forks and Q23 about finality.

---

Q3: Why do blockchains use hashing in the data model?

A: Hashing is how a blockchain creates compact, tamper-evident commitments. When you hash the contents of transactions (and often the block header), you get a fixed-size digest that changes drastically if any input changes. That makes it cheap to detect inconsistency and efficient for nodes to verify data without re-downloading everything.

Hashing also enables Merkle Trees, where you commit to a large set of items with a single root hash while still allowing proofs for individual items. That’s how you verify “this transaction is in that block” without trusting the peer who sent the block.

In interviews, the clean answer is: hashing gives immutability-by-detection, and it makes verification scalable.

Related: See also Q7 about Merkle Trees and Q4 about block linkage.

---

Q4: How do blocks link together - what actually prevents rewriting history?

A: Blocks link via cryptographic commitments in their headers. Typically, each block header includes a hash of the previous block header (directly or indirectly). If you change an old block, the hash changes, which breaks the link to the next block, and so on. To rewrite history, you must produce a new valid chain from that point onward under the consensus rules.

So “immutability” isn’t magic; it’s the combination of (1) cryptographic linkage and (2) consensus cost/requirements. If consensus makes it expensive or impossible to produce an alternative chain that nodes accept, rewriting becomes practically infeasible.

Interview-ready framing: nodes don’t just check “hash matches”; they check “the chain is valid under consensus,” which includes difficulty/stake rules and valid state transitions.

Related: See also Q12 about forks and Q23 about finality.

---

Q5: What does “state” mean in a blockchain?

A: State is the current set of account balances, contract storage, and other protocol-relevant variables after executing transactions according to the consensus rules....