As part of the technical interview, you’ll be provided with an exercise, and some skeleton code that aims to solve a problem. Over approximately 40 minutes, you’ll get to implement a solution the best way you can while walking the interviewers through your process.
You will have the choice of approaching the problem in either Ruby or JavaScript.
This exercise mimics (in simplified form) some of tasks that we might do day to day, such as using different languages to interact with the command line.
One of our internal tools is a command line interface that helps developers set up and maintain their local environments in an easy and quick manner. This tool incorporates many helper methods that involve shelling out to the terminal.
For example, say we wanted to check if a config file existed locally, we could use a method doesFileExist? that would check the given directory and return a response.
Similarly to that example, this exercise will ask that you implement a series of helper commands that would be used in this tool.
We ask that to prepare, you:
- Choose either JavaScript or Ruby
- The exercise will take place on Repl.it, take a few minutes to familiarize yourself if needed.
- Come ready to ask questions, discuss your decisions, and have fun!
We don't believe in “gotcha” coding or irrelevant technical questions -- this is an open book, collaborative exercise to let us see how you approach and solve a problem and give you a glimpse into what we work on.
We're not judging on how many algorithms or libraries you've memorized, or how much immediate knowledge you have about the esoteric aspects of a language. Use Google, Stack Overflow, libraries, whatever other resources you’d normally use. There's no correct way to approach the problem; use whatever techniques you would use to help a teammate solve a problem in your day to day work.
We are interested in learning how you approach problems, and how you approach collaborating with your peers. We want to see how you explain your thought process. You can take whatever approach you're most comfortable with here, whether that's starting by correcting obvious errors and iteratively improving from there, or overhauling the solution from the ground up to approach it in a different way. Just make sure you're actively communicating with our interviewers to explain your thinking.
Typing with someone’s virtual eyes over your shoulders can be stressful, so we’re not looking for you to immediately figure out a solution or approach. Programming can be a process of iteration, and it's how you get there that's useful for us, not when.
You might be nervous coding live, and we understand that you may not be as comfortable as you’d normally would. That’s okay! We’re not looking for perfection or production quality code.
Besides, our code almost never works the first time around too.