SQL Playground
TutorialsPlayground
SQL FormatterSQL MinifierSyntax ValidatorJSON to SQLCSV to SQLSQL to JSONER Diagram Generator
Daily ChallengeInterviewsCheat SheetBlog

© 2026 SQL Playground. Built for developers.

PrivacyTermsAboutRSS Feed
SQL Playground
TutorialsPlayground
SQL FormatterSQL MinifierSyntax ValidatorJSON to SQLCSV to SQLSQL to JSONER Diagram Generator
Daily ChallengeInterviewsCheat SheetBlog
Back to Pool
Coinbase

Daily Trading Volume Trend

Calculate the daily trading volume and the percentage change from the previous day. Return trade_date, volume, and pct_change. Use window functions to compare with the previous day.

Schema

SQL Editor
Loading...

Execution Result

Write and run your query to see results here.

Problem Context & Learning

đź’ˇWhy This Question Matters

This time-series analysis problem is central to Coinbase's cryptocurrency exchange analytics. Understanding volume trends helps traders identify market momentum and liquidity patterns. This question tests your mastery of window functions, specifically LAG() for accessing previous rows, and percentage change calculations—critical skills for financial data analysis.

🔑Key SQL Concepts

Advanced concepts: LAG() window function to access previous row values, ORDER BY in window function to define row sequence, percentage change formula ((current - previous) / previous * 100), and NULL handling for the first row (no previous day). Understanding window function syntax and when to use them vs self-joins is essential.

🌍Real-World Applications

Coinbase's analytics teams use similar queries to: generate daily volume reports for market makers, detect unusual trading activity for fraud prevention, calculate volatility metrics for risk management, power real-time trading dashboards, identify optimal trading times based on liquidity, and feed machine learning models for price prediction.

Interview Insights & Approach

Strategic Approach

When tackling this Coinbase problem, the key is to understand the grain of the result. Are you returning one row per user, or one row per category? Always start by identifying your unique join keys and consider if filtered aggregations (CASE WHEN) are more efficient than multiple subqueries.

Common Pitfalls

Be careful with NULL values in your JOIN conditions or aggregate functions. In interview scenarios, datasets often include edge cases like zero-count categories or duplicate entries that can throw off a simple COUNT(*) if not handled with DISTINCT.

Discussion & Solutions

Share your approach, optimized queries, or ask questions. Learning from others is the fastest way to master SQL.

đź’¬ Join the conversation below

Comments

© 2026 SQL Playground. Built for developers.

PrivacyTermsAboutRSS Feed