One of the main criticisms of take-home coding tests from companies is that there is no restriction on what a candidate can include in the zip file containing their solution.
Companies then spend more time unpacking the solution and running it compared to actually reviewing the candidate’s important (non-scaffolding) code. Comparing like for like when reviewing multiple candidate solutions, therefore, becomes very difficult.
We initially attempted to solve this problem by having template repositories on GitHub that companies could follow for each of our supported languages.
The template repositories solved the problem to a certain degree. However, based on the feedback we received from our early users, it was clear that this was still too much of a manual process.
The company needed to clone the template repository (for each language they wanted to allow the candidate to choose from) and update them with their test details.
For full-stack tests, the workflow was even more painful.
We did not support full-stack tests natively. As an alternative, we just provided a single “Generic template” repository, containing only two folders, one for the candidate’s frontend code and one for the backend code.
The “Generic template” was not very helpful at all for full-stack tests. The final submission for a full-stack test from a candidate could be anything from a Rails app, an Angular frontend with a Java backend, a React frontend with a Node.js backend, etc. Therefore, the problem of unpacking these tests was still very much an issue.
A new, more automated approach:
Today we are launching a new feature on CodeScreen that removes these current problems.
Instead of companies cloning down our template repositories and working from there, they simply add the description of the task and choose which combination of languages & frameworks a candidate can select from before starting the test.
CodeScreen then takes care of all the heavy-lifting by creating the repositories for the company, one for each of the selected combinations, with proper project structures already set up in the repositories.
For example, the user below has selected that the candidate can write their solution to a full-stack test using one of the following:
1. Ruby on Rails.
2. Angular frontend with a Java backend.
3. Angular frontend with a Node.js backend.
4. React frontend with a Java backend.
5. React frontend with a Node.js backend.
User adding the description of the test.
User selecting their full-stack framework options.
User selecting their frontend framework options.
User selecting their backend language options.
A private GitHub repository will be generated for each combination of the above, and the user is given access. In the case above, five repositories are created: Ruby on Rails, Angular & Java, Angular & Node.js, React & Java, and React & Node.js
The task details are automatically added to the README of each repository.
The root directory of the repository set up for an Angular & Java full-stack test.
The frontend directory of the repository, with a standard Angular project already set up.
The backend directory of the repository, with a standard Java Maven project already set up.
When a candidate then starts the test, they are given the list of options to choose from:
The main advantage of this is that all the scaffolding for each language & framework is created upfront, automatically by CodeScreen.The amount of work a company has to perform when setting up their custom tests is therefore massively reduced.
Candidates benefit from this too, as it means that when they start a CodeScreen test, the correct project structure is already set up for them in their private repo.
Full-stack tests are also now, by definition, natively supported via these new Template Generators.
We ultimately want to support all mainstream backend languages, frontend frameworks, and full-stack frameworks. We are working currently on adding support for Vue.js, Ember.js, Laravel, Clojure, and Rust.
You can see a video demo of Template Generators in action here.
We are currently brainstorming ways we can extend this approach further. Areas such as the choice of database used and even what cloud provider the backend code runs in (AWS Lambda, Google Cloud Run, K8s, etc.) are all in the pipeline!
Interested?
If so, then head over to https://www.codescreen.com to start your 7-day free trial!
If you have any questions or feedback, you can either:
- Ping me a message on LinkedIn.
- Send an email to hello@codescreen.com.
Thanks for your time!
