Question 1

What do the status codes 200, 201, 202, 400, 401, 403, 404, 409, 429 and 503 mean?

Accepted Answer

200 OK, success with a body. 201 Created, a new resource was created. 202 Accepted, the request was received and will be processed later (common for webhooks and long jobs). 400 Bad Request, the input is invalid. 401 Unauthorized, missing or invalid credentials. 403 Forbidden, authenticated but not allowed. 404 Not Found. 409 Conflict, for example a duplicate or a version conflict. 429 Too Many Requests, you are rate limited. 503 Service Unavailable, a temporary server problem, often worth retrying later.

Question 2

What is idempotency, and why does it matter when calling or building APIs?

Accepted Answer

An operation is idempotent if doing it several times has the same effect as doing it once. Networks fail after a request is processed but before the response arrives, so clients retry, and non-idempotent operations such as "create payment" can then happen twice. GET, PUT and DELETE are idempotent by design; for POST, use an idempotency key: the client sends a unique key per logical operation and the server stores the result for that key, returning it again for repeats instead of acting twice.

Question 3

If TypeScript has types, why do you still need to validate data from an API?

Accepted Answer

TypeScript types are checked at compile time and erased at runtime. When you write await res.json() as User , you are asserting the shape, and nothing checks it when the code runs. If the API returns an error object, a missing field or a different type, the code fails later with a confusing error or, worse, writes bad data. Validate external data at the boundary with a schema library such as zod, and derive the static type from the schema so they stay in sync.

Question 4

You need data for 50 customers from an API. How would you fetch it in TypeScript, and what can go wrong?

Accepted Answer

Fetching one by one with await in a loop is simple but slow. Promise.all over 50 requests is fast but may hit rate limits, and one rejection rejects the whole batch. A good answer uses limited concurrency (for example batches of 5 or a small pool), Promise.allSettled or per-item error handling so one failure does not lose the others, a timeout on each request with AbortSignal.timeout , and retries with backoff for transient errors. Also mention validating each response.

Question 5

What do the `?.` and `??` operators do, and how is `??` different from `||`?

Accepted Answer

a?.b reads b only if a is not null or undefined ; otherwise the whole expression is undefined instead of throwing. a ?? b returns b only when a is null or undefined . a || b returns b for any falsy a , including 0 , an empty string and false , which is a common source of bugs: count || 10 turns a real count of 0 into 10, while count ?? 10 keeps it.

Question 6

When do you use symmetric and when asymmetric cryptography? How does TLS use both?

Accepted Answer

Symmetric encryption (AES) uses one shared key and is fast, so it protects bulk data. Asymmetric cryptography uses key pairs and is slower; it solves key distribution and provides signatures. TLS uses both: the handshake uses asymmetric cryptography to authenticate the server with its certificate and an ephemeral key exchange (ECDHE) to agree a shared secret, then the connection data is encrypted with fast symmetric ciphers such as AES-GCM. Ephemeral keys give forward secrecy.

Question 7

What does a digital signature prove, and what does it not?

Accepted Answer

A valid signature proves that the holder of the private key signed exactly this data (authenticity and integrity) and, if the key is well protected, non-repudiation. It does not provide confidentiality: the signed data remains readable. It also only proves which key signed, so trust depends on knowing that key belongs to the claimed signer, which is what certificates and PKI provide. Always verify before trusting or using the data.

Question 8

What is the difference between hashing, encryption and encoding?

Accepted Answer

Encoding (Base64, URL encoding) changes representation and is reversible by anyone; it gives no security. Encryption is reversible only with a key and protects confidentiality. Hashing is one-way: you cannot recover the input, which suits integrity checks and, with a slow salted function such as Argon2id or bcrypt, password storage. A common mistake is calling Base64 "encryption" or storing passwords encrypted instead of hashed.

Question 9

What is the test pyramid, and how would you apply it to a backend service?

Accepted Answer

Many fast unit tests at the bottom, fewer integration tests in the middle, and a small number of end-to-end tests on top. For a service: unit tests for business rules and edge cases; integration tests that call endpoints with a real database (for example in a container) to check SQL, serialisation and status codes; and a few end-to-end tests of the critical user journeys in a deployed environment. Lower levels are faster and more precise about what broke; higher levels catch wiring problems.

Question 10

What is the difference between merge and rebase, and when should you not rebase?

Accepted Answer

Merge joins two histories with a merge commit and keeps what happened. Rebase replays your commits on top of another branch, producing a linear history but new commit IDs. Do not rebase commits others have already pulled (shared branches), because their history diverges from yours and force-pushing can destroy their work. A common approach: rebase your own feature branch to update it, and merge (or squash-merge) into main through pull requests.

Question 11

Someone pushed a cloud access key to a Git repository. What do you do?

Accepted Answer

First revoke or rotate the key immediately, because anything pushed may already be copied, especially in public repositories. Then check audit logs for use of the key since it was pushed. Remove it from history (git filter-repo or BFG) and coordinate a force push if the repository must be cleaned, but treat that as secondary. Prevent a repeat: secret scanning in CI and push protection, pre-commit hooks, and moving the workload to short-lived credentials so there is no key to leak.

Question 12

Tell me about a time a stakeholder disagreed with your analysis.

Accepted Answer

Use situation, task, action, result. Show that you first understood their view (often a different definition or context), checked your own work, found the source of the difference together and agreed on the next step. End with the outcome and what you changed in how you work, for example writing definitions into every brief.

Question 13

Tell me about a production issue you handled.

Accepted Answer

Use a STAR story. Show how you detected it (alert, user report), how you limited the damage first (rollback, feature flag, scaling), how you found the root cause with evidence (logs, metrics, traces), how you communicated during the incident, and what changed afterwards (a test, an alert, a runbook, a design fix) as part of a blameless review. Interviewers look for calm prioritisation and learning, not heroics.

Question 14

Given a list of order amounts and a target, return whether any two different orders add up to the target. What is your approach and its complexity?

Accepted Answer

The brute-force approach checks every pair: O(n squared) time, O(1) extra space. Better: walk the list once, and for each amount check whether target - amount is in a hash set of amounts seen so far, then add the current amount: O(n) time on average and O(n) space. If the list is already sorted, two pointers from both ends give O(n) time with O(1) space. State the trade-off and test edge cases: empty list, one element, duplicates and negative values.

Question 15

What makes a blockchain tamper-evident, and when is it the wrong tool?

Accepted Answer

Each block contains the hash of the previous block, so changing an old block changes its hash and breaks every later link. Consensus (proof of work or proof of stake) makes rewriting history expensive, because an attacker would have to out-produce the honest network. A blockchain is the wrong tool when a trusted party already exists and a normal database would work, when data must be private or deletable, or when throughput and latency matter more than shared, verifiable state.

Question 16

What is the difference between proof of work and proof of stake?

Accepted Answer

In proof of work, miners compete to find a nonce that makes a block's hash meet a difficulty target; the cost is electricity and hardware, and the heaviest chain wins. In proof of stake, validators lock up tokens as collateral and are selected to propose and attest to blocks; dishonest behaviour can be punished by slashing their stake. Proof of stake uses far less energy and, on Ethereum, gives explicit finality through checkpoints, while proof of work offers probabilistic finality that grows with confirmations.

Question 17

What is finality, and how should an application treat unconfirmed or recent transactions?

Accepted Answer

Finality is the point after which a transaction cannot be reversed. Recent blocks can be replaced in a reorganisation, so applications should show recent transactions as pending, wait for a number of confirmations or for finalised blocks before treating value as settled, and design indexers to roll back data from blocks that were reorganised away. The right threshold depends on the chain and the value at risk.

Question 18

How is an Ethereum address derived from a private key?

Accepted Answer

The private key is a random 256-bit number. The public key is computed from it with elliptic-curve multiplication on the secp256k1 curve, which cannot practically be reversed. The address is the last 20 bytes of the Keccak-256 hash of the uncompressed public key, usually shown with an EIP-55 mixed-case checksum. Anyone who knows the private key controls the address, which is why keys must never be shared or stored in code.

Question 19

What is the difference between a call and a transaction on Ethereum?

Accepted Answer

A call executes a function locally on a node without creating a transaction: it is free, cannot change state and returns a value immediately, which suits view functions. A transaction is signed by an account, broadcast to the network, included in a block, costs gas, can change state and emits events; its result is known only after it is mined. Front ends use calls for reads and transactions for writes, and simulate transactions with calls to catch reverts before sending.

Question 20

What is gas, and how do you reduce the gas cost of a contract?

Accepted Answer

Gas measures the computation and storage a transaction uses; the sender pays gas used multiplied by the gas price. Storage writes are the most expensive operations. Reduce costs by minimising storage writes, packing variables into fewer storage slots, caching storage reads in memory, using immutable and constant values, custom errors instead of revert strings, calldata instead of memory for external inputs, and avoiding unbounded loops. Measure every change with a gas report, and never trade safety for small savings.

Question 21

What is the difference between storage, memory and calldata in Solidity?

Accepted Answer

Storage is persistent contract state on chain and is expensive to write. Memory is temporary, exists only during a function call and is cheaper. Calldata is the read-only input of an external call; using it for array and struct parameters avoids copying and saves gas. A common bug is assigning a storage struct to a memory variable, changing the copy, and expecting the stored data to change.

Question 22

Why use custom errors and events in Solidity?

Accepted Answer

Custom errors ( revert NotOwner() ) are cheaper than revert strings and can carry typed data, and callers can decode them by their 4-byte selector. Events record what happened in transaction logs, which cost far less than storage and are how front ends and indexers follow contract activity; indexed parameters can be filtered. Contracts cannot read their own events, so anything the contract needs later must be in storage.

Question 23

How do you implement and test access control in a contract?

Accepted Answer

Use audited patterns such as OpenZeppelin's Ownable for a single owner or AccessControl for roles, check msg.sender (never tx.origin ), and give each role only the powers it needs. Protect privileged functions with modifiers, emit events for role changes, and plan for key compromise with multisig owners and time-locks. Test every privileged function from an unprivileged account and assert the expected custom error, and test role grant, revoke and ownership transfer.

Question 24

What is reentrancy and how do you prevent it?

Accepted Answer

When a contract makes an external call (sending ether or calling another contract) before updating its own state, the callee can call back into the contract and act on stale state. Prevent it with the checks-effects-interactions pattern (validate, update state, then call out), a reentrancy guard on functions that make external calls, and pull-based payments. Remember that token callbacks can also re-enter. Write a test with a receiver that calls back, and check that the test fails when the protection is removed.

Question 25

How does Solidity 0.8 handle integer overflow, and when is unchecked used?

Accepted Answer

Since 0.8, arithmetic reverts on overflow and underflow by default, which removed a whole class of bugs that needed SafeMath before. An unchecked block turns the checks off to save gas, and should be used only where you have proved the values cannot overflow, such as a loop counter bounded by an array length. Rounding in division is a separate issue: always decide which way to round, usually in the protocol's favour.

Question 26

How do upgradeable contracts work, and what are the risks?

Accepted Answer

A proxy contract holds the state and delegates calls to an implementation contract using delegatecall; upgrading points the proxy to a new implementation. Patterns include transparent proxies and UUPS. Risks: storage layout collisions between versions, uninitialised implementations, and the upgrade key itself, which is a central point of trust. Mitigate with storage layout checks, initializers instead of constructors, upgrades behind a multisig and a time-lock, and tests that upgrade with real state.

Question 27

How would you test a smart contract before deployment?

Accepted Answer

Unit tests for every function and revert path, fuzz tests over inputs, and invariant tests for properties that must always hold (balances sum to total supply, the contract always holds what it owes). Differential tests against an independent model for complex maths, fork tests against real deployed contracts it integrates with, static analysis such as Slither, coverage reports, and an external audit before significant value is at stake. Deploy to a testnet and run the full flow before mainnet.

Question 28

A contract accepts signed messages to authorise actions. How do you prevent signature replay?

Accepted Answer

Include a per-signer nonce that increments on use, an expiry time, the chain ID and the contract address in the signed data, which EIP-712 domain separation provides. Mark each signature or nonce as used before acting on it, verify the recovered signer is the expected account, and reject malleable signatures (libraries such as OpenZeppelin's ECDSA handle this). Test replay on the same chain, on another chain ID and after expiry.

Question 29

How does a constant-product AMM price a trade?

Accepted Answer

The pool keeps the product of its two reserves constant (x times y equals k), apart from fees. When a trader adds one token, the amount of the other token they receive is whatever keeps the product constant after the fee is taken, so each unit bought is more expensive than the last. Price impact grows with trade size relative to the pool, fees accumulate for liquidity providers, and users protect themselves with a minimum output and a deadline.

Question 30

What is impermanent loss?

Accepted Answer

It is the difference in value between providing liquidity to an AMM and simply holding the two tokens, caused by the pool rebalancing as prices move: the pool ends up with more of the token that fell and less of the token that rose. It is called impermanent because it disappears if prices return to where they were. Trading fees can offset it. For a price change of ratio r, the loss relative to holding is 2 times the square root of r divided by (1 plus r), minus 1.

Question 31

Why is using a DEX pool's spot price as an oracle dangerous, and what should you use instead?

Accepted Answer

A pool's current price can be moved significantly within a single transaction, for example with a large trade funded by a flash loan, so a lending protocol reading that price could value collateral wrongly within the same block. Use prices that are hard to move for one block: time-weighted average prices over a sufficient window, or decentralised oracle networks that aggregate many sources, with sanity checks such as bounds, staleness limits and circuit breakers.

Question 32

What is slippage, and how does a swap protect users against it?

Accepted Answer

Slippage is the difference between the price a user expected and the price they get, caused by price impact and by other transactions executing first. Swaps accept a minimum output amount (or maximum input) and a deadline; if the price has moved beyond the user's tolerance or the transaction is mined too late, it reverts. Front ends should set sensible defaults and warn when the tolerance is high.

Question 33

What is MEV, and how can protocols and users reduce its impact?

Accepted Answer

Maximal extractable value is profit block producers and searchers can capture by including, excluding or reordering transactions, such as trading ahead of a large swap and after it. Users reduce exposure with tight slippage limits and private transaction submission services; protocols reduce it with batch auctions, commit-reveal schemes, time-weighted prices and designs that make ordering less valuable. It is also a reason not to broadcast sensitive transactions carelessly.

Question 34

Explain ownership and borrowing in Rust.

Accepted Answer

Every value has a single owner, and the value is dropped when the owner goes out of scope. Assigning or passing a non-Copy value moves ownership, so the old variable can no longer be used. Borrowing gives temporary access without ownership: many shared references ( &T ) or exactly one mutable reference ( &mut T ) at a time. The compiler enforces these rules, which prevents use-after-free and data races without a garbage collector.

Question 35

How does error handling work in Rust, and when is unwrap acceptable?

Accepted Answer

Recoverable errors are returned as Result<T, E> , and the ? operator propagates them to the caller. Errors are usually enums so callers can match on specific cases. Panics are for bugs and truly unrecoverable states. unwrap and expect are fine in tests and where failure is impossible by construction, but library code should return errors so callers decide what to do.

Question 36

A user clicks "Send" in your dApp. Which states must the interface handle?

Accepted Answer

Wallet not connected or on the wrong network; waiting for the user to sign (and the user rejecting); transaction submitted and pending, with a link to the explorer; confirmed after enough confirmations; and failed, either because it reverted (show a decoded reason) or was dropped or replaced. Disable repeated submission while pending, simulate the call first to catch reverts before asking for a signature, and keep the interface correct if the user switches accounts or networks meanwhile.

Question 37

Design an indexer that turns contract events into a database for an API.

Accepted Answer

Backfill events from the deployment block in batches, then follow new blocks. Store each event with its block number, block hash, transaction hash and log index, and make processing idempotent with a unique key on transaction hash and log index. Handle reorganisations by waiting for a confirmation depth before marking data final, or by checking parent hashes and rolling back rows from orphaned blocks. Checkpoint progress, use more than one node provider, monitor lag behind the chain head, and expose a reindex path.

Question 38

Your backend must send transactions automatically. How do you manage its keys?

Accepted Answer

Keep keys out of code, config files and environment variables in repositories. Use an HSM or a cloud KMS that signs without exposing the key, give the hot key only the permissions and funds it needs, and hold larger balances and admin rights in a multisig with a time-lock. Rate-limit and monitor what the key signs, alert on unusual activity, and have a tested rotation and revocation procedure, including updating contract roles if the key is compromised.

Question 39

What regulatory issues should a blockchain developer in India be aware of?

Accepted Answer

Crypto transfers are taxed in India (a 30% tax on gains and 1% TDS on many transfers), and virtual digital asset service providers must register with the Financial Intelligence Unit and follow anti-money-laundering rules, which brings KYC and record-keeping obligations. Personal data processed off chain falls under the DPDP Act, and immutable on-chain data conflicts with deletion rights, so personal data should not be written on chain. Rules change often, so check current guidance and involve legal counsel.

Question 40

Tell me about a time a reviewer found a serious problem in your code shortly before a release.

Accepted Answer

Use a STAR story. Show that you took the finding seriously without being defensive, assessed the impact, fixed the root cause rather than the symptom, added a test that would have caught it, and communicated clearly about any delay. For contract roles, mention that delaying a deployment is much cheaper than fixing a deployed contract. End with the process change you made afterwards.

Blockchain Developer interview questions

Concepts

Coding

Case studies

System design

Behavioural