Skip to main content

Discord

Frontend engineer at Discord

The typical process shape, common frontend engineer interview questions, and a market salary band for this role.

Process timeline

  1. 1

    Recruiter screen

    A conversation about your background, motivation, and logistics, plus a first check that your experience lines up with the frontend engineer opening.

  2. 2

    Technical phone

    A remote session on the core skills of the role, worked through live with an interviewer rather than answered as trivia.

  3. 3

    Onsite

    A longer block of back-to-back interviews with the team, mixing deeper skill exercises with behavioral questions about how you work.

  4. 4

    Decision

    Interviewers pool their feedback, the hiring manager makes the call, and the recruiter comes back with an outcome or next steps.

Interview questions

Common frontend engineer interview questions that come up across companies like Discord.

As asked

Walk me through every step that happens between you typing a URL and pixels appearing on screen. Go as deep as you can.

Sample answer outline

Cover the layers: input handling and autocomplete in the address bar; DNS resolution (local cache, OS resolver, recursive resolvers); TCP + TLS handshake; HTTP request; server-side processing (which the candidate can stay shallow on if frontend-only); response received and parsed; HTML parsing builds the DOM; CSS parsing builds the CSSOM; JS execution may block parsing; render tree built; layout (reflow) computes geometry; paint produces pixels; composite combines layers on the GPU. Modern additions: HTTP/3, Service Worker interception, Early Hints, streaming SSR, hydration.

Expect these follow-ups

  • Where in this flow does a Service Worker fit in?
  • Which step is usually the biggest LCP contributor and how do you measure it?
  • What changes if the page is served by a Next.js App Router with PPR?
browser-internalsperformancenetworking

As asked

Implement a debounce function in TypeScript. It should take a function and a delay in ms and return a debounced version. Bonus: support leading edge and a cancel method.

Sample answer outline

Maintain a timer ID in closure. On each call, clear the existing timer and schedule a new one. Pay attention to: preserving `this` correctly, typing the generic so the returned function has the same signature as the input, exposing `cancel` and (optionally) `flush`. Discuss difference vs throttle. Edge case: what if the callback throws.

Reference implementation (typescript)

TypeScript
export function debounce<TArgs extends unknown[]>(
  fn: (...args: TArgs) => void,
  delayMs: number,
): ((...args: TArgs) => void) & { cancel: () => void } {
  let timer: ReturnType<typeof setTimeout> | null = null;
  const debounced = (...args: TArgs) => {
    if (timer) clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delayMs);
  };
  debounced.cancel = () => {
    if (timer) clearTimeout(timer);
    timer = null;
  };
  return debounced;
}

Expect these follow-ups

  • How would you write a throttle that fires both leading and trailing?
  • How do you cancel a pending debounce on component unmount in React?
  • What is the difference between requestAnimationFrame-based debounce and setTimeout-based?
closuresjavascript-fundamentals

As asked

Explain when React Server Components are the right tool and when they are not. What changes in your mental model versus traditional React?

Sample answer outline

RSCs run on the server, never ship to the client, and can directly read from the database or filesystem. Good fit: pages that compose lots of data and want zero client JS for that composition (dashboards, content sites, lists). Not a fit: highly interactive UI (charts you can drag, editors, live forms) which still needs client components. The mental model shift: split your tree into server and client boundaries, pass data down as props (serialisable only), avoid mixing concerns. Pitfalls: passing event handlers across the boundary, accidental waterfalls, and the suspense story for streaming.

Expect these follow-ups

  • What is the hydration story for a page that mixes RSC and client components?
  • When does RSC make a page slower, not faster?
  • How does this change with Partial Prerendering?
reactrscnext-js

As asked

At a high level, what are the main steps that happen between typing a URL into the browser and the page appearing? Hit the big stages; you do not need to go deep into each one.

Sample answer outline

Give the clear high-level chain: the browser resolves the domain name to an IP via DNS, opens a connection to the server, sends an HTTP request, and receives the response. The browser then parses the HTML into the DOM, applies CSS, runs any JavaScript, and finally lays out and paints the page to the screen. At this level the goal is a confident, correct overview without rabbit-holing into TLS internals or the render pipeline. Showing you know the ordered stages and roughly what each does is enough for an early-career answer.

Expect these follow-ups

  • What does DNS do in one sentence?
  • Why does CSS or JavaScript sometimes delay the page appearing?
  • What is the difference between the DOM and the HTML you wrote?
browser-internalsfundamentalsnetworking

As asked

Walk me through what happens when a user loads a page in an app you own end to end. I want you to cover both the server side, where your backend generates the response, and the client side, where the browser turns it into pixels, and the choices that span both.

Sample answer outline

A full-stack engineer should narrate both halves and the seam between them. Server side: the request hits your application, which may run middleware, query the database, render markup or serialise data, and set caching and security headers. The response then travels back, and the browser parses HTML into the DOM, builds the CSSOM, runs JavaScript, and lays out and paints. The interesting decisions span both: what you render on the server versus hydrate on the client, how cache headers and a CDN change the second visit, how the payload shape avoids client over-fetching, and where authentication is checked. The strong answer shows you reason about the whole round trip rather than treating frontend and backend as separate worlds.

Expect these follow-ups

  • Which work do you keep on the server and which do you defer to the client?
  • How do cache headers and a CDN change the second page load?
  • Where in this flow do you enforce authentication?
browser-internalsfull-stackssrcaching

As asked

Explain in plain terms what a debounce function is for, give an example of where you would use it, and write a basic version in JavaScript or TypeScript.

Sample answer outline

Debounce delays running a function until a pause in activity, so it fires once after the user stops rather than on every event. The classic example is a search-as-you-type box: you wait until the user stops typing before calling the API. The basic implementation keeps a timer in a closure, clears it on each call, and schedules a fresh one. Keep the explanation concrete and the code small; an early-career answer does not need leading edge or a cancel method, just a correct timer that resets on every call and the contrast with calling on every keystroke.

Reference implementation (typescript)

TypeScript
export function debounce(fn, delayMs) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delayMs);
  };
}

Expect these follow-ups

  • What is the difference between debounce and throttle in one line?
  • What happens if you forget to clear the previous timer?
  • Why is search-as-you-type a good fit for debounce?
closuresjavascript-fundamentalsearly-career

Salary band

Senior p50
$269,000
City
San Francisco
Data type
Total comp
View salary detail

Similar companies