Six Things About JavaScript Which If You Don't Know, Signal to Others That You Are Still A Beginner

This is a question I’ve struggled with a lot, while trying to optimise the way I interview people. I don’t want to misjudge people, or evaluate them the wrong way, so I took some time and dug through my head, scoured the Internet for resources and narrowed down to a simple list.

This is not a definitive list, I must state this loud and clear, before you even start reading. None of the points outlined here should be taken in isolation.

There’s a multitude of factors an interviewer needs to consider. The experience of the candidate, number of projects they’ve worked on, technologies they’ve used in the past, as well as how they perform in the current moment, when solving technical challenge, for example.

There’s a lot you can learn about a candidate by giving them something to implement and leaving them to it.

I’d love to hear people’s thoughts and suggestions on the topic so please use the comments section. If valuable information surfaces, I will definitely update the article with it and credit the authors.

1. Prototypal inheritance vs. this

You know how prototypal inheritance works but you don’t know how this works. Any JavaScript web developer who moved past the junior stage should be able to at least partly explain both concepts.

2. Type coercion vs. loose/strict equality

You can talk about type coercion but can’t properly explain what’s the difference between == and === and how they work internally(hint: one uses type coercion).

These concepts build on top of each other. For example, strict equality (===) is used to avoid false positives due to type coercion.

3. Hoisting vs. closures

You can explain hoisting but you can’t explain what are closures and/or when you would use one.

This is more of a personal expectation, although there’s no direct link between the two concepts. Once you start learning how scoping and closures work in JavaScript, you inevitably end up learning about hoisting.

4. Discerning between array methods (the big four)

You can’t properly articulate when you would use an array method over the other — map over forEach, reduce over map, and so on…

The big four array methods have different uses, and they range from more generic ones, like forEach to specialized ones like map, reduce or filter. I’d say that any web developer worth their salt should at least know how to use forEach, map and filter.

5. Event delegation

You can’t explain event delegation or write a simple event handler, in vanilla JavaScript to prove it(hint: Vanilla JavaScript is not a new framework).

The most concrete example of event delegation is registering click events on the items in a list. The naive solution would be to bind an event handler to each list item. But that is not optimal nor scalable.

const lis = document.querySelectorAll('li');

lis.forEach(
	(li) => li.addEventListener('click', (e) => console.log('clicked!'), false));

If the list is altered and new items are added, you won’t be able to register event handlers on the new items. So instead you register the click handler on the list itself and look whether or not the node being clicked on is a list item.

const list = document.querySelector('ul');
list.addEventListener('click', (e) => {
	// normally, event.target.nodeName is in uppercase - LI
	if (e.target.nodeName.toLowerCase() === 'li') {
		// only log to the console if the target node is an <li>
		console.log('clicked with delegation!');
	}
	
	return false;
}, false);

That’s event delegation, using regular JavaScript!

6. Pseudo-code / verbalizing your thoughts

You can’t describe concepts in pseudo-code.

The interviewer might want to have a conversation with you so you should be able to explain the solution you’re thinking about, without having to write code — at least for simple concepts.

Unless the interviewer is a complete lunatic, and they inhibit you, you should talk. You should verbalize the solution you’re thinking about, because that gives them the opportunity to assess your problem-solving capabilities.

You are ultimately interviewing so that you could join a team. Within a team, you will need to verbalize your thoughts. If you can’t explain, it will be harder for the interviewer to realize whether you’re a good fit for the team.

Closing thoughts

The inverse of each combo is also valid.

Again, this is not a definitive list, and I’ve picked up most of what I wrote here from interviews I conducted for my employers/clients, throughout the past 4 years. Feel free to contribute your own.

The reason I wrote this article is because someone asked me to answer a similar question on Quora: What are 5 ‘must know’ concepts in Javascript, which if you do not know, signal to others that you are still a beginner?.

I feel it is very important to give new web developers and beginner JavaScript developers in particular clearer guidance.

Keep an open mind.

Adrian.

Photo credits: Raj Eiamworakul on Unsplash