Frontend Online Assessments

Frontend online assessments are lost in the first five minutes, not the last. Candidates open problem 1, overbuild a clever tree, and never read problem 2, which was a 15-minute hashmap. Some papers also hide a 10-question MCQ section and a tiny DOM widget behind a tab. If you did not inventory the paper, you spent minutes like they were free.

An OA is a time-allocation problem with coding attached. Language choice, tests, and a written plan matter as much as the algorithm.

Key takeaways

• Read the whole paper before you type. Budget minutes per item in writing.
• Pick the language you can debug under time. For FE roles that is usually JavaScript.
• Make hidden tests boring: examples first, then edges, then complexity.
• Skip a stuck MCQ. A tiny UI is an MVP, not a design system.

Read the whole paper, then spend minutes like money

Do this before the first function.

1. Click every tab: coding, MCQ, UI, instructions, allowed libraries.
2. Note count, marks, and time.
3. Skim each prompt’s I/O. Mark easy / medium / “maybe skip.”
4. Write a minute budget. Leave a 5-minute buffer for submit glitches.
5. Start the item with the best marks-per-minute, not the one that looks prestigious.

Paper shape	Total	Split (example)
2 coding, 90 min	90	5 read, 40 + 40, 5 submit
2 coding + 10 MCQ, 75 min	75	5 read, 12 MCQ, 28 + 28, 2 buffer
1 coding + tiny UI, 60 min	60	5 read, 30 DSA, 22 UI, 3 buffer
3 coding, 120 min	120	8 read, 30 + 40 + 35, 7 buffer

If problem 3 is worth as much as 1 and looks like a known pattern, do not donate it to a stuck graph on problem 2. Move. You can return.

Pick a language

Default to JavaScript for frontend roles when the platform allows it. You will not fight vector<int> syntax while thinking about indexes. Exceptions:

• The posting is general SDE and they insist on Java/C++.
• You are faster in Python and you remember integer vs float gotchas (1/2 in Py2 is gone, but // vs / still bites).
• The UI section is in a browser sandbox that only runs JS anyway.

Set yourself up in the first minute: 'use strict' is already true in many sandboxes. Prefer const/let. Avoid ==. Do not import lodash unless the instructions say it is there.

How platform tests actually work

Most OA judges call your exported function with hidden cases. console.log is for you; the return value is for them.

/**
 * @param {number[]} nums
 * @param {number} target
 * @return {number[]}
 */
function twoSum(nums, target) {
  const seen = new Map();
  for (let i = 0; i < nums.length; i++) {
    const want = target - nums[i];
    if (seen.has(want)) return [seen.get(want), i];
    seen.set(nums[i], i);
  }
  return [];
}

// Local checks you type before submit (delete if the judge is noisy)
function assertEqual(actual, expected) {
  const a = JSON.stringify(actual);
  const e = JSON.stringify(expected);
  if (a !== e) throw new Error(`${a} !== ${e}`);
}
assertEqual(twoSum([2, 7, 11, 15], 9), [0, 1]);
assertEqual(twoSum([3, 3], 6), [0, 1]);

Write two examples from the prompt and two edges (empty, one element, duplicates, target at the ends). If the platform shows a “run sample” button, use it after each function is syntactically valid, not after a 20-minute rewrite.

Complexity: state it in a comment or in the wrap-up box if they have one. For FE OAs, O(n) with a hashmap beats a clever O(n log n) you cannot finish. Patterns: JavaScript coding interview patterns, complexity analysis, DSA hub, Two Sum.

MCQs on the platform

Frontend MCQs cluster around: event loop order, this, hoisting/TDZ, CSS specificity, HTTP cache headers, React keys. They are cheap points if you do not reread the same stem four times.

• First pass: answer what you know in under 45 seconds.
• Flag the rest. Second pass: eliminate two options, guess, move.
• Do not debug a 2-mark output question for 8 minutes while a 20-mark coder sits empty.

Warm up the night before with the method on JavaScript output-based questions, plus event loop and this binding. Do not cram fifty random quizzes during the OA clock.

Tiny UI sections

Some FE OAs embed a sandbox: todo, rating stars, typeahead. Score is usually “works + a couple of tests,” not visual design.

1. Read the acceptance tests if they are visible.
2. MVP: render, one interaction, persist in memory.
3. Then empty state. Then keyboard if the test names it.
4. Stop. Extra animations do not ship marks.

Reuse the timebox from machine coding interview framework. Practice todo app, star rating, tabs.

Footguns

• Coding in an editor with autosave off, then losing the buffer on a refresh. Copy locally if the platform is shaky (and if the rules allow).
• Mutating inputs when the prompt did not say you could.
• Off-by-one on windows and binary search. Dry-run [1] and [1,2].
• Printing instead of returning.
• Using sort without a comparator. JS default sort is UTF-16 string order: [10, 2, 1].sort() is [1, 10, 2].
• Starting the UI in CSS. Tests click the button, they do not screenshot the gradient.
• Cheating sites. That is a career event, not a prep tactic.

Default sort reminder you can type in 10 seconds:

nums.sort((a, b) => a - b); // numeric ascending

Interview out-loud (when a human reviews the OA later)

Some companies walk your OA on the phone. Be ready to recap:

“I read both problems first and spent forty minutes on the hashmap one because it was worth the same as the graph and I could finish it. I chose JavaScript, wrote the sample plus empty and duplicate cases, and returned indexes not values. I skipped two MCQs I was not sure about after a minute each. If I had fifteen more minutes I would have added the UI empty state.”

That recap is also how you should think during the paper, even with nobody watching.

Prep the week before

1. Two timed 45-minute DSA sessions in JS from the DSA set: arrays, hashing, intervals, binary search, a tree.
2. One mixed paper: 10 output/MCQ questions from your notes, then one widget.
3. One dry run of the platform if they send a practice link (HackerRank, Codility, CodeSignal, home-grown). Learn where Run vs Submit lives.
4. Sleep. An OA at 8am after a 2am grind is how you misread constraints.

Language path: JavaScript interview learning path, JavaScript interview guide.

Further reading

• Array.prototype.sort: MDN
• Map: MDN
• ECMA-262 (when an MCQ argues about ToUint32 or ===)

Related on this site

• DSA · Two Sum · Merge Intervals · LRU Cache
• JavaScript interview learning path
• JavaScript coding interview patterns
• Common frontend interview mistakes