sprkdsprkd.io
πŸ—„οΈSkill assessment Β· 180 questions

Databases skill assessment

SQL, modeling, indexing, transactions, and scale.

What it covers

SQL & Queries

Fluent SQL is the baseline expectation in almost every engineering interview and every real job β€” you'll write joins and aggregations daily, and window functions separate people who can query from people who can analyze.

Joins (inner, outer, self, cross) and when each appliesSubqueries vs. CTEs (WITH queries)Window functions (ROW_NUMBER, RANK, LAG/LEAD, running totals)GROUP BY, HAVING, and aggregate pitfallsSet operations (UNION, INTERSECT, EXCEPT) and query composition

Data Modeling

The schema you design today is the schema you're stuck migrating for years β€” normalization prevents data-integrity bugs, but knowing when to denormalize is what keeps queries fast at scale.

Normalization (1NF-3NF) and what each form preventsDenormalization tradeoffs and when they pay offPrimary keys, foreign keys, and referential integrityModeling one-to-many and many-to-many relationshipsSchema evolution and migrations without downtime

Indexing & Performance

An unindexed query that's fine at 1,000 rows can take down production at 10 million β€” reading query plans and choosing the right index type is how you catch that before users do.

B-tree, hash, and composite indexesReading EXPLAIN / EXPLAIN ANALYZE outputCovering indexes and index-only scansWhen indexes hurt (write overhead, low-cardinality columns)N+1 queries and other common performance traps

Transactions & Concurrency

Two requests hitting the same row at the same time is where 'it works on my machine' breaks β€” understanding ACID and isolation levels is what keeps money, inventory, and bookings from silently going wrong.

ACID properties in practiceIsolation levels (Read Committed, Repeatable Read, Serializable)Row-level locking and deadlocksOptimistic vs. pessimistic concurrency controlMVCC and how it avoids blocking readers

NoSQL & Scaling

Not every problem fits a relational table β€” knowing when a document, key-value, or column store beats SQL (and the consistency tradeoffs that come with it) is core to designing systems that scale past one server.

Document, key-value, and column-family modelsCAP theorem and consistency/availability tradeoffsSharding strategies and partition keysReplication (leader-follower, multi-leader, leaderless)Caching layers and cache invalidation

Operations & Reliability

The database is the one piece of infrastructure you truly can't just redeploy β€” backups, failover, and connection pooling are what turn an outage into a non-event instead of a resume-generating one.

Backup strategies and point-in-time recoveryReplication topologies and automated failoverConnection pooling and connection limitsMonitoring slow queries and resource saturationZero-downtime schema migrations and maintenance

Ready to benchmark your Databases skills?

180 questions Β· about 5 minutes Β· see your level and percentile instantly.

Take the assessment β†’

Explore other assessments