Solana Developer Job Description Template

Solana Rust programs · 30%
Core of the role is building and maintaining Solana on-chain logic reliably in Rust. Evaluated in Round 1.

• Weak: Explains what a Solana program does but struggles to describe how it validates accounts and handles instruction data.
• Meets the bar: Describes a clear program structure and basic account validation approach; can reason through typical instruction execution flow.
• Strong: Walks through a specific program design including instruction interfaces, account constraints, and how it avoids common correctness pitfalls.

Account model mastery · 20%
Correct PDAs, ownership checks, and account constraints are essential to security and correctness. Evaluated in Round 1.

• Weak: Gives high-level descriptions of PDAs/accounts without explaining derivation/validation details.
• Meets the bar: Explains PDA derivation and typical account checks (owner, mutability, data) and how they map to runtime behavior.
• Strong: Designs/defends an account model with precise constraints, explains failure modes, and describes how to validate accounts defensively.

Solana security thinking · 20%
Security fundamentals directly reduce the likelihood of exploitable flaws in on-chain programs. Evaluated in Round 2.

• Weak: Mentions security concerns broadly without tying them to concrete checks and threat scenarios.
• Meets the bar: Identifies key security checks (input validation, access control, safe account handling) and explains why they matter.
• Strong: Proactively outlines multiple attack surfaces and maps them to specific mitigations and verification steps in code and reviews.

Client transaction integration · 15%
The role requires robust off-chain transaction construction and integration behavior. Evaluated in Round 2.

• Weak: Describes sending transactions conceptually but cannot explain how it builds instructions, manages signers, or handles confirmations/errors.
• Meets the bar: Explains how to create transactions with correct accounts/signers and manage confirmation and basic error handling.
• Strong: Describes an integration flow end-to-end, including deriving accounts client-side, handling retries/idempotency, and interpreting failure reasons.

Debugging with logs · 10%
Production support requires reading logs/traces and turning evidence into fixes quickly. Evaluated in Round 3.

• Weak: Relies on guesswork when diagnosing; cannot interpret log output meaningfully.
• Meets the bar: Interprets common log patterns and can narrow down where a failure occurred using transaction traces.
• Strong: Uses transaction details (program logs, compute/err codes, account states) to form hypotheses and propose precise corrective changes.

Independent delivery · 5%
Mid-level scope requires owning well-defined work without constant guidance. Evaluated in Round 3.

• Weak: Needs frequent direction to break down work or validate completion criteria.
• Meets the bar: Clarifies requirements, proposes a plan, and delivers incrementally with appropriate checks.
• Strong: Takes ownership of ambiguous parts, defines acceptance criteria, coordinates dependencies, and surfaces risks early.