Back to portfolio
Technical & SecuritySimulated project
Backend Engineer portfolio brief
A simulated technical & security exercise for Backend Engineer. Treat it as realistic practice, not real client or protocol work.
7 deliverables6 tools referenced3 linked interview questions
Objective
Build a small indexer and API
Expected deliverables
API serviceIndexerData modelReconciliation processMonitoring dashboardRunbookArchitecture decision record
Recommended workflow
- Build a small indexer and API
- Handle retries and reorgs explicitly
- Add observability, reconciliation, and a runbook
- Review the result against the rubric, then package it as a case study.
Constraints and safety
- Use only public sources or clearly simulated data.
- Never include seed phrases, private keys, or wallet secrets.
- Redact private user, company, security, legal, or compensation information.
- State every assumption you make.
Tools in practice
- Go, Rust, TypeScript, Python, or similar
- Collect and analyse the evidence used in API service and indexer, with definitions and reproducible steps.
- databases
- Design schemas and indexes for chain, account, and application data while planning consistency, retention, and recovery.
- queues
- Process asynchronous events, retries, backpressure, and ordering without losing or duplicating critical work.
- cloud infrastructure
- Deploy APIs, indexers, databases, queues, and observability with capacity, security, rollback, and disaster-recovery plans.
- RPC and indexing tools
- Read chain data reliably, manage provider limits, index relevant events, and recover from reorgs or missed blocks.
- observability stack
- Connect logs, metrics, traces, alerts, and incident records so service failures can be reproduced and fixed.
What a strong submission shows
- An indexer with reorg handling
- A documented API
- A reconciliation job
- An incident postmortem
Weak submission patterns
- A CRUD API with 'Web3' added to the title
- Services with no observability
- Indexers that assume events are never reorganized
Review rubric
- Accuracy of claims and sources
- Relevance to the target role
- Decision quality and trade-offs
- Completeness of the deliverable
- Clarity of communication
- Honest limitations and next steps
Present it as a case study
- Explain the problem, sources, decisions, ownership, constraints, output, review, and what you would change.
- Show the final artifact before the process notes.
- State what you owned and what belonged to other people.
- Label the work as simulated, and keep any real contribution clearly separate.
Interview questions this project helps you answer
How do you make event processing idempotent?
What happens to your database when a chain reorg invalidates events?
How would you design around an unreliable RPC provider?