Node.js Interview Questions Part 2

A recent project that I am proud of was a simple Arabic letter writing and spelling app I recently wrote. Basically, the app plays the audio of a random Arabic word, the user then drags and drops the correct letters of the alphabet in order to spell the word, and then the app tells her if it is correct or not. I implemented the audio feature using the web speech API, which I was thrilled to discover comes with a pretty decent Arabic voice out of the box. I found though that the Arabic voice would not read all words correctly, and so I had to be relatively selective with what words I could include in the list. Secondly, I found that the text to speech audio would not work correctly on all browsers, which I am not too distressed about for now given that the web speech API is still an experimental technology . I’m actually curious and excited to see this technology progress further, and ultimately had fun experimenting with it to come up with what at the end of the day is a working up for now!

I typically do testing by using a node.js testing suite like Mocha or Jest. In writing tests, I try to think about the basic cases and their expected return values first, and write a few tests for those. Once I can get those tests to pass, I then try to think about the edge cases and write more rigorous tests for those. As a complement or sometimes even alternative to test-driven development, I am also a very firm believer in “console.log driven development”. I will take the function I am trying to build to an IDE and play with it for several cases. I will throw console.logs into various steps of the function to see what it is doing at those various steps and debug or re-assess my code plan as needed.

I will use any and all tools that help me get a clear overview of what the code in my functions is doing and how it is behaving at every stage of function execution. Three indispensable tools for me in this regard are node.js testing suites, using console.logs liberally, and using the chrome developer tools and their robust set of features — particularly the ability to step through a function to try and discover exactly where a bug is occurring.

One preferred method is to anticipate possible error cases and to throw a new Error should they occur. Another is to use try … catch blocks for error handling. However, one caveat is that try ... catch blocks will only work on synchronous code. For asynchronous code, a good method is to take advantage of the process global object in node, which is a listener function in node that always keeps track of events during execution. One of the events on the process object is an unhandled exception. We can reverence this on the process object and then pass in an error handling function with the following code:

process.on(‘uncaughtException’, function(err) {// Handle the error safely

Node.js is by default a single thread application. Hence, it will run on a single processor core and will not take full advantage of multiple core resources. However, Node.js does provide support for deployment on multiple-core systems, to take greater advantage of the hardware. The Cluster module is one of the core Node.js modules and it allows running multiple Node.js worker processes that will share the same port. This is one of the features that makes Node.js highly scalable for large web applications.

The first argument passed to a Node.js callback handler is typically the error object. This way, if an error occurs, it can safely be handled. If not, then a value of null for error is passed for that argument, and the function proceeds to execute for the rest of the arguments. Hence the following is a typical callback pattern in Node:

function callback(err, results) {
// check for the error before handling results
if(err) {
// handle error somehow and return
// no error, perform standard callback handling



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Fares

Michael Fares


I am a Frontend Web Developer, Educator, Lifelong autodidact, 3rd Culture Kid, and Citizen of the World.