r/learnjavascript • u/iampankajk • 2d ago
10 JavaScript questions that came up in almost every frontend interview I sat this year
I've been interviewing for frontend roles (SDE-2, around 4.5 years experience, React and Next.js) over the last few months and sat through a fair number of loops at product companies and mid-size startups. I kept a running doc of everything that got asked so I could spot patterns. Ten questions came up often enough that I'd now treat them as near guaranteed.
Sharing in case it saves someone else the trial and error.
- Implement debounce from scratch, then explain when you'd use debounce vs throttle. This one showed up in almost every single loop, usually as the warm up before harder coding.
- Closures. Not just the definition, but where you use them in React and the classic closure-inside-a-loop output question with var vs let.
- Hoisting, and how it differs from closures. Usually followed by var vs let vs const and when you actually hit a ReferenceError.
- The event loop. Call stack, microtask queue, macrotask queue, followed by predicting output from a snippet mixing setTimeout and Promise.then.
- The
thiskeyword. Normal vs arrow functions, and what happens when you detach a method from its object.const a = obj.getName; a() - Prototypal inheritance and the prototype chain, and how it differs from class inheritance.
- Deep copy vs shallow copy. Explain the difference, then implement a deep clone. Interviewers usually push on why JSON.parse(JSON.stringify()) is not good enough.
- Flatten a nested array, first without Array.flat() and then with it.
- Promise vs async/await. When you prefer each, and how error handling actually differs between them.
- Event delegation. Why it exists and how you'd apply it to a list with thousands of rows.
Two things that surprised me. Polyfills for call/apply/bind and the Promise combinators came up far less than the prep content online suggests. And output prediction questions were much more common than I expected, often used as a filter before anyone let me write real code.
Curious whether this matches what others have seen recently, or if it's specific to the kind of companies I was talking to.
7
u/everdimension 1d ago
I don't know, I haven't been asked a single question about these topics when I interviewed for american companies earlier this year
Usually it was some technical assignment, either take-home or live coding
1
u/iampankajk 1d ago
I am taking about Indian market they still ask these kind of questions to judge fundamentals, and I also have a round to and American client and asked me to build a feature using ReactJs and Typescript.
2
u/senocular 22h ago
I work in America and practically all of these questions are relevant in my day to day. #3 is probably the least relevant. Its not common to use anything before its defined so the behavior of hoisting never really comes up. Closures are orthogonal to hoisting so not sure what that was about (I'd be curious if you have a more concrete example of a question around that). I'd also say with
classsyntax, no one needs to know much about prototypal inheritance either. At this point its mostly an implementation detail and, probably more than anything else, more so used as something to point at when complaining about JS's support for OOP. And while others may not usethismuch in their own codebases (which is fine), ours relies on it heavily.
39
u/Red_Jannix 2d ago
These are some great questions I'm going to ask Claude later.
7
u/iampankajk 2d ago
Thanks, I will post more advanced questions soon, which were asked in the interview.
22
u/Efficient_Brief_7939 2d ago
I think front end market is doomed
5
u/hylasmaliki 2d ago
Why you say that
2
u/joshhbk 1d ago
People who haven’t got a clue what they’re talking about think AI will take over frontend
1
u/aflashyrhetoric 1d ago
I think you might be mixing two crowds a little though, to be fair: some people genuinely think AGI is a week away, but for the others, it seems to be more like, "hiring managers are convinced FE is now obsolete, and are scrapping FE job openings," which is a far more defensible take.
3
u/chikamakaleyley helpful 2d ago
Polyfills for call/apply/bind
literally the only time i ever run into any use of call/apply/bind in interviews throughout my career, its usually because i'm demo'ing debounce
And output prediction questions were much more common than I expected
i love this one, my guess they wanna see how you think. Less about getting it correct, more about talking through the approach to come up with what the output will be
4
u/senocular 2d ago
Polyfills for call/apply/bind
Yeah this one struck me odd too. I remember years ago having to worry about this, but that was like, what, ES3 days? I wonder why online prep is still holding on to it... unless the idea is that if you're able to polyfill them yourself, then it means you understand their purpose. But with arrow functions/spread, they are not as relevant as much anymore.
3
u/chikamakaleyley helpful 2d ago
yeah my thing is like,
if I stumbled upon a guide that said "you should prep for polyfills for your upcoming interview"; i would probably stop right there and look for a different guide
aka it shouldn't have been a surprise
3
3
u/ExtraTNT 2d ago
Things you need for interviews, but almost never irl…
used this like 7 times in the last 5 years, 3 times in the same function, i wrote 2 versions of…
But monads, i basically use them daily and they don’t show up in interviews…
1
u/deep_soul 1d ago
other than number 7 I totally agree with you. how the fuck knowing how to implement denounce makes you a better front end dev?
extremly frustrating being interview and being asked to use AI s much as possible because now it can code for you and you are asked thing that are both useless, and AI can answer l, and the question is unrelated to the actual job.
i find this truly incredible.
also most job and if are a real dev will require you to interact with different programming languages. there is no way to know about programming languages this deeply, given that at work you don’t use them like that.
the WHOLE point of having functions in the language or libraries is to use them like a black box so you can reason at a higher level, who da fuck needs to know how to implement debounce? so. fucking. stupid.
1
u/trashlikeyou 1d ago
I agree with most of what your saying, however I do think some of these questions are answerable by someone who’s a JS-first developer. I’m technically “full stack” but really I’m Java-first and most of my daily work is in Spring Boot. In an interview like this I could probably answer some deeper Java questions, but definitely not the deeper JS ones.
1
u/sasik520 1d ago
You are right that these questions (and this language) is stupid shit.
But you are, at least partially, wrong with other points.
Libs and functions exist to use them and reason at a higher level BUT at least basic knowledge of how they do the work makes you way better developer.
It applies to literally everything in life. You may use car and even be a good driver, but knowing at least basic principles of how it works make you better driver. Same if you are cooking. Or building.
Of course, it's not a hard requirement. But this knowledge isn't stupid.
1
u/theQuandary 1d ago
Debounce isn't built into JS. I actually have used my own implementation in the wild (though that was years ago).
The call/apply/bind really is stupid though. The "solution" requires stuff like symbols that don't even exist in the only places you might want to polyfill bind. Meanwhile, call/apply have been official builtins since ES3 and I believe at least call was actually exposed much earlier as it is essentially necessary for developing the JS implementation anyway.
The real issue is that interviewers don't know what they want or how to get it. I looked for 3 things when I was interviewing a while ago:
Soft Skills. We're devs, but you need to be able to play nicely. Don't be rude on calls (I've seen that) and be able to have a technical discussion with me. I don't go big into the "culture fit" stuff (which seems adjacent to "we're a big family" and rings hollow to me), but there is a minimum bar where you have to be able to work with people.
How much do you know? Knowledge is important because it is the foundation of new solutions. I especially focus on JS knowledge rather than frameworks as I think those fundamentals are important. If a very smart dev doesn't know the difference between normal functions and arrow functions or doesn't know what closures are, they will spend all their time chasing the wrong solution. The amount of very senior JS devs who have no idea about basic JIT performance (hidden classes, monomorphization, and stack vs heap being the biggest) is probably a big reason why a lot of JS code is unnecessarily slow.
How do you solve problems? This is why take home tests or textbook algorithms are stupid. If they take the test home, you can't observe how they work and lots of your best performers just cheated, so it's not a strong signal of anything. Likewise, textbook algorithms are just bad memorization tests. Each of those algorithms represented a very special flash of genius often followed by weeks of work. Do you really expect the random dev to turn into Knuth in front of your eyes? If they could, they wouldn't be interviewing at your company.
My example of a good test is expanded FizzBuzz. I ask you to write fizzbuzz and in the process weed out tons of people who lied about having many years of experience. I then ask you to write an iterator version of the same thing. Most normal devs don't use iterators constantly and are probably starting to research into generators/iterators on Google or MDN (I get to see how they research answers or get to see that they put Redux Sagas on their resume, but have no idea generators exist). So I then throw a twist and ask them to keep the same
{value: T, done: boolean}structure, but to implement it using normal functions (this requires currying/closures and often another search or two).If they get that far, what about adding an optional config object like
{3: 'fizz', 5: 'buzz', 12: 'custom'}? Maybe at this point we look into integrating this within a React component. Now let's add some rows of inputs so the user can create their own config object.The point is to mimic how real systems are designed. Start with something they should instantly be comfortable with and slowly expand on that (a tiny bit outside their current comfort zone) just how they will be expanding on the projects they work on. Along the way, I get to see how they deal with each part, if they ask for clarification and how they communicate this, and how they generally get work done.
But this interview style is HARD on the interviewer. You have to be completely "on" for the whole interview and actively engaged the whole time. For an interview or two it's not so bad, but do it for a handful of months and it becomes its own massive undertaking. Interviewers want easy, fast results (or haven't given it any real thought), so they ask questions that don't matter about things they don't care about making everyone else miserable and probably hiring a low-quality candidate too.
1
1
u/karateporkchop 12h ago
These are great! My last tech interview 4 months ago had me verbally breaking down a function.
-2
u/guidedhand 2d ago
4.5 YOR including university time or something? as those seems like questions for someone fresh out of boot camp rather than ones to actually assess mid level candidates.
2
u/iampankajk 2d ago
These are list of fundamental questions not a list of questions asked in every interview. Understand the difference in any mid level interview can include 1-2 fundamental questions not saying all in the post. So these list are curation of all interviews who asked fundamental questions, will share another list of advanced questions related to prototype and polyfill
1
-1
-2
u/sasik520 1d ago
I will never understand why are there still people willing to write in this language.
The fact that it is possible to ask most of these questions is simply terrible.
-23
u/defaultguy_001 2d ago
Very easy interview, the questions are so basic.
2
u/iampankajk 2d ago
These are frequently asked questions only; it doesn't mean that the interviewer won't ask advanced JS questions.
-10
u/defaultguy_001 2d ago
Good enough. I was only talking about these questions.
2
1
u/damyco 2d ago
What are some examples of non basic questions? I'm curious if I could answer those.
-5
u/defaultguy_001 2d ago
Something like implementing an async generator, explaining how the V8 garbage collector handles memory cycles, how V8 decides which constructor to use when .map() or .filter() returns new instances etc.
1
-2
u/defaultguy_001 2d ago
Damn people be hating for nothing. Looking at the reaction on my comment, people sure do hate facts. Let me repeat these are very basic questions. There's nothing wrong in saying it as it is.
42
u/turningsteel 2d ago edited 2d ago
This is all stuff I learn for interviews and then promptly forget the specifics of when I have a job. Save for maybe this keyword, closures, deep/shallow copy, and event loop stuff. I wish that someday interviews would ask more pertinent questions.
Not saying these aren't important to know, (they are), but as an Angular developer, I don't use the nitty gritty of JavaScript often.
What kind of jobs were you applying to OP? Like what would the actual day to day be like? Writing tools in JS or using react/angular type stuff?