DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 968,873 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Junaid
Junaid

Posted on • Updated on

Interview questions for JS

Javascript Interview Questions

Javascipt is a great language and i believe every web developer in todays world should definitely learn it.

Not is it just awesome but also by just learning and understanding javascript you will be able to learn and use so many great frameworks that are buzzing in current job market
like React , Angular , Next JS etc.

So this is a gist of some of the questions and concepts that i have came across in my interview for some product based startups.

Basics

Basics of javascript should be clear very much , Things like arrays , objects , variables etc should be very clear before even you think of applying at any job as a js dev.

Arrays

Arrays are very important and since you will be using them so much in your day to day use case as being a web dev you should definitely learn all the things that can be done in js for arrays like
* Push
* pop
* shift
* unshift
also you should learn how we iterate over arrays

Also learn these :-
* Slice
* Splice

Objects

Every developer in his day to day life will definitely come across objects while working on a javascript project .
So every interviewer expects you know the basics of Objects.

Try to understand them and apply them in any of your projects.

Objects will also be used while you work on things like json all that is is a big blob of object so you have to work with them .

So try to understand all related topics to objects
Things like how we add an item to an object

  • How to iterate through an object
  • How can we delete an item from an object

Try to also learn things like object.keys , object.freeze etc.

More Good Topics

Every interviewer will ask you questions related to these questions so its very necessary that you know these concepts and can explain them in detail

  1. Whats Execution context in js.
  2. Whats a promise and how to create one .
  3. What are callbacks
  4. whats async/await used for
  5. Difference between == and ===
  6. whats call , apply and bind .
  7. Difference between simple functions and arrow functions
  8. Whats 'this' in javascript
  9. What are closures
  10. whats memoization
  11. what is an IIFE(Immediately Invoked Function Expression).
  12. Difference between let and Var.
  13. Different stages of a promise.
  14. Difference between setTimeout and setInterval

There are other topics also which you should give a good go before going for the interview , not everyone will ask you these but its good to know them

  1. Whats prototype and prototypal inheritance
  2. what are anonymous functions
  3. Event bubbling and how do you prevent that.
  4. Whats promise.all
  5. whats a polyfill.

There are many many topics in javascript that you would to know but for a fresher js or even for 1+ year of experience these are the most asked questions .
You can also checkout the greats series by Akshay Saini which explains all the javascript concepts in great detail.

All right , i guess this will be hopefully helpful for any one out there .

Feel free to reach out to me for any thing over email
junaid shah

Top comments (31)

Collapse
 
lukeshiru profile image
Luke Shiru

My main question is how much value would you get from questions like those, that anyone can just google?

From my point of view, you get 0 value of questions like that. It's more important to get to actually know the developer in an interview, talk about past projects, how do they keep up to date, figure out how easy is for them to learn new stuff, and so on. Companies asking stuff like the questions above are basically giving you red flags, just keep your interview short and look for a better company.

Cheers!


PS: My answers, just for the lolz
  1. Whats execution context in JS? The "environment" around your code currently running.
  2. Whats a promise and how to create one? Is a way of dealing with async code. new Promise((resolve, reject) => { /* Do something with that */ }).
  3. What are callbacks? Functions passed to functions. Also used sometimes to deal with async code.
  4. What's async/await used for? Sugar on top of promises for folks that don't fully understand async code.
  5. Difference between == and ===? The first one you should avoid, the second you should use to compare stuff.
  6. whats call, apply and bind? Ways of calling functions that are more annoying than just using ().
  7. Difference between simple functions and arrow functions: Arrow functions rock and simple functions are for boomers.
  8. What's 'this' in javascript? A refactor waiting to happen.
  9. What are closures? What you should use instead of classes.
  10. What's memoization? Save output of expensive functions to avoid having to run them more than necessary.
  11. What is an IIFE(Immediately Invoked Function Expression)? (()=>console.log("this is"))().
  12. Difference between let and var? let is for the cool kids and var is for boomers.
  13. Different stages of a promise: Pending and fulfiled or rejected.
  14. Difference between setTimeout and setInterval: One runs the code once, the other runs it constantly, both suck compared to rAF if you are using it for animations or other UI stuff.
  15. What's prototype and prototypal inheritance? Another refactor waiting to happen.
  16. What are anonymous functions? ()=>console.log("this is").
  17. Event bubbling and how do you prevent that: Event of an element goes up like a bubble. event.stopPropagation().
  18. What's Promise.all? Something that some folks that love async/await don't even know.
  19. What's a polyfill? Old code to make new stuff run.



Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
lukeshiru profile image
Luke Shiru

If you measure the value of a dev with this "exam" format, you aren't getting any useful information out of the interview other than the capacity of the candidate of memorize definitions and concepts, or their capacity of googling without you noticing.
There are way better ways of actually getting value of an interview than this type of questions :/

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
lukeshiru profile image
Luke Shiru • Edited on

You're just wrong. If you want to actually check if they know what a promise is, you don't ask for the definition, you ask about issues they had in the past with promises and how they solve them, you ask about common issues and how they would solve those, you give them actual async problems in a sandbox to code, you ask about what they like or not like about promises, libraries that they used that implement them, and so on. A definition that you can google in 1 minute don't tell you anything useful about the candidate. We need to stop pretending that questions coming from a school exam format are useful in the slightest.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
lukeshiru profile image
Luke Shiru

Is not a high horse, bro. Companies are moving away from questions like this because you end up with a bunch of folks that only know how to answer questions by memory but don't actually know how to do anything. Knowing the definition of something and saying it with confidence only proves that you have memory and charisma, not that you actually know that... really. I can't believe I'm having this discussion in 2021 almost 2022. Good thing is that if you're actually interviewing then several folks dodged a bullet if you gave them the thumb down for not knowing the "correct definitions" :/

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
lukeshiru profile image
Luke Shiru

I interviewed for the last 3 companies I worked for, trust me, we just skip that step because is not useful at all. We value both our time and the time of our candidate, so making them waste it answering questions that show us nothing about the candidate and makes the candidate want to leave, is something we avoid. Just FYI, seniors have to google stuff all the time ...

Collapse
 
oniichan profile image
yoquiale

I call BS. I forget these most of the time because I don't use them even though I learn the concepts over and over.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
lukeshiru profile image
Luke Shiru • Edited on

Using is not the same as knowing the definition. Is not like every time you use an if you think:

Ok, so I need to write a condition that executes a statement if a specified condition is truthy (which means a value that is considered true when encountered in a Boolean context), and if the condition is falsy (which means a value that is considered false when encountered in a Boolean context), another statement can be executed.

You just think:

If this happens, then let's do this, and if not, then let's do that.

Knowing how to do stuff doesn't translate to knowing the "book definition" of something, and viceversa.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
lukeshiru profile image
Luke Shiru • Edited on

The answer for "What's a promise?" is not to write new Promise(..., is:

A proxy for a value not necessarily known when the promise is created. It allows you to associate handlers with an asynchronous action's eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of immediately returning the final value, the asynchronous method returns a promise to supply the value at some point in the future.

You see what I mean now? One thing is asking about syntax, usage, pros and cons, experience, alternatives, etc ... other different and useless thing is to ask for definitions.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
lukeshiru profile image
Luke Shiru • Edited on

That's what I meant in this comment -_- You don't get all that from asking: What is a promise? ... you get that from actually engaging with the candidate in questions such as:

  • Have you worked with Promises?
  • Do you personally prefer the async/await approach or the then/catch? Why?
  • Do you like to work with Promises or do you prefer other approaches? (Such as callbacks or Observables).

You could also just have a problem that includes Promises for the candidate to fix, or that can be fixed with Promises to see how they will solve it. With a "conversation" like that you get way more value from the candidate and you "implicitly" get the answer for "what's a promise" because they have to know what it is to be able to follow that conversation. You can also just stop in the first question if they don't have experience with promises (which would be weird, but maybe they just use async/await without knowing what's below the sugar).


LOL all the comments were deleted. Now I look crazier than usual.

Collapse
 
lucastvms profile image
Lucas Vieira

Then what about developers itself? We can find almost everything that we need in the internet, so the value of a developer is 0? In my opinion knowing these concepts shows that the developer knows more than just "copy and paste" code (what is common even with complete projects).

Collapse
 
lukeshiru profile image
Luke Shiru

The value of a developer goes beyond what you can find on google. More often than not is more important their value as people/teammates. And is funny that you mention "copy and paste" because right now there is kinda a debate in Twitter about that, and I have the same opinion Jake has. If you actually think that the value of a developer is based on if they know from the top of their heads stuff like the above, you and me have very different definitions for the word "developer". I know amazing devs that wouldn't know half of those questions, and pretty bad developers that know everything on that list.

Collapse
 
johandalabacka profile image
Johan Dahl

Sugar on top of promises for folks that don't fully understand async code.

So it’s just something you use until you understand asynchronous code. After that you start to use then() and catch() or callbacks?

Collapse
 
lukeshiru profile image
Luke Shiru • Edited on

Nah, it's just something you use when then and catch are harder to read. Folks not used to async code generally just use async/await because it makes their code easier to read for them.

Collapse
 
__junaidshah profile image
Junaid Author

I definitely understand your point of view here , and i totally agree
Althoughthe inteviewer sometime can ask these questions indirectly rather, they can also give you a challenge and ask can you solve this via lets say a promise based approach etc .

Collapse
 
lukeshiru profile image
Luke Shiru

Having exercises makes a little more sense, but still ideally they should be taken in editors with auto-completion, and evaluate not if the code actually runs or not, but mainly what's the process the dev goes in order to solve that issue. Is way more important to know that. Maybe the candidate says something like "I don't know, I guess I would google this or ask a co-worker" and that's way more valuable that someone that will struggle for hours trying to come up with the solution by themselves.

Collapse
 
soulfiremage profile image
Richard Griffiths

I'd worry about an interviewer who focussed on this kind of thing rather than having a proper conversation about projects past and present, issues they've got and my opinions (in general) around them. I'd want them to find out if I would fit and likely learn what they and their clients need rather than whether I'm the current version of a Javascript language reference.

They should use my project experience to determine whether or not I'm used to using different tools to solve business relevant problems and whether I'd sit and pickle or actually go out and figure out exactly how to solve some awkward requirement.

If they're focussed on whether I know syntactic detail of a specific language, then they are a very junior interviewer and don't actually understand what their team needs.

If your questions are the kind that a few hours of google can answer, then you are thinking, conceptually, at the wrong end of the scale to get anything worthwhile done.

Unless you really really do want someone who just swallowed a javascript book?

Collapse
 
__junaidshah profile image
Junaid Author

Thanks for your valuable comment , richard .
While i totally agree with you but i have been asked these kind of questions many a times while i sat for an entry level dev position .

Collapse
 
soulfiremage profile image
Richard Griffiths

Ah I remember my first entry level too. I guess, being fair, context is everything.

Still, I'd hope a beginner would try to have projects already they can chat about as I'd still be biased against pop quizzes and strongly focussed on whether they would work with us, albeit as a newbie.

Thread Thread
 
__junaidshah profile image
Junaid Author

Absolutely having some good projects takes you a long way .
I remember mine first as well and since i had some projects built i was able to take the interviewer about how i went about creating them and in one of the projects we even discussed what could have improved if i would to optimise it right now ,
So i guess yeah having some projects is quite nice to have , it. shows that you really can do some work on your own and can learn

Collapse
 
theeasydev profile image
Uriel Bitton • Edited on

First of all you will never get questions like this when applying to any job today. They are just way too specific and no interviewer cares to ask you this as you can simply google the answers.

In my experience, interviewers ask two things during interviews. One can be hypothetical questions like "how would authenticate a user in this scenario"? Or "how do you handle login in your app"? And these would be asked in a very general way. They won't ask you to explain how an arrow function works or what a split function does...

The second question could be "say I wanted to remind a user to check their email, how would I achieve that with react/vanilla js/java etc.

In a third likely scenario you could also be asked the classic question "how do you see yourself working with a team of x developers", "would you refactor or continue code that is poorly written as a new team member" Etc.

Knowing basic and advanced js concepts is definitely important and you should master them as much as possible but these specific concepts are ones you need once you do get the job but very rarely during the interview process.

Collapse
 
syeo66 profile image
Red Ochsenbein (he/him)

Actually I got a lot of those questions as a senior developer. And to be frank I found it to be quite insulting. I mean I can write code in at least 10 programming languages. The languages and their special cases usually don't matter much. The concepts at the root (and from a birds eye view) however do matter.

Collapse
 
lexiebkm profile image
Alexander B.K.

"Whats prototype and prototypal inheritance"
This is one of the topics I have been suspending, because I have been busy on trying with a few compiled languages for backend; I will resume on learning this topic in appropriate time. As far as I know, eventhough ES6 provides classes for OOP, javascript OOP is still prototype based.
I think you miss one important thing : strict mode.
For Node.js, it is also important to know Event Loop in addition to promise and async/await.

Collapse
 
__junaidshah profile image
Junaid Author

event loop is definitely a good question and asked many a times

Collapse
 
dmitryame profile image
Dmitry Amelchenko

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.