Build a React Table That Fetches and Paginates API Data from Scratch

Read the full interview experience this question came from →

Quick Overview

Starting from an empty React project, build a page that fetches records from an HTTP API, shows them in a table and lets the user page through them. The exercise tests hand-written data fetching with hooks, loading, error and empty states, handling of stale responses, and correct pagination controls.

Build a React Table That Fetches and Paginates API Data from Scratch

Company: Remitly

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

Starting from an empty React project, build a page that fetches records from an HTTP API, renders them in a table, and handles pagination. Write the data fetching, the table and the pagination controls by hand, without a data-fetching or table library. The endpoint and the response shape were not reported; assume something like the following and confirm it with the interviewer. ```text GET /api/records?page=2&pageSize=20 (illustrative) { "items": [ { "id": 21, "name": "...", "status": "..." }, ... ], "total": 137 } ``` ```hint Requests that finish out of order Think about what happens when the page changes again before the previous request has finished, and which response is allowed to update the table. ``` ```hint Everything the user can see List every state the page can be in between clicking a page button and seeing rows, including the ones where something goes wrong or nothing comes back. ``` ### Constraints and Clarifications - Reported: an empty project, hand-written fetching, a rendered table, and pagination handling. - Not given: the endpoint, whether pagination is page-based, offset-based or cursor-based, the page size, and which columns to show. Ask, or state your assumptions. - The round also included 10 to 15 minutes of behavioral questions, and the code runs in a shared online editor, so get a minimal component rendering on screen before writing the rest. ### Clarifying Questions - Does the API paginate on the server (page and page size, offset and limit, or a cursor), or does it return the whole list for the client to page through? - Does the response include a total count, so the page can show "page X of Y" and disable Next on the last page? - Which columns appear, in what order and format, and does any column need sorting? - What should the user see while a page loads, when a request fails, and when there are no rows? - Should the current page survive a reload or be shareable through the URL? ### What a Strong Answer Covers - Component state for the page, rows, total, loading and error, with a fetch effect keyed on the page - Correct fetch handling: checking the HTTP status, parsing JSON, and cancelling or ignoring stale responses - A semantic table with stable row keys and clear loading, error and empty states - Pagination controls with correct bounds, disabled states and page-count arithmetic - Working in small steps that render early, and a way to test the component without a live API ### Follow-up Questions - The API switches to cursor-based pagination. What changes in your state and in the controls? - Add server-side sorting by a column. How does it interact with the current page? - A user clicks Next five times quickly. Which requests go out, and what does the table show at each moment? - How would you test this component without a live API?

Overview: Starting from an empty React project, build a page that fetches records from an HTTP API, shows them in a table and lets the user page through them. The exercise tests hand-written data fetching with hooks, loading, error and empty states, handling of stale responses, and correct pagination controls.

Read the full Remitly Software Engineer interview experience this question came from

Remitly logo
Remitly
Oct 15, 2026
mediumSoftware EngineerOnsiteSoftware Engineering Fundamentals
0
0

Starting from an empty React project, build a page that fetches records from an HTTP API, renders them in a table, and handles pagination. Write the data fetching, the table and the pagination controls by hand, without a data-fetching or table library.

The endpoint and the response shape were not reported; assume something like the following and confirm it with the interviewer.

GET /api/records?page=2&pageSize=20          (illustrative)

{
  "items": [ { "id": 21, "name": "...", "status": "..." }, ... ],
  "total": 137
}

Constraints and Clarifications

  • Reported: an empty project, hand-written fetching, a rendered table, and pagination handling.
  • Not given: the endpoint, whether pagination is page-based, offset-based or cursor-based, the page size, and which columns to show. Ask, or state your assumptions.
  • The round also included 10 to 15 minutes of behavioral questions, and the code runs in a shared online editor, so get a minimal component rendering on screen before writing the rest.

Clarifying Questions Guidance

  • Does the API paginate on the server (page and page size, offset and limit, or a cursor), or does it return the whole list for the client to page through?
  • Does the response include a total count, so the page can show "page X of Y" and disable Next on the last page?
  • Which columns appear, in what order and format, and does any column need sorting?
  • What should the user see while a page loads, when a request fails, and when there are no rows?
  • Should the current page survive a reload or be shareable through the URL?

What a Strong Answer Covers Guidance

  • Component state for the page, rows, total, loading and error, with a fetch effect keyed on the page
  • Correct fetch handling: checking the HTTP status, parsing JSON, and cancelling or ignoring stale responses
  • A semantic table with stable row keys and clear loading, error and empty states
  • Pagination controls with correct bounds, disabled states and page-count arithmetic
  • Working in small steps that render early, and a way to test the component without a live API

Follow-up Questions Guidance

  • The API switches to cursor-based pagination. What changes in your state and in the controls?
  • Add server-side sorting by a column. How does it interact with the current page?
  • A user clicks Next five times quickly. Which requests go out, and what does the table show at each moment?
  • How would you test this component without a live API?