# Mobile vs Desktop Session Duration

> Mobile versus desktop. Who stays longer?

Canonical URL: <https://datadriven.io/problems/mobile_vs_desktop_session_duration>

Domain: SQL · Difficulty: medium · Seniority: L4

## Problem

For each user in 2025, compute the longest session on a mobile device versus the longest session on a desktop device.

## Worked solution and explanation

### Why this problem exists in real interviews

By linking user_sessions.session_start against devices, this problem requires grouping and date extraction on a multi-table result set. Interviewers deploy it in mid-level screens to see if you handle the intermediate cardinality correctly.

> **Trick to Solving**
>
> Read the prompt carefully for implicit constraints. The phrase structure hints at the grain of the output: what each row represents.
> 
> 1. Identify the output grain from the prompt (one row per what?)
> 2. Work backward from the desired output columns
> 3. Build the query inside-out: innermost subquery first, then layer on filters and aggregates

---

### Break down the requirements

#### Step 1: Join tables with INNER JOIN

Connect `user_sessions` and `devices` on `device_id` to keep only matching rows.

#### Step 2: Filter to the target rows

Apply the date filter using `STRFTIME` to extract and compare the relevant time component. This restricts rows before aggregation.

#### Step 3: Aggregate with MAX

Group by the output grain and apply `MAX()` to compute the metric. The `GROUP BY` must match exactly what the output needs: one row per group key.

---

### The solution

**Conditional MAX for side-by-side comparison**

```sql
SELECT s.user_id,
    MAX(CASE WHEN d.device_type = 'mobile' THEN s.session_duration_sec END) AS longest_mobile,
    MAX(CASE WHEN d.device_type = 'desktop' THEN s.session_duration_sec END) AS longest_desktop
FROM user_sessions s
JOIN devices d ON s.device_id = d.device_id
WHERE STRFTIME('%Y', s.session_start) = '2025'
GROUP BY s.user_id
```

> **Cost Analysis**
>
> The join touches `user_sessions` (60M rows) and `devices` (8M rows). `user_sessions` is partitioned by `session_start`, which the optimizer can exploit with a partition filter.

> **Interviewers Watch For**
>
> Interviewers expect you to articulate why you chose a specific join type and what happens to unmatched rows. Walking through comparison logic step by step, rather than writing it in one pass, demonstrates structured thinking.

> **Common Pitfall**
>
> Forgetting that a JOIN can multiply rows when the relationship is one-to-many. Always check whether the join key is unique on at least one side.

---

## Common follow-up questions

- What happens to your result if devices.browser contains NULLs for some rows? _(Tests whether the candidate accounts for NULL behavior in aggregates and comparisons on browser.)_
- If the join between user_sessions and devices produces a fan-out, how does that affect your aggregate? _(Tests awareness of join cardinality and its impact on SUM, COUNT, and AVG results.)_
- With millions of distinct values in user_sessions.session_id, what index strategy would you use to keep this query performant? _(Tests indexing knowledge specific to high-cardinality columns like session_id.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/mobile_vs_desktop_session_duration)
- [SQL Interview Questions](https://datadriven.io/sql-interview-questions)
- [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep)
- [Daily Challenge](https://datadriven.io/daily)

---

Source: DataDriven (https://datadriven.io). 100% free data engineering interview prep. Live code execution against Postgres 16, Python 3.11, and Spark sandboxes. No paywall, no premium tier, no signup gate.