Coding challenges on Honeypot

Every developer on Honeypot is prescreened before being accepted into a batch. This is beneficial for both sides: for devs, passing the challenge grants access to a platform with high quality companies and job offers, and for companies, pre-screening simplifies their work. Here’s how it all works…

Our first step for evaluation is activity on relevant public profiles. In cases where the developer doesn’t have any opensource code on GitHub or contributions on other platforms we offer a challenge. The challenges are delivered through git repositories hosted on GitHub that contain a simple description of the task. After results are submitted and the developer is accepted onto a batch this repository gets shared with companies. We are currently beta-testing our initial set of challenges and using the learnings to improve and further expand the variety of our challenges.

The challenges are designed to be language independent and show not only programming skills but general understanding of the domain. Our evaluation criteria takes the assumption that code is written once but read multiple times. We do not evaluate the challenge results in isolation but rather consider them to be an addition to existing profile.

So what do we value? We have divided it in two categories, workflow best practice and code quality. The following is an overview of what we are up to at Honeypot:

Workflow best practices: these general characteristics show a developer’s ability to communicate constructively, work in teams and think organizationally.

1. Usage of Source Control System such as Mercurial, CVS, GIT, SVN Source control is a system which records changes to a file or set of files so that specific versions can be recalled later. It is important for the process of reviewing code, correcting mistakes, and understanding what was done by whom and why.

2. Usage of continuous integration for automating tests, deploys and quality assurance Continuous Integration (CI) is a development practice in which developers integrate their code into a shared repository several times a day. It allows team members to detect problems early.

3. Usage of documentation Documentation, such as a basic README, describes what the code does, how it is set up, why one framework instead of another was chosen. This allows newcomers to the project get easier up to speed.

4. Usage of automated server setup tools such as Chef, Ansible, Saltstack, Docker, Vagrant Manual server setup, as opposed to automated server setup, wastes time and are generally more prone to error than automated setups.

5. Communication skills as evidenced through reporting issues and submitting patches, pull requests We review available history of communication with other developers. We search for evidence of structured, constructive communication. This indicates a developer who is a team player.

6. Knowledge of different languages and programming paradigms Knowing how different problems are approached in different environments expands the scope of possible solutions when a problem is faced. And shows general learning abilities.

Code quality

1. Does it work? (is executable and behaves as specified) Does the solution solve the problem at hand.

2. Testing (unit, integration and/or acceptance tests, they pass and cover public interface) It is always good to have someone else to verify that your changes are delivering the expected results. This gets even more important while work in teams and on larger code bases. It makes it easier for others to understand and change the code.

3. Size of files, classes, modules, functions and methods Structuring code in smaller chunks, grouping and assigning meaningful names makes the code more readable, reusable, testable and maintainable.

4. Complexity (minimal usage of nesting and conditionals) Avoiding multi level nested conditions makes reasoning about the code more simple and through that significantly improves the possibility to spot errors earlier in the development cycle.

5. Framework/library usage: using frameworks springs/rails/laravel or non-trivial libraries. Reusing existing solutions and not reinventing the wheel saves time and hassle.

We are constantly working on improving our challenges and evaluation process by collecting feedback, suggestion and integrating with existing tools and libraries.

Join Honeypot today and receive 4 interview invites or more in three weeks.