- Posted by Intent Media 19 May
- 0 Comments
During the technical interview process at most companies, software engineering candidates are generally expected to provide evidence of the quality of their work. That demonstration often consists of a code sample or a coding test. That test serves both as a measure of the candidates skill at problem solving and an opportunity to showcase their proficiency and professionalism.
The intention of this article is to shed some light on Intent Media’s code test evaluation process, and reinforce positive qualities in the code submissions we receive. While these tips are presented in the context of an Intent Media code review, they are broadly applicable and should serve as a reasonable baseline for code submissions to any company.
The code test at Intent Media consists of a simple problem to be solved using one of our core programming languages: Clojure, Ruby, or Java. Build tools and testing libraries are allowed, other third-party libraries generally are not.
With no more instruction than that, it’s no surprise that we receive solutions that vary greatly in focus, scope, and quality. Evaluating submitted code then becomes an exercise in balancing the candidate’s interpretation of the instructions with our own internal expectations.
Here are some principles to help candidates make the most of their code submissions:
Choose the right tools – The expectation is that a code submission represents a candidate’s best work. We love to know that someone is curious about learning new languages and techniques, but the code submission is emphatically not the place to do it.
The choice of implementation language is left up to the candidate precisely because we want submissions to represent that person’s best work in a language and ecosystem he or she is comfortable with.
Be idiomatic – The definition of idiomatic is, “using, containing, or denoting expressions that are natural to a native speaker.” In the context of programming languages, this generally means using common patterns and constructs that are a natural way to represent concepts in a given language.
Idiomaticity isn’t limited to source code. It can be expressed in testing, building, packaging, documentation and almost any other aspect of the code submission process.
The best way to learn the idioms of a language or process are to work with people who are more experienced, and read source code and documentation from other projects.
Solve the problem – It may be tempting to solve problems in novel ways, or account for the most esoteric of edge cases, but in general, a concise, logical solution is preferable to something that feels over-engineered.
Over-engineering is a particularly common issue in the code submissions we receive, because candidates understandably feel the need to show off. A little robustness doesn’t hurt, but it detracts from the focus and readability of a submission if the design or implementation is convoluted in order to accommodate extra features. Furthermore, we wouldn’t want a candidate to waste their own time designing and implementing features that we didn’t ask for.
Test – Testing serves many purposes, but in a code submission, it is the quickest, easiest way to unequivocally prove that the code solves the problem. Testing also enables refactoring, which can be very important in the context of a coding interview.
For the same reasons we don’t mandate a specific implementation language, we don’t specify a particular testing framework or infrastructure. Candidates can write the tests comfortably and don’t need to worry about learning the idiosyncrasies of an unfamiliar framework.
Be consistent – In all aspects of engineering, consistency wins the day. From project structure to comment indentation, a consistent approach will simply refactoring, and review. Many build tools and IDEs have features that make it easy to generate consistent output.
Consistency is another attribute of a language or process that can be picked up easily by working with an experienced developer and especially through reading code from other projects.
Make it easy – Thanks to the fantastic technical recruiting staff at Intent Media, we are regularly reviewing code submissions. The more time we spend trying to build and run a submission to verify that it solves the problem, the less time we have to spend reviewing the actual code.
Make as few assumptions as possible about the reviewer’s environment, and be as explicit as possible about the submission’s build and runtime requirements. Make our jobs easier, so we can give the code the attention and careful review it deserves.
Communicate – While the initial code test submission is done in isolation, our onsite (or video chat) coding interview is an opportunity for the candidate to not only show us more of their coding chops, but also to work with our engineers in a way that approximates the kind of pair programming we do every day.
During this session the candidate has the opportunity to explain their problem-solving approach and ask us questions. We won’t give explicit solutions, but we will discuss design trade-offs and work with the candidate to agree on acceptance criteria.
With these principles in mind, we hope that software engineering candidates will be able to make the most of their code submissions, and represent themselves in the best way possible during the interview process. If you’re interested in applying for a software engineering position, check out the Intent media jobs page.
John Chapin is a Data Engineer at Intent Media, where he is building the next generation of predictive analysis tools alongside a world-class team. When he’s not hacking on a functional programming project, he can be found running along the Hudson River or planning his next trip abroad. John has a bachelor’s degree in computer science from James Madison University.