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.
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 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:
For more information about how to use jsdom, check out their api: https://github.com/tmpvar/jsdom
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.
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: