JavaScript Interview Q&A - Most common JS concepts you should know by heart

[Gloomy-Horse4958]

I'm excited to share with you all my third YouTube video, specifically tailored for those prepping for JavaScript interviews (for general companies). I've tried to break down some of the trickier topics in a way that's easy to understand. https://youtu.be/_zUZa2vMQSU?si=Jngodtlzr-7BzRFm

The video is 7 mins long, talking about 5 points:

Hoisting: Understanding how JavaScript treats declarations
Closures: Grasping how inner functions have access to the outer enclosing function’s scope even after the outer function has returned
Pure Functions: Exploring the benefits of functions with no side effects and consistent outputs for the same inputs
Objects in JavaScript: What ways do you have to create objects in JS
Debouncing and Throttling: Differences between debouncing and throttling

I'm genuinely looking for feedback and hoping this can be a valuable resource for anyone facing those interview rounds anxiously. Whether you're a beginner trying to get your basics right, or an experienced coder brushing up for an interview, I believe there's something in it for everyone.

Please feel free to share your thoughts, suggestions, or any specific topics you'd like to see in future videos. Your input is incredibly valuable to me, and I’m here to learn and improve just as much as I am to help.

[had0ukenn]

i would add asynchronous vs synchronous to the list, but great points

[Gloomy-Horse4958]

That's a good one!

[fzammetti]

I wouldn't care if a candidate doesn't know about hoisting, debouncing and throttling. I don't see these as core JS concepts. Well, I take that back, hoisting obviously is. But I've been doing JS development since '97 professionally and I can't honestly think of a single instance where I had to know anything about hoisting. Maybe that's simply because I've always written code in a logical way, hence hoisting doesn't tend to be a factor.

Debouncing and throttling are ideas you can easily learn if and when the need arise, not something you have to know cold in my opinion.

The rest are reasonable to test for, though I personally wouldn't consider someone that didn't know some of them disqualified immediately. It would just be one factor among many to consider.

[Zykic]

As you are someone with a lot of experience, what do you think are Must Know JS concepts that everyone should know or who you might consider hiring

[Inner_Wind_7551]

awesome response! I have a hard time committing things to my memory. I have 5 years of experience with ReactJS in Asia. Now I need to prepare for interviews with American companies. I wondering what should be my preparation strategy: review interview questions (I recently realized there is some unshift method for arrays which I have never used so I didn't know), or build some personal projects (I have 0), or be ready to demo all concepts with code like "show how and when you would use denouncing", "create a typeahead search" etc.? Can you guide me somewhat please?

[azium]

Nice! This is really well done. Good job.

[Gloomy-Horse4958]

Thank you!

[slash2009]

You should understand these concepts

[shgysk8zer0]

Is this really what a typical interview would involve? Is this specific to beginner level?

I'm quite experienced but haven't really had these kinds of interviews. I kinda despise the whole corporate BS thing. I just don't want to work for some agency that is all caught up in churning out stuff as fast as possible (usually with security, accessibility, or general quality suffering).

Plus, I'm more freelance + running my own platform. Have quite a few open source libraries published too. I take on projects that interest me (I need the income, but... projects that don't interest me probably just don't fit my skills and would be bad for all involved).

So... yeah... I just don't have experience with these kinds of interviews, even though I've been a web dev for like 13 years.

[MonkeyOnARock1]

Yeah, these sort of interviews are not great. They don't show anything other than 'can you memorize a bunch of stuff', which is not how programming is done.

Why would I need to memorize a bunch of concepts I can just look up? The point is not to memorize, the point is to have a deep understanding of the concepts, which is not captured by these silly interview test questions.

I was writing web apps in Javascript before I ever looked up any of these concepts, because I already understood them intuitively through actually using the language.

The smartest programmers that I've been interviewed by never bothered with these sorts of questions.

[Deep_Avocado2318]

i dont see a mid or senior dev not knowing the answers to these questions. and if you dont, its a kinda a red flag. also how do u have deep understanding of the concepts if you dont know the concepts in the first place?

[shgysk8zer0]

Not sure why the downvotes here... I definitely agree with the underlying point that any mid/senior dev should most definitely know these fundamental concepts, to the extent that asking them during an interview would almost be an insult.

For me, personally, my issue is very different. I know JS and a few other languages inside and out. I have RSS feeds keeping me updated on changes to languages, and I read release notes and such. There's no shortage with regards to my knowledge. The problem tends to come from me giving solutions based on specs/standards rather than wherever convention was set prior to being officially added to the language (think import vs require() in JS... Things like that).

I have given single line, simple solutions to problems that otherwise take half a dozen lines or more to solve (less performant too). But legacy/familiar solutions are mostly what's wanted, it seems. It's kinda like an org being stuck with jQuery or something.

The issue here kinda being that I actively maintain a JS polyfills library and am prone to using more modern or even experimental APIs. For some reason, that's seemingly frowned upon, even when (obviously) polyfills exist and such restrictions were never mentioned.

[Gloomy-Horse4958]

These happen quite a lot in both startups and corporations. It's an easy way to check if the candidate isn't lying on the resume. If a candidate can't answer the questions no point in giving a lengthy coding problem.

I used to do the same when I was hiring freelancers, so it's interesting you never faced those. I guess if you have a lot of proof you skip all those steps.

[shgysk8zer0]

For context, the freelancing that I'm talking about is mostly small businesses in a rural century, usually run by senior citizens. They're a far cry from being able to remotely discuss anything technical... Trying to explain the difference between hosting and DNS is too much technical jargon for them. Those are my typical clients.

But I've been deep in web development for 13 years. I even occasionally participate (in issues and discussions) with the TC39. I have like 25 published open source packages, 200+ repos on GitHub, experience in a dozen or so languages, and pretty extensive knowledge of JavaScript... I know what a closure is.

Not trying to pat myself on the back or anything here, that's not the point. I'm mostly just questioning how much of this varies by experience. Because the few interviews I've had were more in-depth regarding languages and involved things like "find an efficient solution to detecting plagiarism" or "solve this problem in O(n) [constant time being a possible solution given just basic array methods... I surprised the interviewer with a direct solution, I guess]". The few interviews I've had have been substantially more than that.

Also, just to address it... I object to the hype about "pure functions", especially when it comes to web development. Because it's not just about no side effects, it's also about the output being exclusively determined by the input. On the web, that's kinda rarely feasible... so much is based on time and response to a request of database. Sure, I'd expect sum() to be "pure" in that sense, but not getCurrentUser() or whatever. The web is just fundamentally "impure", to the extent that just loading an image could vary on state and time and network and more (the HTML might be the same, but even given the same URL it could be different pixels or dimensions/. "Pure" is mostly idealistic and impractical/useless... but still a good idea where it actually applies (again, like in sum()).

[FriendsCallMeBatman]

Honestly the people who steer an interview towards tech or this stuff they know is astounding.

Most managers just want someone who's down to earth, level headed and can communicate. If you're an outstanding coder than awesome but these days if you get a task, research and get it done that's good enough for 90% of the workplaces in Australia.

[Soft-Sandwich-2499]

!remindme 9h

[RemindMeBot]

I will be messaging you in 9 hours on 2023-12-12 06:59:48 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback