Cho is a full-stack web-application developer. He dislikes mean people but likes the MEAN stack (MongoDB, Express.js, Angular.js, Node.js). During a typical week, he'll be coding in JavaScript, writing about JavaScript, or watching movies NOT about JavaScript. Here’s his blog.

Cho S.'s articles

  1. How to Conduct a Fair and Meaningful Technical Interview

    When I began searching for my first job as a web developer, I applied to, and received interviews with, several companies. Some of my interviews were with Fortune 500 companies; some of my interviews were with fledgling start ups. Regardless of the size of a company, the interview process was very similar: phone screening, technical challenge, and cultural screening.

    The technical challenge informed me about a company’s character. If the questions being asked were fair and meaningful, then I, regardless if I passed or failed the technical interview, would leave with a favorable impression of a company. At worst, I would leave without a job but with some new and useful knowledge.

    If the questions I was being asked were out of the scope for a particular position or merely a trick, then a company risked alienating me and other applicants. I can still recall an interview I had with a CTO of a start up in Manhattan, New York. This person asked me to describe the difference between prototypal inheritance and prototipal inheritance. The second inheritance pattern didn’t exist. After my interview, I talked to a few of the other applicants, and we all agreed – we would never work for that company.

    So what’s considered fair and meaningful? Fair is considered asking questions that are appropriate for an applicant’s prospective position. Meaningful is considered asking questions that reveal some level of understanding of a fundamental concept. When a question is fair and meaningful, both the interviewee and interviewer benefit.

    I believe that both of these objectives can be meet with these three concepts:

    1. Callbacks
    2. Binding
    3. Event Emitters & Inheritance

    Each of these concepts are integral to a web developer’s knowledge; these topics, however, are disconnected enough to give an interviewee who incorrectly answers a question an opportunity to correctly answer the other questions.

    A rubric for grading a technical interview is located after these three concepts.

    Callbacks

    Interviewers should always ask an interviewee to define a concept. This initial step confirms that the interviewee understands what’s being asked. If the interviewer fails to ask this question, then the interviewee should volunteer to share their understanding of the concept. Without a mutual definition, the interviewee is unlikely to solve a given task.

    After a mutual definition is reached, the interviewer should present a question involving code: I want to explore your understanding of callbacks, so please create an implementation of a well-known function called reduce. At this point, the interviewer should present an invocation of reduce with example input and output data.

    [js]
    // input
    reduce([1,2,3], function(total, value) {
    return total + value;
    }, 0);

    // output
    6
    [/js]

  2. Understanding module.exports and exports in Node.js

    As developers, we often face situations where we need to use unfamiliar code. A question will arise during these moments. How much time should I invest in understanding the code that I’m about to use? A typical answer is learn enough to start coding; then explore that topic further when time permits. Well, the time has come to gain a better understanding of module.exports and exports in Node.js. Here’s what I have learned.

    What is a Module

    A module encapsulates related code into a single unit of code. When creating a module, this can be interpreted as moving all related functions into a file. Let’s illustrate this point with an example involving an application built with Node.js. Imagine that we created a file called greetings.js and it contains the following two functions:

    [js]
    // greetings.js
    sayHelloInEnglish = function() {
    return “Hello”;
    };

    sayHelloInSpanish = function() {
    return “Hola”;
    };
    [/js]

    Exporting a Module

    The utility of greetings.js increases when its encapsulated code can be utilized in other files. So let’s refactor greetings.js to achieve this goal. To comprehend what is actually happening, we can follow a three-step process:

    1) Imagine that this line of code exists as the first line of code in greetings.js:

    [js]
    // greetings.js
    var exports = module.exports = {};
    [/js]

    2) Assign any expression in greetings.js that we want to become available in other files to the exports object:

    [js]
    // greetings.js
    // var exports = module.exports = {};

    exports.sayHelloInEnglish = function() {
    return “HELLO”;
    };

    exports.sayHelloInSpanish = function() {
    return “Hola”;
    };
    [/js]

    In the code above, we could have replaced exports with module.exports and achieved the same result. If this seems confusing, remember that exports and module.exports reference the same object.

    3) This is the current value of module.exports:

    [js]
    module.exports = {
    sayHelloInEnglish: function() {
    return “HELLO”;
    },

    sayHelloInSpanish: function() {
    return “Hola”;
    }
    };
    [/js]