Front-End Design of an Emoji Picker with a Search Field

Quick Overview

A candidate-driven front-end system design discussion about an emoji picker with a search field. It tests how a candidate scopes the component, models and loads the emoji catalog, ranks search results, keeps a grid of thousands of emoji fast, and supports keyboard and screen-reader users.

Front-End Design of an Emoji Picker with a Search Field

Company: Atlassian

Role: Frontend Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

Design the front end of an emoji picker: the familiar panel that opens from a message box or a reaction button, shows emoji grouped by category in a scrollable grid, and has a search field at the top that filters the emoji as the user types. Selecting an emoji hands it back to whatever opened the picker. This is a short front-end system design discussion (about 15 minutes) in which the interviewer asks few questions, so you are expected to drive: set the scope, propose the architecture, and choose where to go deep. ```hint Size the data first Estimate how many emoji and search keywords the picker has to handle before deciding where search runs and how the data reaches the browser. ``` ```hint Find the expensive part Ask which part of the panel costs the most to render and to update on every keystroke, and design around that part. ``` ### Clarifying Questions - Is the picker a reusable component used by several surfaces (message composer, reactions, status), or a single screen? - Which features are in scope: categories, recently used emoji, skin-tone variants, custom emoji uploaded by users or organizations? - Which browsers and devices must be supported, and must emoji look identical everywhere, or may the operating system's own glyphs be used? - Must search work in several languages? - What keyboard and screen-reader support is required? ### What a Strong Answer Covers - Scope stated up front and a time plan that leaves room for depth, since the candidate drives the discussion. - A component breakdown (search field, category navigation, grid, preview, skin-tone control) with a clear state model and a small API for the host that opens the picker. - The emoji data model and a loading strategy that does not slow down the host page. - Search: matching against names and keywords, result ranking, and responsiveness while typing. - Rendering performance for a grid of thousands of items, and how emoji glyphs are drawn. - Keyboard navigation, focus management and screen-reader announcements. - Persistence of recent emoji and preferences, and behavior when the data fails to load. ### Follow-up Questions - How would the design change if an organization can upload thousands of custom emoji that change daily? - Emoji render differently, or not at all, across operating systems. What are the trade-offs between system glyphs and an image sprite? - How would you measure and protect the time from keystroke to updated results on low-end phones? - How would you test this component, including its accessibility?

Overview: A candidate-driven front-end system design discussion about an emoji picker with a search field. It tests how a candidate scopes the component, models and loads the emoji catalog, ranks search results, keeps a grid of thousands of emoji fast, and supports keyboard and screen-reader users.

Community answers

Answer by briancare82

What a front-end design would include a container where this emoji picker layout takes shape, it includes a search bar where the user can search for each emoji by name or letter, and a button that the user should press once they find their preferred emoji, which would display on a text editor by default, a right-to-left horizontal scroll that includes categories for each emoji, and a grid where each emoji is displayed and organized correctly, and some key features for this design would include different types of skin tones for each face and hand emoji, fast response time, lots of emoji's.
Atlassian logo
Atlassian
Sep 12, 2026
mediumFrontend EngineerTechnical ScreenSystem Design
18
0

Design the front end of an emoji picker: the familiar panel that opens from a message box or a reaction button, shows emoji grouped by category in a scrollable grid, and has a search field at the top that filters the emoji as the user types. Selecting an emoji hands it back to whatever opened the picker.

This is a short front-end system design discussion (about 15 minutes) in which the interviewer asks few questions, so you are expected to drive: set the scope, propose the architecture, and choose where to go deep.

Clarifying Questions Guidance

  • Is the picker a reusable component used by several surfaces (message composer, reactions, status), or a single screen?
  • Which features are in scope: categories, recently used emoji, skin-tone variants, custom emoji uploaded by users or organizations?
  • Which browsers and devices must be supported, and must emoji look identical everywhere, or may the operating system's own glyphs be used?
  • Must search work in several languages?
  • What keyboard and screen-reader support is required?

What a Strong Answer Covers Guidance

  • Scope stated up front and a time plan that leaves room for depth, since the candidate drives the discussion.
  • A component breakdown (search field, category navigation, grid, preview, skin-tone control) with a clear state model and a small API for the host that opens the picker.
  • The emoji data model and a loading strategy that does not slow down the host page.
  • Search: matching against names and keywords, result ranking, and responsiveness while typing.
  • Rendering performance for a grid of thousands of items, and how emoji glyphs are drawn.
  • Keyboard navigation, focus management and screen-reader announcements.
  • Persistence of recent emoji and preferences, and behavior when the data fails to load.

Follow-up Questions Guidance

  • How would the design change if an organization can upload thousands of custom emoji that change daily?
  • Emoji render differently, or not at all, across operating systems. What are the trade-offs between system glyphs and an image sprite?
  • How would you measure and protect the time from keystroke to updated results on low-end phones?
  • How would you test this component, including its accessibility?