Build a Social Feed List in HTML/CSS, Then Render It from a Mock API

Quick Overview

A two-stage front-end coding exercise: build a Twitter-style social feed list with HTML and CSS, then render it from a mock API. It tests semantic markup, a resilient card layout, asynchronous loading with loading and error states, and safe rendering of user-generated text.

Build a Social Feed List in HTML/CSS, Then Render It from a Mock API

Company: Atlassian

Role: Frontend Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

A front-end screen asks you to build, in two short timed stages, a feed that looks like a typical Twitter-style timeline: a vertical list of posts, each showing who wrote it and what they wrote. 1. First, build the feed as a static list using only HTML and CSS. 2. Then you are given a mock API that returns feed data, and you must feed that data into the list from the first stage, so that the posts are rendered from the API instead of being hard-coded. Assume a post shows what such a feed usually shows: an avatar, the author's display name and handle, a timestamp, the post text, and a row of actions with counts (reply, repost, like). The exact fields come from the mock API, so confirm them before the second stage. ### Constraints and Clarifications - Time budget: about 10 minutes for the static list and about 15 minutes for the mock-API stage. - The first stage uses only HTML and CSS; there is no data fetching yet. - The second stage should reuse the first stage's markup and styles rather than rebuilding the list. - The mock API's exact response shape is part of the exercise but is not reported here; state the shape you assume. ### Clarifying Questions - Which post fields must be displayed, and which are optional (for example, posts without an avatar, or with zero counts)? - For the second stage, is plain JavaScript expected, or may a framework such as React be used? - Is the mock API a function returning a promise, a JSON file, or an HTTP endpoint? Can it be slow, fail, or return an empty list? - Should the layout be responsive down to a phone-sized viewport? ### Part 1 — Static feed list in HTML and CSS Build a feed of a few hard-coded posts. Each post shows the avatar on the left and, to its right, a header line (display name, handle, timestamp), the post text, and an action row. ```hint Lay out one post first Get a single post right before repeating it. Which pieces sit side by side, which stack vertically, and which CSS layout tool makes that split easy? ``` #### What This Part Should Cover - Semantic markup for a list of posts, including a machine-readable timestamp and suitable alternative text for avatars. - A two-column post layout that survives long names, long unbroken words and multi-line text without overflowing. - Class names and structure that the second stage can generate from data without changes. ### Part 2 — Render the feed from a mock API Replace the hard-coded posts: call the mock API and render one post per item it returns, using the markup and styles from Part 1. ```hint Separate fetching from rendering Write one function that turns a single post object into markup, and decide what the page shows before the data arrives and if it never does. ``` #### Clarifying Questions for this Part - Is the post text plain text, or can it contain markup, links or mentions? - In what format do timestamps and counts arrive, and how should they be displayed (relative time, abbreviated counts)? - Is the response one complete list, or a page with a cursor for more? #### What This Part Should Cover - Asynchronous loading with explicit loading, error and empty states. - Mapping API fields onto the Part 1 markup, inserting user-written text as text rather than as HTML. - Efficient DOM updates (or keyed list rendering in a framework) and display formatting for times and counts. ### What a Strong Answer Covers - Both stages finished within the time budget, with the Part 2 renderer producing exactly the Part 1 markup. - Safe handling of user-generated content and of missing or unexpected fields in the API data. - Accessibility basics: list semantics, labeled action buttons, a machine-readable timestamp, and a status message that assistive technology announces. - A clear account of the shortcuts taken under time pressure and what would come next with more time. ### Follow-up Questions - How would you add infinite scrolling against a cursor-based API while preventing duplicate or out-of-order page loads? - If the feed grows to thousands of posts, how would you keep scrolling smooth? - How would you implement the like button optimistically and roll it back if the request fails? - How would you render mentions and links inside the post text without opening an injection hole?

Overview: A two-stage front-end coding exercise: build a Twitter-style social feed list with HTML and CSS, then render it from a mock API. It tests semantic markup, a resilient card layout, asynchronous loading with loading and error states, and safe rendering of user-generated text.

|Home/Software Engineering Fundamentals/Atlassian
Atlassian logo
Atlassian
Sep 12, 2026
mediumFrontend EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

A front-end screen asks you to build, in two short timed stages, a feed that looks like a typical Twitter-style timeline: a vertical list of posts, each showing who wrote it and what they wrote.

  1. First, build the feed as a static list using only HTML and CSS.
  2. Then you are given a mock API that returns feed data, and you must feed that data into the list from the first stage, so that the posts are rendered from the API instead of being hard-coded.

Assume a post shows what such a feed usually shows: an avatar, the author's display name and handle, a timestamp, the post text, and a row of actions with counts (reply, repost, like). The exact fields come from the mock API, so confirm them before the second stage.

Constraints and Clarifications

  • Time budget: about 10 minutes for the static list and about 15 minutes for the mock-API stage.
  • The first stage uses only HTML and CSS; there is no data fetching yet.
  • The second stage should reuse the first stage's markup and styles rather than rebuilding the list.
  • The mock API's exact response shape is part of the exercise but is not reported here; state the shape you assume.

Clarifying Questions Guidance

  • Which post fields must be displayed, and which are optional (for example, posts without an avatar, or with zero counts)?
  • For the second stage, is plain JavaScript expected, or may a framework such as React be used?
  • Is the mock API a function returning a promise, a JSON file, or an HTTP endpoint? Can it be slow, fail, or return an empty list?
  • Should the layout be responsive down to a phone-sized viewport?

Part 1 — Static feed list in HTML and CSS

Build a feed of a few hard-coded posts. Each post shows the avatar on the left and, to its right, a header line (display name, handle, timestamp), the post text, and an action row.

What This Part Should Cover Guidance

  • Semantic markup for a list of posts, including a machine-readable timestamp and suitable alternative text for avatars.
  • A two-column post layout that survives long names, long unbroken words and multi-line text without overflowing.
  • Class names and structure that the second stage can generate from data without changes.

Part 2 — Render the feed from a mock API

Replace the hard-coded posts: call the mock API and render one post per item it returns, using the markup and styles from Part 1.

Clarifying Questions for this Part Guidance

  • Is the post text plain text, or can it contain markup, links or mentions?
  • In what format do timestamps and counts arrive, and how should they be displayed (relative time, abbreviated counts)?
  • Is the response one complete list, or a page with a cursor for more?

What This Part Should Cover Guidance

  • Asynchronous loading with explicit loading, error and empty states.
  • Mapping API fields onto the Part 1 markup, inserting user-written text as text rather than as HTML.
  • Efficient DOM updates (or keyed list rendering in a framework) and display formatting for times and counts.

What a Strong Answer Covers Guidance

  • Both stages finished within the time budget, with the Part 2 renderer producing exactly the Part 1 markup.
  • Safe handling of user-generated content and of missing or unexpected fields in the API data.
  • Accessibility basics: list semantics, labeled action buttons, a machine-readable timestamp, and a status message that assistive technology announces.
  • A clear account of the shortcuts taken under time pressure and what would come next with more time.

Follow-up Questions Guidance

  • How would you add infinite scrolling against a cursor-based API while preventing duplicate or out-of-order page loads?
  • If the feed grows to thousands of posts, how would you keep scrolling smooth?
  • How would you implement the like button optimistically and roll it back if the request fails?
  • How would you render mentions and links inside the post text without opening an injection hole?
Loading comments...