Solana Development interview questions

What a strong answer covers

• PoH is a cryptographic clock that orders events before consensus, not a consensus mechanism itself.
• PoW uses computational puzzles to achieve consensus; PoS uses stake-based voting.
• PoH enables parallel transaction processing (Sealevel) by providing a global order.
• PoH requires high-bandwidth networking and a leader-based schedule.
• Tower BFT (Solana's consensus) uses PoH as a source of time to reduce message overhead.

Where people lose the point

• ×Claiming PoH replaces consensus entirely.
• ×Confusing PoH with a blockchain's timestamp field.
• ×Assuming PoH is a proof-of-work variant.

What a strong answer covers

• Rent is a fee paid per epoch to keep an account alive, based on its data size.
• Accounts with a balance sufficient to pay rent for 2 years become rent-exempt and no longer pay rent.
• Rent-exempt accounts persist indefinitely; non-exempt accounts may be garbage collected.
• Developers should ensure accounts are rent-exempt to avoid unexpected deletion.
• Rent can be reclaimed when an account is closed (via the `close` constraint in Anchor).

Where people lose the point

• ×Thinking rent is a one-time fee.
• ×Believing all accounts must pay rent forever.
• ×Ignoring rent-exemption when designing account sizes.

What a strong answer covers

• CPI allows a program to call instructions on another program, enabling composability.
• The calling program must pass all accounts required by the callee, including the callee program's ID.
• CPI is performed using `invoke` or `invoke_signed` (for PDA signing).
• The runtime enforces that the caller's signer privileges are passed to the callee.
• CPI depth is limited to 4 levels to prevent abuse.

Where people lose the point

• ×Forgetting to include the callee program's account in the accounts list.
• ×Assuming signer privileges are automatically propagated without explicit passing.
• ×Not checking the return status of a CPI call.

What a strong answer covers

• PDAs are addresses deterministically derived from a program ID and a set of seeds (e.g., strings, public keys).
• PDAs have no corresponding private key; only the program that derived them can sign on their behalf using `invoke_signed`.
• Common uses: creating unique account addresses for users (e.g., ATA), storing program state, and enabling program-controlled signing.
• The derivation uses a hash function and must find a nonce (bump) to ensure the address is off the ed25519 curve.
• Anchor provides the `#[account(seeds = ...)]` constraint to handle PDA derivation and validation.

Where people lose the point

• ×Thinking PDAs have private keys.
• ×Using the same seeds for multiple purposes without differentiation.
• ×Hardcoding bump seeds instead of storing them or deriving dynamically.

What a strong answer covers

• `init` creates a new account and assigns it to the program's owner.
• It requires the account to be a PDA (derived from seeds) or a signer (if not PDA).
• The account must not already exist; Anchor checks this.
• It automatically sets the account's owner to the program ID and allocates space based on the account struct.
• The `payer` field specifies who pays for the rent-exemption; often the user or a fee payer.

Where people lose the point

• ×Using `init` on an account that already exists (causes error).
• ×Forgetting to specify `payer` or `space` when needed.
• ×Assuming `init` works for non-PDA accounts without a signer.

What a strong answer covers

• The mint authority is the only account that can mint new tokens to any token account.
• It can also be used to set a new mint authority or freeze authority.
• To make a token fixed supply, the mint authority is set to None (revoked) after initial minting.
• Revoking the mint authority is a one-way operation; tokens cannot be minted afterward.
• This is commonly done by setting the authority to a PDA that cannot sign, or by using a multisig.

Where people lose the point

• ×Thinking the mint authority can be changed after being set to None.
• ×Confusing mint authority with freeze authority.
• ×Not revoking the mint authority when a fixed supply is desired.

What a strong answer covers

• An ATA is a deterministic token account address derived from a wallet address and a token mint using the ATA program.
• It ensures each wallet has at most one token account per mint, simplifying token management.
• ATAs are created on demand via the `createAssociatedTokenAccount` instruction.
• They are owned by the SPL Token program and controlled by the wallet owner.
• Using ATAs avoids the need to manage multiple token account addresses manually.

Where people lose the point

• ×Assuming ATAs are the only way to hold tokens (token accounts can be created manually).
• ×Thinking ATAs are owned by the user's wallet program.
• ×Forgetting to create an ATA before transferring tokens to a new wallet.

What a strong answer covers

• Sealevel is Solana's parallel smart contract runtime that identifies non-overlapping accounts.
• Transactions that touch disjoint sets of accounts can be executed concurrently.
• The runtime uses a transaction's account list to determine dependencies.
• PoH provides a global ordering, allowing the leader to schedule transactions in parallel.
• This design significantly increases throughput compared to sequential execution models like Ethereum.

Where people lose the point

• ×Claiming all transactions are executed in parallel (only those with non-overlapping accounts).
• ×Confusing Sealevel with sharding.
• ×Assuming parallel execution eliminates the need for atomic composability.

What a strong answer covers

• Tower BFT is a variant of Practical Byzantine Fault Tolerance (PBFT) optimized for Solana.
• It uses PoH as a global clock to reduce the number of messages needed for consensus.
• Validators vote on the latest PoH hash, and votes are weighted by stake.
• A supermajority (2/3+ of stake) is required to finalize a block.
• PoH allows validators to know the order of votes without additional communication, improving speed.

Where people lose the point

• ×Thinking Tower BFT is a separate consensus from PoH.
• ×Assuming Tower BFT requires all validators to communicate with each other.
• ×Confusing Tower BFT with Tendermint or HotStuff.

What a strong answer covers

• When an account is closed, its lamports (including rent-exemption) can be transferred to a destination account.
• In Anchor, the `close` constraint on an account automatically transfers its lamports to a specified `sol_dest` account.
• The account must be owned by the program and the instruction must be signed by the account's owner or a PDA.
• After closing, the account data is zeroed out and the account is no longer usable.
• Example: `#[account(mut, close = user)]` in a struct will send lamports to `user`.

Where people lose the point

• ×Forgetting to specify a destination for the rent.
• ×Closing an account that is still needed (data lost).
• ×Assuming rent is automatically returned without explicit close logic.

What a strong answer covers

• An account confusion attack occurs when a malicious user passes an account of the wrong type or ownership to a program instruction.
• For example, passing a token account where a mint account is expected, or passing an account owned by a different program.
• Anchor prevents this by using typed accounts (`Account<'_, MyType>`) that automatically check the account's owner and deserialize the data.
• The `#[account(owner = ...)]` constraint can enforce ownership by a specific program.
• Additionally, Anchor's `#[derive(Accounts)]` validates all accounts before the instruction executes.

Where people lose the point

• ×Relying solely on naming conventions to distinguish accounts.
• ×Not checking the owner program in manual implementations.
• ×Assuming Anchor's checks are optional (they are enforced at runtime).

What a strong answer covers

• BPF (Berkeley Packet Filter) is a restricted instruction set; programs cannot use floating-point arithmetic, dynamic memory allocation (except via a syscall), or certain system calls.
• Programs have a limited stack size (4KB) and heap (32KB) per instruction.
• All memory must be pre-allocated; no dynamic data structures like `Vec` without careful management.
• The runtime enforces a compute budget (max CU per instruction) to prevent infinite loops.
• Developers must optimize for low compute unit consumption and avoid expensive operations like large loops.

Where people lose the point

• ×Using floating-point numbers in program logic.
• ×Assuming dynamic memory allocation is available.
• ×Writing unbounded loops that exceed the compute budget.

What a strong answer covers

• Sysvars are system accounts that provide information about the current state of the blockchain, such as clock, rent, and epoch schedule.
• They are read-only and can be accessed by passing their well-known addresses to instructions.
• Common sysvars: `Clock` (slot, epoch, unix timestamp), `Rent` (rent parameters), `EpochSchedule` (epoch boundaries).
• In Anchor, sysvars are accessed via `Sysvar<'_, Clock>` or using the `clock` helper.
• Example: using `Clock::get()` to get the current slot for time-based logic.

Where people lose the point

• ×Trying to modify a sysvar account.
• ×Hardcoding sysvar addresses instead of using Anchor's typed access.
• ×Assuming sysvars are available on all clusters (they are).

What a strong answer covers

• Compute units measure the computational cost of an instruction; each instruction has a maximum CU budget (default 200k, can be increased via `ComputeBudget`).
• Operations like hashing, account deserialization, and CPI calls consume CU.
• Optimization strategies: minimize account reads/writes, use efficient data structures, avoid unnecessary CPI, and batch operations.
• Use `msg!` sparingly as it consumes CU; prefer logging only in development.
• Profile CU usage with `solana-validator` or test frameworks.

Where people lose the point

• ×Assuming CU budget is unlimited.
• ×Writing loops that iterate over large arrays without batching.
• ×Forgetting to set a higher compute budget via `ComputeBudgetProgram` when needed.

What a strong answer covers

• Anchor provides the `#[error_code]` attribute to define custom error enums that implement `Error`.
• Errors can be returned using `Err(MyError::Variant.into())` or the `require!` macro.
• The `require!` macro checks a condition and returns an error if false, improving readability.
• Anchor also maps common runtime errors (e.g., account not found) to user-friendly messages.
• Custom errors are serialized as u32 codes and can be caught on the client side.

Where people lose the point

• ×Using `panic!` instead of returning errors (panics consume CU and are not recoverable).
• ×Not using `require!` for simple condition checks.
• ×Defining errors without the `#[error_code]` attribute.

What a strong answer covers

• A multisig wallet requires multiple signers to approve a transaction before execution.
• Implementation: store a list of owners and a threshold in a PDA account.
• Proposals are created as separate accounts containing the instruction data and approval count.
• Each owner signs a transaction to approve the proposal; when threshold is met, the proposal can be executed via CPI.
• Key considerations: replay protection (use a nonce), owner management (add/remove owners), and secure execution (verify all approvals).

Where people lose the point

• ×Not checking that the same owner cannot approve twice.
• ×Allowing execution before threshold is reached.
• ×Storing sensitive data like private keys on-chain.