yoklainterview sim
ProgressHistory

Frontend Senior Interview Questions

1917 verified Frontend Senior interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

AccessibilityDifficulty 3
After a user submits a form via AJAX, a 'Saved successfully' message appears in a <div>. Sighted users see it, but screen-reader users get no announcement. What is the standard accessible approach?
  • aRender the message into a container marked with aria-live="polite" so its updates get announced✓
  • bShow the message inside an alert() dialog so the browser reads it aloud for every user
  • cAdd role="button" to the message element so that screen readers treat it as interactive
  • dMove keyboard focus to the page's <h1> element each time the message is shown
Explanation:An aria-live region tells assistive tech to announce content that changes dynamically without the user moving focus; polite waits for a pause so it does not interrupt. role="button" (c) is semantically wrong for a status message, and yanking focus to the h1 (d) is disorienting and does not read the message.
AccessibilityDifficulty 3
<h2 id="billing">Billing address</h2>
<section aria-labelledby="billing">
  ...
</section>

What does aria-labelledby="billing" do here?
  • aIt names the <section> using the text of the element whose id is billing✓
  • bIt copies the heading's text into the section so that the <h2> can then be removed
  • cIt hides the <h2> from screen readers, because the section already references it
  • dIt links the section to the heading only for styling, with no effect on assistive tech
Explanation:aria-labelledby points to the id of another element and reuses its visible text as this element's accessible name, so the section is announced as the 'Billing address' region. It does not duplicate or remove the heading (b) and is not a styling hook (d) — it is purely a naming relationship.
AccessibilityDifficulty 3
A form marks required fields by coloring their labels red, with no other indicator. Which accessibility principle does this violate, and what is the fix?
  • aIt violates keyboard access; the fix is to add tabindex to each and every required label
  • bIt violates heading order; the fix is to wrap the required labels in a higher heading level
  • cIt relies on color alone to convey meaning; add a text or symbol cue such as 'required' or '*'✓
  • dIt violates the contrast rule; the fix is to make the red brighter so that it stands out much more
Explanation:WCAG's 'use of color' rule says color must not be the only means of conveying information, because color-blind and some low-vision users cannot perceive it; adding a visible marker (an asterisk, the word 'required', or aria-required) fixes it. Brightening the red (d) still leaves color as the sole cue.
AccessibilityDifficulty 3
You build a custom toggle switch out of a <div> that flips an on/off state on click. To make it fully accessible, what does it need beyond just looking right?
  • aOnly a distinct background color for the on and off states so the change stays visible
  • bOnly an aria-label, since naming the control is enough for assistive tech to operate it
  • cOnly tabindex="0", because once it can be focused the browser will handle all the rest
  • dA role (e.g. switch), keyboard operation, and a state like aria-checked kept in sync✓
Explanation:A custom widget must reproduce everything a native control gives for free: a role so it is announced correctly, focusability and key handling so it works from the keyboard, and a state (aria-checked) updated as it toggles. Focusability alone (c) or a name alone (b) leaves it unoperable or unannounced for assistive-tech users.
AccessibilityDifficulty 3
<button role="button" aria-hidden="true" onclick="submit()">
  Submit
</button>

What is wrong with the ARIA on this native button?
  • arole="button" is required on every <button>, but here the aria-hidden should be "false"
  • brole="button" is redundant, and aria-hidden="true" hides a focusable control from screen readers✓
  • cNothing is wrong; both attributes are needed together for the button to be announced correctly
  • daria-hidden is fine, but role="button" conflicts with the native role and disables the click
Explanation:A <button> already has an implicit button role, so role="button" is pointless duplication; worse, aria-hidden="true" removes a still-focusable, operable control from the accessibility tree, so keyboard users can reach a control screen readers never announce. The role does not disable the click (d) — it is simply redundant.
Css LayoutDifficulty 3
.container {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: flex-start;
  height: 400px;
}

How are the children positioned inside this container?
  • aCentered horizontally, and aligned to the top edge
  • bCentered both horizontally and vertically
  • cAligned to the left edge and stacked from the top
  • dCentered vertically, and aligned to the left edge✓
Explanation:With flex-direction: column the main axis runs top-to-bottom and the cross axis runs left-to-right. So justify-content: center centers the children vertically, while align-items: flex-start pins them to the (left) start of the cross axis. The common mistake (a) assumes justify-content is always horizontal, which is only true for the default row direction.

Topics

Accessibility 75Angular Change Detection 75Angular Components Lifecycle 75Angular Dependency Injection 75Angular Directives Pipes 75Angular Router Forms 75Angular Testing Performance 75Css Layout 75Dom Browser Apis 75Javascript Async Concurrency 75Javascript Language 75Javascript Memory Performance 75Javascript Modules Bundling 75Javascript Prototypes Oop 75Javascript Runtime Apis 75Javascript Testing Tooling 75Performance 75React Components Jsx 75React Context State 75React Effects Lifecycle 75React Forms Suspense 75React Hooks State 75React Rendering Performance 75Rendering Reactivity 75State Management 75Testing 75Typescript Advanced Types 75Typescript Generics 75Typescript Modules Declarations 75Typescript Narrowing Control Flow 75Typescript Tooling Config 75Typescript Type Fundamentals 75Vue Components Props 75Vue Composition Api 75Vue Directives Templates 75Vue Performance Testing 75Vue Reactivity System 75Vue Router State Management 75Web Security 75

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview