JavaScript Interview Questions for Freshers

“JavaScript has seven primitive types: string, number, bigint, boolean, undefined, symbol and null. Primitives are single values that can't be changed in place, so any string method gives me a new string. Everything else is an object, and that includes arrays, functions and dates. The typeof operator has a few surprises. typeof null returns object, which is an old bug the language kept so it wouldn't break existing sites. An array also comes back as object, so to check for an array I use Array.isArray. A function is the one object that gets its own answer, function. So when I need to tell these apart, I check null with triple equals first, then use Array.isArray, and only then fall back to typeof.”

“undefined is what JavaScript gives me by default. If I declare a variable and don't assign it, read a property that doesn't exist, or call a function that has no return, I get undefined. null is different because I set it myself, on purpose, to say there's no value here, like clearing the selected item in a list. Not defined isn't a value at all, it's a ReferenceError. It means I used a name that was never declared, and it's often just a typo. For comparisons, null double-equals undefined is true, but with triple equals it's false. So when I want to check for both at once, I either write value == null with a short comment, or use the nullish operator.”

“There's a short list of falsy values: false, zero, negative zero, the bigint zero, the empty string, null, undefined and NaN. Everything else is truthy. So an empty array passes an if check, and so does an empty object, and so do the strings zero and false, because they're non-empty strings. Where this bites people is a check like if (count) when zero is a valid count, or if (name) when an empty string should be allowed. In those cases I check exactly what I mean, like count !== undefined, or items.length > 0 when I want to know if an array has anything in it. To turn a value into a real boolean I use Boolean(value), which reads more clearly to most teammates than a double exclamation mark.”

“JSON.stringify turns a JavaScript value into a JSON string, which is what I send in a request body or save in localStorage. JSON.parse does the reverse. JSON only knows strings, numbers, booleans, null, arrays and plain objects, so some things don't survive. Functions and properties set to undefined are simply left out of objects. A Date becomes an ISO string, and after parse it stays a string, not a Date, so I have to convert it back myself. NaN and Infinity become null. On the parse side, JSON is stricter than JavaScript: keys need double quotes and trailing commas aren't allowed, and bad input throws a SyntaxError. So when I parse anything from outside, like a stored value or a server reply, I wrap it in try and catch.”

“NaN stands for not a number, but funnily enough typeof NaN is number. It's what I get when a calculation can't produce a real number, like multiplying a word by two, or calling Number on text such as twelve px. The rule is that NaN isn't equal to anything, not even itself, so a triple-equals check never finds it. The proper check is Number.isNaN. There's also an older global isNaN, but it converts the value to a number first, so isNaN('hello') returns true even though that's a string, not NaN. In a form, I'd convert the input with Number, then use Number.isNaN to show an error before the bad value spreads into a total and turns everything it touches into NaN.”

“All numbers in JavaScript are 64-bit floating point, stored in binary. Just like one third can't be written exactly in decimal, 0.1 and 0.2 can't be written exactly in binary, so each is stored as the closest value, and the tiny errors add up. The sum comes out as 0.30000000000000004, so a triple-equals check fails. It isn't a JavaScript bug; other languages using the same number format do exactly the same. To compare, I check that the difference is smaller than a small tolerance, like Number.EPSILON for values around one. For showing a result I round with toFixed, keeping in mind it returns a string. And for prices, I'd do the maths in whole cents as integers, so nothing needs rounding until I display it.”

“With a number or a string, the function gets its own copy of the value, so whatever I do inside stays inside. With an object or an array it's more subtle. The variable holds a reference, and the function gets a copy of that reference. So the caller and the function both point at the same object. If I change a property, or push into the array, the caller sees it. But if I reassign the parameter to a brand new object, that only changes the function's local name, and the caller still has the original. That's why people call it pass by sharing. In practice I try not to surprise callers: if a function needs a changed version, I return a new object built with spread instead of editing the one passed in.”

“A callback is just a function I hand to another function so it can call it for me. Functions are values in JavaScript, so I can pass them around like anything else. Some callbacks run right away. When I call sort with a comparator like (a, b) => a - b, sort calls it many times before it returns. That comparator matters, because sort without one compares items as strings, so ten comes before two. Other callbacks run later. With setTimeout or a click listener, my function is stored and called after the current code finishes, when the timer fires or the user clicks. When several async steps depend on each other, those callbacks nest deeper and deeper, and handling errors gets messy. That's the problem promises and async/await were built to fix.”

“The same three dots do two opposite jobs depending on where they sit. Spread expands things: Math.max(...nums) passes each number as its own argument, and { ...user, role: 'admin' } copies an object and overrides one field. Rest collects things: in a function's parameters, ...rest gathers every extra argument into a real array, and in destructuring it gathers whatever I didn't name. Destructuring itself is a short way to pull values out, by position for arrays and by name for objects. I can give a default, like pages = 100, but it only applies when the value is undefined, not when it's null. A neat trick it enables is swapping two variables in one line without a temporary variable.”

“Optional chaining, the question mark dot, lets me read deep into an object without crashing. user?.address?.city gives me undefined if user or address is missing, instead of throwing 'cannot read properties of undefined'. It works for calls too, like onDone?.(). The double question mark is nullish coalescing: it uses the right side only when the left side is null or undefined. That's the difference from the OR operator, which falls back on any falsy value. So if a user sets the volume to zero, volume || 10 quietly turns it back into ten, which is a bug, while volume ?? 10 keeps the zero. One caution: I don't sprinkle question mark dots everywhere, because if a value should always exist, I'd rather get a clear error than hide a real problem.”

“for...in walks over keys. On an object it gives me each enumerable property name, and it also includes properties inherited through the prototype, which is a surprise if a library added one. On an array it gives me the indexes, but as strings, and it'll also pick up any extra property someone attached to the array. for...of walks over the values of anything iterable: arrays, strings, Maps and Sets. So for an array I use for...of, or a normal for loop if I need the index. A plain object isn't iterable, so for...of on it throws a TypeError. For objects I use Object.entries with for...of and destructure the key and the value, which also gives me only the object's own properties.”

“Strict mode is an opt-in that makes JavaScript less forgiving. I turn it on with the string 'use strict' at the top of a file or a function, though ES modules and class bodies are strict automatically. The biggest change is that assigning to a variable I never declared throws a ReferenceError. Without it, a typo like totl = 5 silently creates a global variable, which is a nasty bug to find later. Second, inside a plain function call, this is undefined instead of the global object, so a mistake fails loudly instead of quietly changing global state. It also throws when I write to a read-only property, and it bans duplicate parameter names. I like it because it turns silent mistakes into clear errors early.”

“I'd write an async function that awaits fetch with the URL. That gives me a Response object as soon as the server answers. The part beginners miss is that fetch only rejects when the request can't complete at all, like the network being down. A 404 or a 500 still resolves normally, so I check res.ok and throw my own error if it's false. Then I await res.json(), which is a second promise because the body arrives after the headers. I wrap it all in try and catch, so a failure shows a friendly message instead of a blank page. I put the data on the page with textContent, not innerHTML, so text from the server can't run as code. In my project I also showed a loading message while waiting.”

“setTimeout works with a callback, so I wrap it in a promise. The sleep function takes milliseconds and returns a new Promise, and inside it I call setTimeout with resolve as the callback, so the promise settles once the time is up. Then I write an async function with a plain for loop from one to three. Each time round, it awaits sleep of a thousand milliseconds, then logs the number. The key detail is using for or for...of, not forEach. forEach doesn't wait for promises, so with an async callback all three timers would start together and the numbers would print at almost the same moment after one second. Sleep never rejects, so I don't need a catch here, but with real network calls in the loop I'd add one.”

“The DOM is the tree of objects the browser builds from the HTML. Each tag becomes a node, and JavaScript can read it, change it, add to it or remove from it, and the page updates. To find elements I mostly use querySelector with a CSS selector, which gives me the first match or null, and querySelectorAll, which gives me a NodeList of all matches. getElementById still works and is fine for one element by id. To change text I set textContent. innerHTML parses whatever I give it as HTML, so if that string came from a user, like a comment box, someone could inject an image tag with an onerror handler and run their own script. That's cross-site scripting. So user text goes in textContent, and I only use innerHTML with markup I control.”

“The browser reads HTML from top to bottom, and a normal script tag pauses parsing and runs straight away. If my script is in the head, it runs before the body has been read, so the button doesn't exist yet and querySelector returns null. Then calling addEventListener on null throws. The cleanest fix is the defer attribute: the script downloads in parallel but runs only after the document is parsed, and deferred scripts keep their order. Other options are moving the script to the end of the body, or wrapping the code in a DOMContentLoaded listener. The async attribute is different: it runs as soon as it's downloaded, so it could still run too early. And before blaming timing, I'd check the selector itself, like a missing hash or a typo in the id.”

“All three keep data in the browser, but they behave differently. localStorage keeps data until someone clears it, and every tab from the same origin, meaning the same protocol, domain and port, sees it. sessionStorage belongs to one tab and disappears when that tab closes. Cookies are small and, importantly, get sent to the server with every matching request, which is why they're used for login sessions, and the server can mark them HttpOnly so JavaScript can't read them at all. For a theme choice, localStorage is a good fit: it's small, the server doesn't need it and it should survive a restart. Two things I remember: storage only holds strings, so I use JSON.stringify and JSON.parse for objects, and I'm careful with login tokens there, because any script running on the page can read them.”

“First I'd clean the input: lowercase it and remove anything that isn't a letter or a digit with a regular expression, so the car and cat sentence becomes one long lowercase string. The quick version splits it into characters, reverses, joins and compares. It's easy to read but builds a reversed copy. The version I'd write on the board uses two pointers, one at the start and one at the end, moving inward and returning false at the first mismatch. It stops early and needs no reversed copy. I'd mention edge cases out loud: an empty string or a single character counts as a palindrome. And this regex only keeps plain a to z letters, so I'd call that out if the input could contain accented letters.”

“The one-liner is to put the array into a Set, which only keeps unique values, and spread it back into an array. It keeps the first time each value appears, in the original order. Without Set, the classic answer is filter with indexOf, keeping an item only if its first index equals the current index. It's short, but indexOf scans the array each time, so it's O(n squared) and slow on big lists. A better manual version loops once and uses an object as a lookup of values I've already seen, pushing only new ones into the result. That's O(n). I'd also mention that Set compares objects by reference, so two different objects with the same fields would both stay.”

“I'd do it in two passes. In the first, I loop over the string and count each character in a Map, adding one every time I see it. In the second pass, I loop over the string again, in order, and return the first character whose count is exactly one. For 'swiss', s appears three times, w and i once each, and w comes first, so the answer is w. If nothing is unique I return null, and I'd ask the interviewer whether uppercase and lowercase should count as the same letter. It's O(n) time. The common slow approach is nesting two loops to compare every pair, which works but is O(n squared). I use a Map rather than a plain object because it's built for lookups like this and has no inherited keys to worry about.”

“Sorting works but it's O(n log n), and the default sort compares numbers as strings unless I pass a comparator. In one pass, I keep two variables, first and second, both starting at negative infinity. For each number, if it's bigger than first, the old first moves down to second and the number becomes first. Otherwise, if it's smaller than first but bigger than second, it becomes second. Using strictly smaller than first matters: with five, five, three, the second five doesn't overwrite second, so the answer is three, which is usually what's wanted, though I'd confirm it. At the end, if second is still negative infinity, there's no distinct second value, like an array with one element or all the same number, so I return null.”

“Triple equals on objects compares references, so two separate objects with identical content are still not equal. My function starts with a quick check: if the two values are triple-equal, return true. If either one isn't an object, or is null, they can't be deeply equal, so return false. I also return false when one is an array and the other isn't. Then I get both lists of keys with Object.keys. If the counts differ, false. Otherwise, for every key, I check the other object has it as its own key, and call the function again on the two values, stopping at the first mismatch. Arrays work too, because their indexes are keys. I'd tell the interviewer what this skips: Dates, Maps, NaN and objects that refer to themselves.”

“In my final year I built a small expense-splitting web app with two classmates, using plain JavaScript on the front end and a simple Node API. I owned the front end: the form to add expenses, the list and the running balances. The hardest bug was that clicking delete sometimes removed the wrong expense. I stepped through it with breakpoints in the browser dev tools and saw that each delete button remembered its position in the list from when it was first drawn, so after one delete the positions shifted. I fixed it by giving every expense an id, storing it on the button in a data attribute and deleting by id instead. Looking back, I'd write a few small tests for the balance maths, because I checked those by hand every time.”

“I wouldn't rip it out or make a fuss in the group chat. First I'd sit down with my teammate and read it together, stepping through it in the browser dev tools if that helps, until at least one of us can explain every line. Working code that nobody understands is a risk. If it breaks the night before the demo, nobody can fix it, and the examiner might ask any of us how it works. I'd also check a few basics: does it put user input into innerHTML, does it create global variables, and are we allowed to reuse it under the source's licence and our course rules. If it passes, we add a short comment saying what it does and where it came from. If it's too tangled, I'd suggest we rewrite just the part we need, smaller and in our own style.”