36 practice questions with answers for Blockchain interviews in Lucknow.
Blockchain jobs in Lucknow
Lucknow's tech job market is smaller but growing, led by IT-services delivery centres, government-tech projects and start-ups. Many Lucknow candidates target Noida and Gurgaon roles or remote jobs, so interviews follow the NCR pattern.
Below are 36 questions that match the mix of service, product and domain employers hiring blockchain developers in Lucknow.
Solved for LucknowStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
A 51 percent attack happens when one party controls a majority of mining power or stake. It can then reorder or exclude transactions, censor users and double spend by building a longer private chain that replaces recent blocks. It cannot steal coins from other addresses or forge signatures. Large chains like Bitcoin and Ethereum make it extremely expensive, but small PoW chains have suffered such attacks, which is why exchanges require many confirmations on them.
02
A user approved unlimited token spending to a scam site. What should they do?
Revoke the approval immediately using a token approval checker or by calling approve(spender, 0) from the wallet, because the malicious contract can pull tokens any time. If a drain has started, move remaining assets to a fresh wallet. Check for other suspicious approvals and NFT setApprovalForAll permissions. Going forward, approve exact amounts, read wallet prompts carefully, use a separate hot wallet for new dApps, and prefer wallets that simulate transactions before signing.
03
Your fantasy sports contract needs live match scores. How do you get that data on-chain?
Smart contracts cannot call web APIs, so use an oracle. Options include a decentralised oracle network such as Chainlink Functions to fetch from several sports APIs and aggregate, or an optimistic oracle where results are proposed and can be disputed. Settle only after the match result is final, use multiple data sources, add a dispute window for high-value pools, and handle cancelled matches. Avoid a single back-end key posting results, which is a central point of failure.
04
How is an Ethereum address derived from a private key?
Start with a random 256-bit private key. Multiply it by the secp256k1 generator point to get a 64-byte uncompressed public key. Take the Keccak-256 hash of that public key and keep the last 20 bytes; that is the address, shown as 0x plus 40 hex characters. EIP-55 adds a mixed-case checksum so typos can be detected. The process is one-way: you cannot get the private key back from the address or public key.
05
How did you handle a time you received critical code review feedback?
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.
06
How do you listen to contract events and query past events with ethers?
Use contract.on for live events and queryFilter for history.
const abi = ['event Transfer(address indexed from, address indexed to, uint256 value)'];
const token = new Contract(TOKEN, abi, provider);
token.on('Transfer', (from, to, value, event) => {
console.log(from, to, value.toString(), event.log.blockNumber);
});
const filter = token.filters.Transfer(null, MY_ADDRESS);
const past = await token.queryFilter(filter, -5000); // last 5000 blocks
console.log(past.length);
Use a WebSocket provider for live events, and page large ranges because providers limit block spans.
07
How do you deploy a contract to a Layer 2 testnet with Foundry?
Set the RPC URL and a deployer key, then use forge create or a script, and verify the source on the explorer.
export RPC_URL=https://sepolia.l2-example.org
export PRIVATE_KEY=0x... # testnet key only
forge create src/Counter.sol:Counter \
--rpc-url $RPC_URL --private-key $PRIVATE_KEY --broadcast
# Scripted deploy with verification
forge script script/Deploy.s.sol --rpc-url $RPC_URL \
--broadcast --verify
Use a keystore via cast wallet import instead of raw keys for anything real.
08
Your dApp's users are paying high gas fees on Ethereum mainnet. How would you choose a Layer 2?
I would compare candidate rollups on security (proof system live, stage of decentralisation, upgrade keys), EVM compatibility so our Solidity code deploys unchanged, ecosystem fit (wallets, oracles, liquidity, bridges our users already use), fees and throughput, and withdrawal experience. I would deploy to testnets first, measure real costs and latency, and check that our dependencies such as Chainlink feeds exist there. Then migrate gradually, keeping L1 contracts for high-value settlement if needed.
09
Users complain they received far fewer tokens than expected on large swaps. What is happening and how do you help?
Large trades in shallow pools suffer price impact, and wide slippage settings let sandwich bots extract extra value. Show the expected output, price impact and minimum received before confirming. Set sensible default slippage, such as 0.5 percent for major pairs, and warn when impact is high. Use a router or aggregator that splits trades across pools, and offer private transaction submission so bots cannot see the swap in the public mempool.
10
What are state channels, such as the Lightning Network?
A state channel locks funds in an on-chain contract or multisig between parties, who then exchange many signed off-chain updates and settle only the final state on-chain. Lightning on Bitcoin links channels into a network so payments route through intermediaries using hashed timelock contracts. Channels give instant, nearly free payments but need participants to be online or use watchtowers, and they lock liquidity, so they suit repeated payments between known parties rather than general smart contracts.
A dApp usually has smart contracts on a chain holding core logic and assets; a front-end, often React or Next.js, that connects to the user's wallet; a library such as ethers.js, viem or wagmi to read and write contracts through an RPC provider; an indexer or subgraph for fast queries of history; decentralised storage such as IPFS for files and metadata; and optional back-end services for notifications, relaying or off-chain computation, with oracles bringing external data on-chain.
A sidechain is an independent blockchain with its own validators and consensus, connected to the main chain by a bridge. Its security depends on its own validator set, so if they collude, funds can be stolen. A rollup posts its transaction data and state roots to Ethereum and relies on fraud or validity proofs, so it inherits Layer 1 security for correctness. Sidechains are usually cheaper and more flexible, but rollups give stronger guarantees.
13
You are asked to design a cross-chain bridge. What are the main risks and design choices?
Bridges hold large pooled funds, so they are top hacking targets. Main risks are compromised validator or multisig keys, faulty message verification, and replay of messages across chains. Prefer verification based on light clients or zk proofs over a small trusted multisig. Use rate limits, per-transfer caps, pausing, monitoring of mint-versus-lock balances, and a delay for large transfers. Get multiple audits, run a bug bounty, and consider established messaging protocols instead of building from scratch.
14
Design a back-end relayer so users can make transactions without holding gas.
Users sign an EIP-712 meta-transaction or an ERC-4337 UserOperation. The relayer validates the signature, checks business rules and rate limits per user, then submits it, paying gas from a hot wallet or via a paymaster. Contracts must verify the original signer, using ERC-2771 trusted forwarders or account abstraction. Manage nonces carefully with a queue, replace stuck transactions, keep the relayer wallet funded and monitored, and cap daily sponsorship to prevent abuse.
15
How do you handle unclear or changing requirements from a client?
Situation: a client asked for a marketplace dApp but kept changing royalty and fee rules. Task: deliver without endless rework. Action: I wrote a short spec with examples and edge cases, got sign-off, and made fees configurable parameters with limits instead of hard-coded logic. Changes went through a simple change log with impact estimates. Result: we delivered in eight weeks, and later fee changes needed only a governance transaction, not a redeployment.
Typical bugs include missing onlyOwner or role checks on sensitive functions such as mint, withdraw or setOracle, initialiser functions in upgradeable contracts that anyone can call, misconfigured roles, and a single EOA owning critical powers. Use OpenZeppelin Ownable2Step or AccessControl, give each role the minimum rights, protect admin actions with a multisig and timelock, and write tests confirming that every privileged function reverts for unauthorised callers.
17
What are front-running and sandwich attacks, and how do you mitigate them?
Pending transactions are public, so bots can copy or outbid them. Front-running is placing a transaction ahead of a victim's, for example buying before a large purchase. A sandwich attack buys before the victim's swap and sells right after, profiting from the price impact. Mitigations include slippage limits and deadlines, commit-reveal schemes, batch auctions, private transaction relays, and design that does not reward ordering, such as using time-weighted prices.
In the UTXO model used by Bitcoin, coins exist as unspent transaction outputs; a transaction consumes some outputs and creates new ones, which makes parallel validation and privacy easier. In the account model used by Ethereum, the state stores a balance and nonce per account, which is simpler for smart contracts and wallets. The trade-off: UTXO avoids replay issues and scales verification well, while accounts make complex stateful logic far easier to write.
19
What is the difference between an execution client and a consensus client, and why does client diversity matter?
Since the Merge, an Ethereum node runs two pieces of software. The execution client, such as Geth, Nethermind, Besu, Erigon or Reth, runs the EVM, holds state and handles transactions. The consensus client, such as Lighthouse, Prysm, Teku, Nimbus or Lodestar, runs Proof of Stake. They talk over the Engine API. Client diversity matters because a bug in a client used by over two-thirds of validators could finalise an invalid chain and cause mass slashing.
20
What is the difference between optimistic rollups and zk-rollups?
Optimistic rollups assume batches are valid and allow a challenge window, typically about seven days, during which anyone can submit a fraud proof; this makes them EVM-compatible and simpler but slows native withdrawals. Zk-rollups submit a validity proof with each batch, so L1 verifies correctness mathematically and withdrawals finalise once the proof is accepted. Zk proving is computationally heavy and EVM equivalence was harder, though zkEVMs have matured a lot by 2026.
21
How is a blockchain different from a traditional database?
A traditional database is controlled by one administrator who can create, update and delete rows, and trust comes from that owner. A blockchain is shared by many parties, is append-only, and trust comes from cryptography and consensus. The trade-off is performance: a database handles thousands of writes per second with low latency, while a public chain is slower and costlier. Use a blockchain only when several parties who do not fully trust each other must share one record.
22
The business wants to change contract logic after launch. How do you plan for it?
Decide early whether upgradeability is needed, because it adds trust and storage risks. Options are a proxy (UUPS or Transparent) controlled by a multisig with a timelock, a parameter-driven design where only settings like fees change through governed setters, or a migration plan to a new immutable version. Whatever you choose, document it for users, protect upgrade rights, keep storage layout append-only, and test each upgrade on a fork before executing.
23
What is double spending and how does a blockchain prevent it?
Double spending is trying to spend the same digital money twice, for example sending the same coins to two merchants. A blockchain prevents it by keeping one shared ordering of transactions agreed through consensus. Once a transaction is included in a block, any conflicting transaction that spends the same funds is rejected as invalid. Merchants wait for several confirmations so that the chance of the block being replaced in a reorg becomes negligible.
24
How do you calculate a borrower's health factor in a lending protocol?
Health factor = (sum of collateral value x liquidation threshold) / total debt value. Below 1, the position can be liquidated.
Example: collateral 10 ETH at 3,000 dollars = 30,000 dollars, liquidation threshold 80 percent, debt 18,000 dollars of stablecoins.
HF = (30,000 x 0.80) / 18,000 = 1.33.
If ETH falls to 2,250, collateral is 22,500, so HF = 18,000 / 18,000 = 1.0 and liquidation begins. Users raise HF by repaying debt or adding collateral.
25
How do you compute a keccak256 hash in Solidity and in ethers.js?
Solidity:
bytes32 h1 = keccak256(abi.encodePacked('hello'));
bytes32 h2 = keccak256(abi.encode(addr, amount));
ethers v6:
import { keccak256, toUtf8Bytes, solidityPackedKeccak256 } from 'ethers';
const h = keccak256(toUtf8Bytes('hello'));
const p = solidityPackedKeccak256(['address','uint256'], [addr, amount]);
Prefer abi.encode over abi.encodePacked when hashing several dynamic values, because packed encoding can cause collisions.
26
How do you read a contract and send a transaction with viem?
IPFS, the InterPlanetary File System, is a peer-to-peer network for storing and sharing files. Instead of locating files by server address, it identifies them by a content identifier (CID) derived from the file's hash, which is content addressing. The same content always has the same CID, and any change gives a new CID, so data cannot be swapped silently. Files must be pinned by a node or pinning service, otherwise they may disappear.
A Merkle tree hashes data items in pairs, level by level, until one root hash remains. The root summarises all items: changing any item changes the root. A Merkle proof is the list of sibling hashes on the path from one item to the root. With it, a light client can prove that a transaction is in a block using about log2(n) hashes instead of downloading all transactions. Airdrop allowlists use the same trick on-chain.
29
What is the difference between a soft fork and a hard fork?
A soft fork tightens the rules so that new blocks are still valid for old nodes; it is backward compatible, like Bitcoin's SegWit upgrade. A hard fork changes the rules so that old nodes reject new blocks, so every node must upgrade or the chain splits, as with Ethereum and Ethereum Classic in 2016. Planned network upgrades on Ethereum, such as Dencun and Pectra, are coordinated hard forks that all clients adopt together.
30
After a transaction is confirmed, your front-end still shows old data. How do you fix it?
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.
31
Design token vesting for team members and early investors.
Use a vesting contract that holds allocated tokens and releases them on a schedule, typically a one-year cliff followed by monthly or linear vesting over two to four years. OpenZeppelin VestingWallet gives linear vesting per beneficiary; add a cliff and an owner-controlled revoke for employees who leave, returning unvested tokens. Make schedules public on-chain for transparency, and avoid admin functions that could release tokens early, as that erodes investor trust.
32
What is the difference between CREATE and CREATE2?
CREATE computes a new contract's address from the deployer's address and nonce, so the address depends on deployment order. CREATE2 computes it from the deployer address, a chosen 32-byte salt and the hash of the init code, so the address is known before deployment and is the same wherever those inputs match. CREATE2 enables counterfactual wallets, deterministic factory deployments and same-address deployments across chains, but redeploying at the same address needs care.
A multisig wallet is a smart contract, such as a Safe, that needs M of N owner signatures to execute a transaction; rules are visible on-chain and easy to audit, but every action costs extra gas and works per chain. An MPC wallet splits one private key into shares held by different parties who jointly produce a normal signature; it looks like a regular address, works on any chain and allows key rotation, but the security depends on the off-chain implementation.
34
A user is angry that withdrawing from an optimistic rollup to Ethereum takes seven days. How do you explain and solve it?
Explain that the seven-day window lets anyone challenge a fraudulent batch; it protects their funds. For faster exits, offer third-party fast bridges or intent-based bridges where a liquidity provider pays them on L1 within minutes for a small fee and later claims the slow withdrawal. Also show the expected timeline clearly in the UI and send a notification when funds are claimable, because most anger comes from uncertainty, not the delay itself.
35
What is the difference between a full node, a light node and an archive node?
A full node downloads and validates every block and keeps the current state, so it can verify everything independently. A light node stores only block headers and asks full nodes for Merkle proofs of the data it needs, which suits mobile wallets. An archive node keeps all historical states, so you can query a balance at any past block; indexers and block explorers need it, but it requires many terabytes of storage.
A revert undoes all state changes made during that transaction, including nested calls, as if it never ran. However, the transaction is still included in a block, the nonce is consumed, and the sender pays for the gas used up to the revert. Contracts revert with require, revert or custom errors, which return a reason the wallet can show. Since the Byzantium upgrade, unused gas is refunded on revert, unlike the old invalid opcode which consumed everything.
Which companies hire Blockchain professionals in Lucknow?
Companies with large offices in Lucknow include HCLTech. Use their company pages below to practise employer-specific sets.
Are Blockchain interviews in Lucknow different from other cities?
The questions depend more on the company than the city. Lucknow's mix of employers decides the style: Many Lucknow candidates target Noida and Gurgaon roles or remote jobs, so interviews follow the NCR pattern
How do I find Blockchain jobs in Lucknow?
Shortlist companies with Lucknow offices, keep your CV focused on Blockchain projects, apply on company career pages and job portals with the Lucknow filter, and practise the questions on this page before each interview.