← Back to list

Okta SDE-2 Frontend Interview Experience | 45 LPA

Role: Software Development Engineer 2 — Frontend Interview Mode: Online (Coding + Technical Discussion)

Gourav Hammad in Frontend Army ⭐ · 2026-07-16 04:01 · 93 claps · 3.3 min read paywalled
#javascript #interview #react #reactjs #frontend
Open on Medium ↗
Wiki topics: 💻 · Programming 🌐 · Web Development

Okta SDE-2 Frontend Interview Experience | 45 LPA

Role: Software Development Engineer 2 — Frontend Interview Mode: Online (Coding + Technical Discussion)

Recently, I interviewed for an SDE-2 Frontend position at Okta. The interview focused heavily on React, JavaScript fundamentals, and Frontend System Design. Here’s a breakdown of the interview along with the approach I discussed.

Round 1: React + JavaScript

React Coding Challenge — Dynamic Grid

The interviewer provided a React boilerplate and asked me to implement the following.

Problem Statement

Input: An integer n

Output: An n × n grid.

Requirements

  • Initially, all cells are empty.
  • Clicking an empty cell assigns it max(existingValue) + 1.
  • Clicking an already filled cell updates it to max(existingValue).

My Approach

Instead of storing the current maximum separately in state, I kept only the grid state as the source of truth.

On every click:

  1. Flatten the grid.
  2. Compute the maximum value.
  3. Clone only the affected row.
  4. Update the clicked cell.
  5. Return a new grid reference.

This avoids synchronization issues between multiple states.

For better performance on larger grids, another approach is to maintain currentMax in state and update it only when necessary, reducing repeated scans of the grid.

What Interviewers Expected

  • Immutable state updates
  • Proper component decomposition
  • Efficient rendering
  • Avoiding unnecessary state
  • Clear explanation of trade-offs

The interviewer was more interested in why I chose a particular implementation than simply getting the correct output.

JavaScript Discussion

The interviewer presented multiple snippets involving asynchronous JavaScript and asked me to explain their execution.

Topics included:

  • Event Loop
  • Call Stack
  • Execution Context
  • Promise chaining
  • async/await
  • async vs defer
  • Debouncing
  • Throttling
  • Memory management
  • Synchronous vs asynchronous APIs

Sample Discussion

Promise vs setTimeout

console.log(1);

setTimeout(() => console.log(2));

Promise.resolve().then(() => console.log(3));

console.log(4);

Output

1
4
3
2

Explanation

  • Synchronous code executes first.
  • Promise callbacks are added to the Microtask Queue.
  • setTimeout callbacks go into the Macrotask Queue.
  • The Event Loop always clears all microtasks before executing the next macrotask.

async vs defer

async

  • Downloads in parallel.
  • Executes immediately after download.
  • Does not preserve script order.
  • Can block HTML parsing during execution.

defer

  • Downloads in parallel.
  • Executes only after HTML parsing completes.
  • Preserves script execution order.
  • Preferred for most application scripts.

Debouncing

Use when you want to delay execution until the user stops acting.

Examples:

  • Search input
  • Auto-save
  • API requests

Throttling

Limit execution to once every fixed interval.

Examples:

  • Scroll events
  • Mouse movement
  • Window resize

Memory Management

The interviewer also discussed:

  • Stack Memory
  • Heap Memory
  • Garbage Collection

Memory leaks caused by:

  • Event listeners
  • Timers
  • Closures
  • Detached DOM nodes

Hey New Readers 👋

If you’re new here, make sure to check out my **Frontend Army publication, where I have published 70+** detailed Frontend interview experiences, Top ReactJS, JavaScript questions, and many more.

Great resource for anyone preparing for Frontend Engineer interviews 🚀

Round 2: Frontend System Design

Problem Statement

Design a content publishing platform where:

  • Admins publish Markdown files.
  • Users can read articles.
  • The platform should scale efficiently.

My High-Level Design

Admin Portal
      │
      ▼
Backend API
      │
Markdown Storage (S3)
      │
Metadata Database
      │
     CDN
      │
Frontend Application

Design Decisions

Why Markdown?

  • Lightweight
  • Easy version control
  • Fast rendering
  • SEO friendly

Storage

Store:

  • Markdown in object storage (Amazon S3)

Store metadata in SQL:

  • Title
  • Slug
  • Author
  • Published Date
  • Tags

This keeps searching efficient while avoiding large text blobs inside relational tables.

Rendering

I suggested using Server-Side Rendering or Static Site Generation because:

  • Better SEO
  • Faster First Contentful Paint
  • Better Core Web Vitals

CDN

A CDN makes sense because:

  • Markdown content changes infrequently.
  • Most requests become cache hits.
  • Reduced server load.
  • Lower latency worldwide.

SQL vs NoSQL

I preferred SQL because:

  • Articles have structured metadata.
  • Relationships (author, category, tags).
  • Strong consistency.
  • Easier filtering and pagination.

NoSQL would only become attractive for extremely high write throughput or highly flexible schemas.

SEO

Important points discussed:

  • Sitemap generation
  • Canonical URLs
  • Open Graph metadata
  • Structured Data
  • Server-rendered HTML
  • Robots.txt

Authentication

Admins

  • JWT Authentication
  • Role-Based Access Control

Readers

  • Public endpoints
  • Cached content

Caching Strategy

Browser Cache
    ↓
 CDN Cache
    ↓
Server Cache
    ↓
 Database

This layered caching minimizes backend load and improves response times.

Back-of-the-Envelope Estimation

The interviewer asked for approximate numbers such as:

  • Daily active users
  • Concurrent readers
  • Articles published per day
  • Average Markdown file size
  • Total yearly storage

The goal wasn’t exact numbers but demonstrating the ability to estimate infrastructure requirements.

Final Result

Unfortunately, I wasn’t selected.

The interviewer mentioned that my JavaScript fundamentals — particularly around asynchronous execution and JavaScript internals — needed to be stronger for an SDE-2 role.

I hope this interview experience helps others preparing for senior frontend interviews. Good luck with your preparation!


메타데이터
post_id
7163980a4e0a
slug
okta-sde-2-frontend-interview-experience-45-lpa-7163980a4e0a
url
https://medium.com/frontend-army/okta-sde-2-frontend-interview-experience-45-lpa-7163980a4e0a
canonical_url
https://medium.com/frontend-army/okta-sde-2-frontend-interview-experience-45-lpa-7163980a4e0a
author_url
https://medium.com/@gouravhammad477
status
ok
fetched_at
2026-07-18 08:08:13