Lesson 11 of 30

Empty, Loading & Skeleton States

Q: You're building a dashboard feed that loads a list of activity items. Walk through how you'd handle the loading experience and the case where the feed is genuinely empty.

A strong answer covers: Distinguishes spinner (unknown shape/duration) from skeleton (predictable shape, reduces perceived wait) and picks skeleton for a list with a known card layout; Explains the actual mechanism — the skeleton previews layout shape so the user re-parses less when real content lands, not just 'it looks nicer'; Treats the empty state as a separate, deliberately designed state (not a loading state) with an explanation and a next action, rather than a bare 'no items' message; Recognizes a skeleton mismatched to the real content's size/shape creates its own layout shift.

'Show a loading state' collapses three genuinely different situations into one instruction. A spinner, a skeleton, and an empty state each answer a different question, and using the wrong one is a real, common bug.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A list view with a predictable card layout (avatar, title, two lines of text) currently shows a plain spinner while data loads. What's the strongest reason to switch to a skeleton instead?

The skeleton previews the layout's shape, reducing perceived wait and the re-parsing work needed once content arrivesSkeletons load data faster than a spinner-based approachSpinners are not accessible to screen readers, so skeletons are required for compliance

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Empty, Loading & Skeleton States

What interviewers actually ask about this, and what a strong answer has to cover.

You're building a dashboard feed that loads a list of activity items. Walk through how you'd handle the loading experience and the case where the feed is genuinely empty.

A strong answer covers

Distinguishes spinner (unknown shape/duration) from skeleton (predictable shape, reduces perceived wait) and picks skeleton for a list with a known card layout
Explains the actual mechanism — the skeleton previews layout shape so the user re-parses less when real content lands, not just 'it looks nicer'
Treats the empty state as a separate, deliberately designed state (not a loading state) with an explanation and a next action, rather than a bare 'no items' message
Recognizes a skeleton mismatched to the real content's size/shape creates its own layout shift

Likely follow-ups

What would make you choose a spinner over a skeleton for this same feed in a different scenario?
How would you handle the moment content finishes loading — should the transition from skeleton to real content be instant or animated, and why?

Practice these with the AI interviewer →

The plain-language idea

"Add a loading state" gets treated as one problem when it's actually three, and conflating them is where most of the real mistakes happen:

A spinner communicates "wait, duration unknown." It's the right tool when there's genuinely nothing to show yet and no way to predict the shape of what's coming — a form submission, a short background action.
A skeleton communicates "content is coming, and here's roughly its shape" — placeholder blocks sized and positioned like the eventual title, avatar, and text lines. Because the user can start parsing the layout before the content exists, skeletons measurably reduce perceived wait time compared to a spinner for the same actual duration.
A true empty state isn't a loading state at all — it's what shows when loading finished and there's genuinely nothing there (no results, no items yet, an empty inbox). Treating it as an error to apologize for, or worse, as a blank white space, wastes a real design opportunity: an empty state is where a product gets to explain what would normally be here and prompt the first action that fills it.

See it in a real thing: the same card, two loading strategies

Skeleton vs. spinner: the same content, two loading statesStep 1 of 4

Both cards start loading. The left shows a skeleton — placeholder blocks already sized and positioned like the real content. The right shows only a spinner.

The difference isn't cosmetic. A spinner-based card jumps from an undifferentiated circle to a full layout the instant data arrives — a discontinuous change the eye has to fully re-parse. A skeleton-based card's placeholder blocks are already claiming the exact screen space the avatar, title, and body text will occupy, so when real content swaps in, the layout doesn't move and the user's attention doesn't have to restart from zero. That's the actual mechanism behind "skeletons feel faster" — it's not an illusion about speed, it's a reduction in re-parsing work at the moment content lands.

What people usually miss

Watch out

A spinner for a data-heavy view (a list, a table, a feed) is usually a missed opportunity for a skeleton, not a neutral choice — anywhere the eventual shape is predictable, a skeleton gives the user something to do with their eyes while they wait.
A spinner is still the right call when the shape genuinely isn't knowable — a search whose result count and layout can't be predicted, or a short one-off action with no meaningful shape to preview. Skeletons aren't a universal upgrade; they're a tool for predictable layouts.
An empty state that only says "No items" with nothing else is a dead end, not a state. A good empty state explains why it's empty (never searched yet? no results for this filter? no data yet?) and gives a next action — a genuinely different situation gets a genuinely different message and prompt.
Loading states and empty states get the same treatment by accident when a team ships "handle the empty array case" as one afterthought line, rather than as a deliberately designed state with its own content and layout, treated with the same care as the populated view.

Why this matters in interviews

"Walk me through how you'd handle this list loading" is a real, common frontend interview prompt, and naming all three states — spinner for unknown-shape waits, skeleton for predictable-shape waits, and a designed (not default) empty state — signals a candidate who has actually shipped data-heavy UI, not just happy-path components.