Take-Home Code Test Principles
Why Code Tests
A take-home programming assignment is becoming a common stage of the interview process at many software companies. At Simon Data it is a valuable opportunity for candidates to deliver a complete, working application to spec that showcases their mastery of programming, professionalism, and attention to detail. As a candidate it your chance to show command of modern programming principles and how you might build a small application if you were working here.
We aim to assign simple, constrained problems that will not eat up your entire weekend, but provide enough substance for the candidate to demonstrate his or her expertise. Different roles and positions may involve different problems and evaluation rubrics, but the concepts are always the same. We avoid ‘gotcha’ questions at Simon Data. To the contrary, we want as many candidates as possible to be successful in our interview process. The goal of this post is to share a few principles we work by each day and simultaneously to inform how we think about great code test submissions.
Engineering Principles
Solve the Main Problem
It can be easy to get distracted, and many candidates submit code solutions that do not actually work end-to-end. Try to understand the central problem that is being posed in the challenge and solve that. Start with solving the core as specified and then branch out and decide which reasonable and applicable boundary cases to work on. Take-homes are meant to be time-boxed to a few hours so it often does not make sense to go down long rabbit-holes.
Candidates should be proud of their submissions. Once finished with the main portion, feel encouraged to enhance your solution. Perhaps for you it would involve some core validation or exception handling, but you don’t need to build a monitoring system. You might want to check for certain types of user input, but you don’t have to build for every possible scenario. If the problem were asking for a command line app, you might want to make the output formatting nice, but you probably should not spend your time building a GUI.
Choose the Right Tools
A good engineer understands the available tools in his or her metaphorical toolkit and knows when each is appropriate. A certain type of language, framework, or method of programming may be in vogue, but more important than demonstrating arbitrary knowledge is demonstrating a clear sense of ‘right tool at the right time’. These skills will translate to being more effective in day-to-day work and demonstrate the ability to solve hard problems with straightforward, maintainable solutions.
Simon predominantly uses Python, but we will accept effective and clear solutions in any major language.
Be Idiomatic and Consistent
Once you have chosen a set of tools, whether that be a language, third-party library, or pattern, make sure you follow that through using its internal style. For example, if you choose to write code in Python, make sure it follows PEP conventions and that the code style is internally consistent. At Simon, we won’t judge you on spaces or tabs as long as they are used consistently.
This is also a good reason not to use the code test as a chance to experiment with new technologies. If you use a technology, you will be evaluated against your use of it. For example, if you have never written Scala before, it is unlikely your submission will successfully use Scala idioms and demonstrate mastery. The day you take the road test may not be the best day to also learn how to drive a manual transmission.
Third party packages
Always follow the instructions provided by a company on rules for third-party packages. They can have benefits and drawbacks. In general, showing your own work is more important than just importing someone else’s work, so limit your use. Use external packages that are common to the language patterns, to setup a test harness, or to utilize as shortcuts for repetitive code that may distract from solving the core problem. For example, it would be normal for a Java project using data structures to import Apache Commons, Google Guava, and/or JUnit. Remember your code reviewer might not have certain linked libraries already installed or may not always be running the same version of your OS.
Communicate & Make it Easy
You do not want to spend all day writing code and your reviewer does not want to spend all day reading it. Help them out. Keep it simple and clear. Provide a README or instruction file with any instructions to setup the environment, build, test, and run (where applicable). If the reviewer needs to configure anything, make it as straightforward as possible to see what they need to do. Easily copied, one-line commands to build and run always make reviewers happy. The less time the interviewer needs to spend trying to read, understand, and run your code, the better it probably is!
Conclusion
We hope this article was useful to you, whether you are interviewing with us or another great company. If you are not currently interviewing with us and these principles resonate with you, we’d love to discuss opportunities at Simon Data. Check out our careers page at https://www.simondata.com/careers or drop us a note at jobs@simondata.com!
