Here’s a list of interview questions you might get asked if you’re looking for a job as a JavaScript web developer, or a Node.js developer.
Do you know ECMAscript 2018?
This can really throw you for a loop if you’re not sure what they’re talking about. ECMAscript is the standard that holds all of the features that JavaScript engines within browsers implement. The differences between browsers are just differences in how those browsers have implemented ECMAscript.
For older versions of ECMAscript there are less features implemented, an old version of Firefox will only have some of the functions you’re normally expecting to be there. But the latest version of Firefox implements the latest version of ECMAscript. You can see a good sum up of what features are available in each version. Here’s a reference taken from w3schools.
| ES1 | ECMAScript 1 (1997) | First edition |
| ES2 | ECMAScript 2 (1998) | Editorial changes |
| ES3 | ECMAScript 3 (1999) | Added regular expressions Added try/catch Added switch Added do-while |
| ES4 | ECMAScript 4 | Never released |
| ES5 | ECMAScript 5 (2009) Read More | Added “strict mode” Added JSON support Added String.trim() Added Array.isArray() Added Array iteration methods Allows trailing commas for object literals |
| ES6 | ECMAScript 2015 Read More | Added let and const Added default parameter values Added Array.find() Added Array.findIndex() |
| ECMAScript 2016 Read More | Added exponential operator (**) Added Array.includes() | |
| ECMAScript 2017 Read More | Added string padding Added Object.entries() Added Object.values() Added async functions Added shared memory | |
| ECMAScript 2018 Read More | Added rest / spread properties Added asynchronous iteration Added Promise.finally() Additions to RegExp |
https://www.w3schools.com/js/js_versions.asp
So if your interviewer is asking if you know ECMAScript 2018, or if you know ES6, they’re asking if you’re up to date with advanced JavaScript features. Like, How to use Promise.finally().
If you’re familiar with the latest in JavaScript you should probably say yes, and talk about how much you love how JavaScript is keeping up with the times.
But if you’re not too sure, just talk about the projects you’ve made in JavaScript and express confidence that you can learn and use the JavaScript style that they’re using.
2. How do you avoid Callback hell?
So callback hell, is what happens when you have lot’s of asynchronous functions running all at once, this can sometimes lead to having callback functions within callback functions, within another layer of callbacks etc.
Here’s an article that covers callback hell more deeply. https://www.bmc.com/blogs/callback-hell/
This question is them asking you how you handle a common JavaScirpt problem, to try and figure out how you organize your projects.
3. What was your most difficult project, and how did you handle it.
To prepare for a question like this. You’ll want to consider your past programming projects, and list out the best ones, the worst ones, and what you’ve learned from each. You can get a variation of this question like. “What project did you learn the most from” or what is your least successful project etc. It’s good to have a set of projects in mind, so you can talk about them without pausing, or panicking.
4. Technical questions.
Oh man, it’s amazing how some companies will ask you to “reverse a linked list” or “Make a program to find the palindromes” on the whiteboard. For these kinds of questions I’m afraid you’ll need to go out and find a book, or study on YouTube to get your handle on these kinds of questions. Sometimes they might ask you these questions to see what your softs kills are like, and not exactly if you’re technical. Whatever you do, don’t throw a fit, or complain. Just coolly and calmly walk yourself through the problem on the whiteboard. And write our the pseudocode in plain English. Asking them questions and making progress as much as possible.
However if you flunk this part, and you’ve made sure to include some evidence that you have finished projects before, the company would be foolish to take this part of the interview too seriously.
Ultimately, we’ve got to remember, they’re trying to hire you for a job coding, and finishing things. Not implementing Fiz Buzz on the fly.
5. Practical test of your skill, these are kind of rare, but they can happen. I’ve seen it.
I worked at a place where during the interview, the person interviewing needed to show that they can at least make an Ajax request, and print the values of an array to the console. I’m sure there are places that will ask you to do similar things, and if you’re getting ready to land that job, it’ll help you to get some basics in your toolbelt so you can ace this part of the test.
Some companies give take home tests, and those are fantastic. I love the idea of actually checking to see what someone can learn, in case they don’t know how to complete the test right then and there.
Things that would be good to practice, in case you’re looking for a front end position.
- Ajax requests
- Using one of their technologies if they’ve listed a library or a framework like React, or Vue.
- Centering a div
Here’s a list of tasks you can think about in case it’s a backend position.
- Make an endpoint that tells you the current time.
- Write a sql query that joins two tables
- Look at a code fragment and answer questions about it.
Conclusion
In the end. If you’ve struggled your way through a few very small projects on your own, you’ll be able to handle almost any interview.
However if you should blow this part, say they ask you to make an ajax request and console log out the values, and you fail at the interview. Keep their email, figure out the question that night, or in the next couple of days, and email your recruiter the answer. That would show something that’s almost more valuable then knowing how to do their little test. It would that you know how to learn, and that you are unstoppable. Which could make them want you on their team.
Most companies want smart hard working employees. Those kinds of coders are worth their weight in gold. And you can do a lot of things to ease their concerns in the interviews you go to.
Here’s a tip that worked for me once, I applied for a job at a small web development shop in my city. I arrived with two apps that I had made, on my phone, and showed the person considering to hire me those apps. They were ugly, but they did work, and in the face of that kind of proof (that I can do the job) They were happy to hire me. You can do the same kind of thing. If you make something, or a few things, and you can show them to your prospective employer, I bet you’ll see some good results.
Now go out there and get hired! Start working your dream job and have a great career.