Answering tricky interview JS Questions

If any of you have ever applied to a Javascript Front-End position, you may have been asked questions that look taken out of a university degree context. Many of us have not studied javascript on a theoretical level, but actually started to learn by plunging into the code, so many of these questions could be hard to get even for the most senior profiles. ¿Why do they ask them, you may think? In my opinion it's a bit pointless. For instance at an interview at toptal (that I failed - I'm not ashamed to admit it :-P) I was asked very basic questions like to tell the difference between merge sort and quick sort, or how to order an array of numbers  in a certain way.

In any case, finding out most of these answers would take anything between 5 and 30 minutes of researching in Google trying to figure out the correct answer.  Many may think that these sort of questioning are a bit pointless, at least regarding programming skills. One may argue however that the point of it is to see how much effort the programmer is willing to put to a task.

In any case, this is a small comprendum of the sort of questions you may find in a Javascript Interview. Tricky Javascript questions. These are several basic JS questions that I couldn't answer.  (I'm probably not alone).

JS event listeners fire not only on a single DOM element, but in all of it's descending items.

Inverse of this. Also known as propagation, events on an element will "bubble up" and also fire on all parents.

The latter is the element with the listener attached, the former is the actual element that triggered it. Current target is what you attached the listener to, target is what fired the event.

I had no idea of what an IIFE was. IIFE is "Immediately invoked function expression". If you run this code in your browser it will say "Syntax Error: expected expression, got)".  The idea is I write this function and then I run it. But that way will not work, and you will not be able to do it is because of the difference between writing a function as an statement (or definition) and writing it as an expression.

In Javascript, expressions resolve in a value. This means that if you create a variable and you assign to it a value, that will be an expression itself and will resolve into a value. This value is more like a reference (for the code builder) rather than a  value itself.

If you write this code, what Javascript will understand is that first you are defining a function, and then you are just writing (); , which for Javascript doesn't make any sense.

You can make that function an expression by just putting the function code into parenthesis.  And that's what you call an immediate invokable function expression.

That makes us wonder Why would I ever use one? And you have a point, if you are going to be building things with javascript frameworks, then you are probably never going to find yourself in a situation where you might need to know this.

This is more a question to make sure that you understand the concept of what javascript does and how it compiles, and to prove that you know about variable domains.

Because you can't predict the future.  This sort of practice reduces collisions, it maintains independence and it makes writing your own code easier.

All variables are declared using var at the top of any given function scope whether you really like it or not (including function declarations). The following code will throw "action" is already defined on line 6

What javscript is doing, is getting the initial var action in line 3 and moving it all the way to the top to line 2.Try to declare variables as close to their scopes as possible to improve global performance of your application. 

Remember you can always use const and let instead of var, since they are not hoisted, scoped within the block they are in and give you more control of your code.

This one is a bit easier, since it is more related to everyday programming battles, but - however - it could be a bit tricky to explain the difference.

Undeclared is when you try to use a variable that you've never mentioned before. You forgot something somewhere.

Undefined is a bit different. It means that you have declared it but you have not given it any value. It's not always something bad. For instance, a function that doesn't return a value will return undefined. You can check for  undefined using typeof ,or the tripple === equal . something like console.log(foo === undefined); Undefined is a reserved word.

Null is it's own value, and it's value is null. It means "nothing". It's not zero, not an empty string / object / array , and it's value is null (at least in Javascript. In C null resolves to zero).  Null is a reserved word too.

I see many programmers that use === instead of == in many contexts where you don't need it.

What you do with double equals is you check for equality. So if you are comparing two objects that resolve to the same type, == will check to see if they are equal, even though they come from different types of objects that produced the result.

Triple equal checks also to make sure that there is equality AND type.

This post has been inspired and based on Coding Tech's video and Brad Frost's article on "Why I'm not a Javascript developer". Their channel is very cool for app developers and we recommend you to take a look at it. 

Like the original author, I would like to add that maybe after reading this you may seem to feel like a bit overwhelmed by not knowing how to answer these questions. It's ok. There's always so much to learn in computer software development that it's perfectly fine and normal not to know something. Keep moving on. Keep building good software.