Practice JavaScript & TypeScript interview problems in your browser

Write a solution and see exactly which test cases pass and which fail, edge cases included. No account, no setup.

Practice a problemRun mock interview with a friend

Solo practice runs tests instantly in your browser. A mock interview generates a shareable room for two.

Hiring engineers? See Pairlet for companies →
pairlet.dev/problems/valid-parentheses
Strings / Data StructuresEasy

Valid Parentheses

Given a string s containing bracket characters, determine if the string is valid in correct order.

Test cases
"()"
single pair
"()[]{}"
mixed brackets
"([)]"
wrong bracket type
"{[()]}"
deeply nested
""
empty string
function isValid(s: string): boolean {
// Stack-based bracket matcher implementation
const stack: string[] = [];
const map = { ')': '(', '}': '{', ']': '[' };
for (const char of s) {
if (map[char]) {
if (stack.pop() !== map[char]) return false;
} else stack.push(char);
}
return stack.length === 0;
}
console.log(isValid("()[]")); // true
Test resultsCompleted in 1.4ms · in your browser
5 / 5 passed
Real test casesNamed edge casesCode review drills26 curated JS/TS problems
WhyWhat tells you if you are right

No account. No paywall. No setup.

Open a problem, write something, and find out whether it actually works. That last step is the one that is usually missing.

The default way

Reading the answer

You find a solution, recognise it, and move on. The code looks right — but you never found out whether you could have written it.

Looks right

recognition, not retrieval

Why it is not enough

  • A plausible answer looks like a correct one
    Without a runnable test case there is nothing to tell the two apart.
  • The edge case finds you later
    Off-by-one and wrong-bracket bugs stay invisible until an interviewer feeds in the input that breaks them.
  • Answers are the only reward
    Reading a solution teaches you less than running your own attempt and seeing it fail.
  • You never write the first line
    Reading starts at line 40. Typing starts at line 1, which is the part that gets tested.
PairletThe way that checks you

Pairlet

Open a problem, write your own solution, and run it against named test cases. You find out which case breaks it, and what kind of input that was.

Free

every problem and test case included

What you get

  • Real test cases
    Run your own solution and see exactly which cases pass and which fail, edge cases included.
  • Named edge cases
    Each case carries a description, so a failure tells you what kind of input broke you — not just that something did.
  • Code review drills
    Read realistic code with planted flaws, write down what you would flag, then compare with the notes.
  • Runs in your browser
    A real editor and in-browser execution. Nothing to install, nothing to configure.
  • 26 curated JS/TS problems
    Coding challenges and code review exercises, plus a task creator for anything specific.
PopularInterview questions

Start with a curated task

View All 82 Problems
Strings / Data Structureseasy

Valid Parentheses

Given a string `s` containing just the characters `'('`, `')'`, `'{'`, `'}'`, `'['` and `']'`, determine if the input string is valid. An input string is valid if: 1. Open brackets must be closed by the same type of brackets. 2. Open brackets must be closed in the correct order. 3. Every close bracket has a corresponding open bracket of the same type.

Practice this problem
Arrays & Hashingeasy

Two Sum

Given an array of integers `nums` and an integer `target`, return indices of the two numbers such that they add up to `target`. You may assume that each input would have exactly one solution, and you may not use the same element twice.

Practice this problem
JavaScript Utilitieseasy

Implement Debounce

Implement a `debounce` function that delays invoking `fn` until after `delay` milliseconds have elapsed since the last time the debounced function was invoked.

Practice this problem
TypeScript & ArchitectureCode Review

Code Review: Bad TypeScript Design

Review the following TypeScript data mapper. Identify type safety flaws, excessive `any` usage, unsafe type assertions (`as any`), and weak interfaces. Refactor for strict type safety.

Practice this problem

Prefer a realistic engineering discussion?

Browse code review exercises
No accountNothing to install either

Ready to solve one right now?

Pick a problem and write something. Then run it against test cases and find out whether it actually works.

Practice a problem