JavaScript interview questions: the 12 that actually get asked.
The internet holds 500-question JavaScript dumps nobody can absorb - and interviews keep recycling the same dozen topics anyway. Here are those twelve, with the answers interviewers actually want, why each survives in the AI era, and how the live round probes it. Learn these deeply rather than skimming five hundred shallowly; the follow-up question is where the difference shows.
Before the questions, understand the format they arrive in, because it changed. Memorise-and-recite rounds are fading - AI made recall cheap, and employers responded by moving the test into the room, as we map in the full 2026 interview guide. The same twelve topics below now get probed three ways: explain it (in your own words, ideally connected to your own projects), apply it live (a tiny typed exercise while you narrate), and increasingly judge it(review a snippet - often AI-generated - and find what’s wrong). Prepare all three modes for each topic and the interview holds no surprises; prepare only recitation and the second follow-up question ends the round.
The twelve questions
1. What is the difference between let, const, and var?
var is function-scoped, hoisted with an undefined value, and re-declarable - the legacy behaviour behind many old bugs. let and const are block-scoped and cannot be accessed before their declaration. const prevents reassignment of the binding (though object contents can still change). The answer interviewers want beyond the definitions: "I default to const, use let when reassignment is genuinely needed, and never use var" - because it shows you understand the WHY (smaller scopes and immutability-by-default prevent whole bug classes), not just the trivia.
2. Explain how closures work - and give a real use case.
A closure is a function that keeps access to the variables of the scope where it was created, even after that scope has finished running. The classic real uses: private state (a counter function that remembers its count without a global variable), function factories (makeFormatter("MYR") returning a currency-specific function), and callbacks that remember context. Interviewers ask this because closures are everywhere in real JavaScript - every event handler and every React hook leans on them - and candidates who can only recite the definition but not point to one in their own project code reveal exactly the gap the question exists to find.
closure.js - the counter every interviewer knows
functionmakeCounter() {
letcount = 0// private - only the returned function sees itreturnfunction () {
count = count + 1returncount
}
}
constnext = makeCounter()
next() // 1next() // 2 - the closure "remembers" count between calls
3. What does "asynchronous" mean in JavaScript, and how do promises and async/await relate?
JavaScript runs on one thread, so slow operations (network calls, timers) are handed off and their results handled later via the event loop, instead of blocking everything. Promises are objects representing those eventual results, with .then/.catch chaining; async/await is syntax over promises that lets asynchronous code read like synchronous code, with try/catch for errors. The strong answer connects them: "await pauses the function, not the browser - other code keeps running". Expect the live follow-up: "what happens if you forget await?" (you get a pending promise instead of the value - a bug every interviewer has watched juniors create in real time).
missing-await.js - the live-round bug hunt
// The classic live-round follow-up: spot the missing awaitasyncfunctiongetPrice(item) {
constres = fetch('/api/price?item=' + item) // BUG: missing awaitconstdata = awaitres.json() // crashes - res is a Promisereturndata.price
}
4. What is the difference between == and ===?
== compares after type coercion ("5" == 5 is true), === compares value and type with no coercion ("5" === 5 is false). The answer that scores: always use === (and !==), because coercion rules are full of surprises (0 == "" is true, null == undefined is true) and the strict version makes intent explicit. This is a screening question - missing it suggests you have not written much real JavaScript - so answer it fast and confidently, and mention a coercion gotcha to show depth.
5. How do map, filter, and reduce differ - and when would you use each?
All three iterate arrays without mutation. map transforms every element one-to-one (prices to formatted strings), filter keeps elements passing a test (orders above RM 100), reduce collapses the array into one value (a total, or a grouped object). The strong answer includes judgement: chains of map/filter read clearly; a gnarly multi-purpose reduce is often less readable than a plain loop, and knowing when NOT to be clever is the senior signal. Interviewers frequently follow with a tiny live exercise ("sum the prices of in-stock items"), so be ready to type one, not just describe one.
6. What is the "this" keyword, and why does it confuse people?
this refers to the object a function is called ON - it is bound at call time, not where the function is written, which is exactly why it confuses people: the same function can have different this values depending on how it is invoked. Arrow functions do not have their own this; they inherit it from the surrounding scope, which is why they became the default for callbacks. A practical answer beats an academic one: "I use arrow functions for callbacks so this behaves predictably, and I know method shorthand on objects when I need dynamic this." Deep rabbit holes (bind/call/apply) come up mainly at stronger mid-level interviews.
7. What happens when you type a URL and press Enter? (the JavaScript-relevant part)
The browser fetches HTML, parses it, requests linked assets, builds the DOM, and executes JavaScript as it arrives - scripts can block parsing, which is why modern apps defer or module-load them. Then the framework (React et al.) takes over rendering. Interviewers use this classic to test whether you see the whole pipeline your code lives in - a candidate who knows their JavaScript runs inside parsing, rendering, and network realities debugs real problems ("why is this page slow?") far better than one who has only seen code inside a sandbox.
8. How does JavaScript handle errors, and how do you handle them in async code?
Synchronous code uses try/catch; promises use .catch; async/await brings try/catch back for asynchronous flows, which is one of its main readability wins. The answer that separates juniors: mention what you DO with the error - user-facing fallback, logged context, retry where sensible - because catching and ignoring is worse than not catching. Interviewers often probe with "where would an error in this fetch call end up?" against a snippet; trace it calmly: no catch means an unhandled rejection, and you say so.
9. What is the DOM, and what does it mean to "manipulate" it?
The DOM is the browser’s live object representation of the page - a tree of nodes JavaScript can read and change: create elements, update text, toggle classes, attach event listeners. Frameworks like React are, underneath, sophisticated DOM-manipulation machines that batch and minimise updates. The question checks that framework users understand the layer their framework abstracts - interviewers report that candidates who have ONLY seen React often cannot explain what it is doing for them, and that gap shows up the first time a real DOM problem (focus, scroll, third-party embeds) appears.
10. Explain event delegation and why it is useful.
Events in the browser bubble up from the element where they happen through its ancestors. Event delegation attaches ONE listener on a parent and inspects which child was actually clicked - instead of attaching hundreds of listeners to hundreds of rows. Useful for performance and for elements added dynamically after page load. This is a classic "have you actually built things" question: anyone who has made a list interactive has met the problem it solves, and the answer naturally includes event.target - which is the detail interviewers listen for.
11. What are the common ways to avoid mutating state, and why does immutability matter?
Spread syntax ({...obj}, [...arr]), array methods that return new arrays (map, filter, slice), and structured cloning for deep copies. Immutability matters because shared mutable state is the root of a huge class of bugs - and because frameworks like React detect changes by comparing references, so mutating an object in place can silently break re-rendering. The strong answer includes that React detail: it converts an abstract principle into a concrete bug you know how to avoid, which is exactly the flavour of understanding 2026 interviews probe for.
12. The AI-era question: an AI assistant wrote this function for you - how do you decide whether to trust it?
The newest fixture in JavaScript interviews, and the one that decides premium-band offers. The winning shape: read it line by line and explain what it does in your own words; check edge cases (empty arrays, null inputs, unexpected types); test it - write two or three quick cases including the ugly ones; and check fit - naming conventions, error-handling style, whether it duplicates an existing utility. Then say the honest sentence interviewers are listening for: "the AI drafts, but the pull request has my name on it, so nothing goes in that I can’t explain." That single answer demonstrates the direct-and-judge capability the RM 6,000-9,000 AI-capable band actually pays for.
How to prepare these (the week-before plan)
Connect every topic to your own projects first- the strongest possible answer to “explain closures” is “here’s where one bit me in my booking app”, because it simultaneously proves understanding and authenticates your portfolio (interviewers increasingly use fundamentals questions to verify the portfolio is really yours - the dynamic covered in the portfolio guide). Drill aloud, daily: one topic per day, empty editor, tiny example typed while narrating - the live round tests speaking-while-coding, which is a separate, fast-training skill. And practise the judge mode:have an AI assistant generate small functions and review them critically - find the edge case it missed, say why aloud. That drill is simultaneously question-12 preparation and the daily shape of the actual job you’re interviewing for.
If working through these twelve exposed real gaps rather than rusty phrasing, that’s useful information: the gap is fundamentals, not interview technique, and the fix is building - not more question dumps. The free trial rebuilds exactly this foundation through six real projects with a live instructor session - one signup, no card - and the full path from fundamentals to the RM 6,000–9,000 AI-capable band is mapped in the AI-native developer path.
FAQ
How many JavaScript questions should I prepare for an interview?
Depth beats coverage. The twelve on this page cover what Malaysian and remote junior interviews actually recycle - variables and scope, closures, async, array methods, this, the DOM, errors, immutability, and the AI-collaboration probe. Preparing those twelve deeply (able to explain, type a live example, and connect each to your own projects) outperforms skimming a 100-question dump, because 2026 interviews follow up live: the second question about any topic is where memorised answers collapse and understood ones compound.
Do interviewers still ask JavaScript trivia in the AI era?
Less than before, and differently. Pure recall trivia declined - AI made recall cheap, and employers know it. What replaced it: the same topics probed through explanation and live application ("use a closure to build X while we watch") plus the new AI-collaboration layer ("here is AI-generated code - review it aloud"). The topics on this page survived the transition precisely because they test understanding rather than memory: you cannot fake your way through explaining why a stale closure broke your own project.
Should I learn JavaScript or TypeScript for interviews?
JavaScript first - every TypeScript question is a JavaScript question underneath, and the concepts on this page are the shared core. But expect TypeScript in the job itself: the Malaysian and remote market has largely standardised on it, and mid-level interviews probe typing habits. The efficient path: learn JavaScript fundamentals deeply, adopt TypeScript early in project work (it is the stack our own programme teaches), and by interview time you can answer in either - which itself reads as a professional signal.
How do I practise for the live-coding part?
Practise the performance, not just the material: the live round tests speaking-while-typing, which is its own trainable skill. The drill that works: pick one question from this page daily, open an empty editor, and solve a tiny version aloud as if an interviewer were watching - narrating your thinking, including the dead ends. Then do 2-3 mock interviews with a mentor or study partner before any real one. Our programme formalises exactly this as defence interviews, because the market tests it; the free trial’s live instructor session is a zero-cost first taste of explaining your code to a professional.
Twelve topics. Three modes. One foundation. Interview answers are built, not memorised.
If these questions exposed gaps, the fix is building - six real projects and a live instructor session, free. The fundamentals that answer interviews are the same ones that do the job.
