Skip to content
SDETRole
SDETRole

Practice / JavaScript

JavaScript Coding Challenges for SDETs

Coding rounds for SDET roles favour practical problems: transform test data, retry flaky async calls, parse reports, implement small utilities. Every challenge here runs your code against real tests in your browser.

Challenges
18
Beginner
6
Intermediate
9
Advanced
3
Solved
0

Challenges

  1. 01 Chunk an array Split an array into groups of a fixed size. A warm-up that checks loop bounds, the last partial chunk and input validation.
  2. 02 Check for an anagram Decide whether two phrases are anagrams, ignoring case, spaces and punctuation. Tests normalisation and character counting.
  3. 03 First non-repeating character Return the first character that appears exactly once in a string. A classic use of Map, which keeps insertion order.
  4. 04 Group test results by key Implement groupBy(items, key) to bucket test results by status or by a computed key. Practises reduce and dynamic property access.
  5. 05 Safe JSON parse Wrap JSON.parse so it never throws and returns a result object instead. A pattern for reading API bodies and test fixtures safely.
  6. 06 Diff two flat objects Compare an expected and an actual API payload and report added, removed and changed keys. The core of every JSON diff tool.
  7. 07 once() and memoize() Build two classic higher-order functions on closures: once(fn) runs fn a single time, and memoize(fn) caches results by arguments.
  8. 08 Get a value by path Read a nested value from an API response with a path such as "data.items[0].id", returning a default when any step is missing.
  9. 09 Summarise a test report Parse a JSON test report and compute totals, the pass rate and the slowest test. The kind of script SDETs write for CI summaries.
  10. 10 Deep clone test data Write deepClone() for nested objects, arrays and Dates so each test gets its own copy of a fixture. Shows why spread and JSON fall short.
  11. 11 Promisify a callback API Implement promisify(fn) to turn a Node-style (err, value) callback function into one that returns a Promise, so you can await it.
  12. 12 Predict the event loop order Predict the order in which a snippet mixing setTimeout, promises, queueMicrotask and await logs its output. The tests run the real snippet.
  13. 13 Run async tasks in series Implement runInSeries(tasks) so async steps run one after another, unlike Promise.all. Useful for ordered setup such as create user, then log in.
  14. 14 Retry a flaky async call Write retry(fn, attempts, delayMs) that re-runs a failing async function and rejects with the last error. Common for flaky test setup calls.
  15. 15 Implement Promise.all Write promiseAll(values) without using Promise.all: keep input order, accept plain values and reject on the first failure.
  16. 16 Debounce with cancel Implement debounce(fn, wait) with a cancel() method, and test it with real timers. Explains how search-as-you-type inputs behave in UI tests.
  17. 17 Find duplicate values Write findDuplicates(arr) that returns each repeated value once, in the order it first appeared, without mutating the input.
  18. 18 Classify an HTTP status code Write statusClass(code) that maps an HTTP status code to its class, such as 'client error', and throws a RangeError for anything that is not a valid code.

What SDET coding rounds actually test

Coding rounds for automation roles rarely ask for dynamic programming or graph algorithms. They ask you to write the kind of small, reliable utility that lives in every test framework: group test results by status, compare two API payloads, read a value from a nested response, retry a flaky call, or run steps in order without a race. Interviewers watch three things: whether the code is correct on edge cases (empty arrays, missing keys, duplicates), whether you reach for the right built-in (Map, Set, Object.entries, Array.prototype.reduce), and whether you understand asynchronous JavaScript well enough not to write tests that pass by accident.

The challenges here are written around those expectations. Each one gives a short problem statement, a starter function and a set of unit tests, and the tests include the edge cases an interviewer would raise as follow-up questions.

A suggested order through the challenges

The async mistakes interviewers look for

The most common bug in JavaScript test code is an await that does not wait. items.forEach(async (i) => { await save(i); }) starts every call and returns immediately, because forEach ignores the promises its callback returns. Use for (const i of items) { await save(i); } for sequential work, or await Promise.all(items.map(save)) when the calls are independent and can run in parallel.

Event loop ordering is the other classic. In console.log(1); setTimeout(() => console.log(2)); Promise.resolve().then(() => console.log(3)); console.log(4); the output is 1, 4, 3, 2: synchronous code runs first, then the microtask queue (promise callbacks), then the next macrotask (the timer). Being able to explain why, not just recite the answer, is what separates a mid-level answer from a senior one.

How your code is checked

Your code runs in a Web Worker inside a sandboxed iframe with network access disabled. The tests call your functions directly with Jest-style expect() matchers, so a pass means your code really produced the right values, including for the edge cases. A challenge is only marked solved when every test passes, and progress is saved in your browser.

When you are comfortable here, read async programming for testers, then try answering the JavaScript interview questions out loud before revealing the model answers.

Frequently asked questions

Do I need to know algorithms for an SDET coding round?

You need solid data handling more than advanced algorithms. Arrays, objects, maps, sets, string manipulation and async control flow cover most SDET coding questions; complexity analysis matters mainly when you explain why a Map lookup beats a nested loop.

Can I use TypeScript in these challenges?

The challenges run plain JavaScript. The same solutions work in TypeScript once you add types, and the TypeScript interview questions cover typing helpers like these.

Why does my solution pass locally but fail here?

The tests include edge cases such as empty input, duplicate values and rejected promises. Read the failing test name and its expected value: it usually points to the case your solution does not handle.

Is my code sent to a server?

No. Code runs in a sandboxed Web Worker in your browser with network access disabled.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →