At Wealthfront, our goal for interviews is simply to assess whether the candidate would be successful as an employee. The most important thing for us is to learn how they think and if they will excel at the job we are hiring them for.

When interviewing frontend engineering candidates, we want them to write real code in an environment that they are used to. One of the greatest tools for technical interviews in the last few years has been CoderPad. CoderPad lets candidates write and run their code in a live interactive environment. No engineer would write code, read it very carefully and think “yep, this looks right”, and then ship it to production. So, why should we structure our interviews in such a contrived way?

When candidates can run their code in interviews it gives us the opportunity to learn how they would actually approach the problem once we hire them. We hope they will test their assumptions in the REPL and use error messages effectively to fix their solutions.

Since testing is so important to us at Wealthfront, being able to use Mocha in some of our technical interviews has been valuable. When designing our questions we can use tests to define the expected behavior, ask the candidate to fix predefined failing tests, or ask them to write their own tests. These are three real scenarios that we are able to introduce to our interview process and have allowed us to create more realistic interview questions.

Using CoderPad with Mocha has been great for our interview process, but one of the other major obstacles for creating a realistic environment is the inability to run browser specific code. When writing JavaScript in CoderPad we are using a node environment so references to document or window will fail since those globals aren’t defined. If we can’t run the code, this puts us back to using the contrived model of “mental compilation”. That puts a lot more stress on the interviewer as a human compiler, and is a less than ideal environment for the candidate.

jsdom

jsdom is a library that provides a fake browser environment in node.

We reached out to CoderPad and they were willing to add jsdom to their list of allowed npm packages.

@Eli_White that's a great suggestion. I'll have it go out in the next release. — CoderPad (@CoderPad) September 16, 2016

By using jsdom, candidates are able to write and run their code in CoderPad as if it was running in a browser. The fundamental thing we want from jsdom is document . We can get that with the following line:

View the code on Gist.

For more information about how to use jsdom, check out their api: https://github.com/tmpvar/jsdom

Mocha

A common complaint about Mocha is that it doesn’t run in a very “node” like way. Mocha uses a special test runner which injects globals like `describe` and `it` and then runs the tests.

We can use some of Mocha’s internal apis to run tests in node, and thus CoderPad. Paste this into a CoderPad and give it a run.

View the code on Gist.

A full example

Putting this all together, we can have a candidate write code that requires the dom and validate it with Mocha tests. Here is a full example: