Errors That Are Common In Recruiting Tasks

For the company I work for, I recently evaluated recruitment assignments.

 

My personal experiences, including the negative and positive feedback I've received, have led me to form an opinion about what a well-written task should appear like.

 

What are the common mistakes candidates make?

 

 

Combining high-level abstractions with low-level details is the crucial part.

 

Putting all of the code in the section responsible for handling HTTP requests is an example of this.

 

When a request is received, the task or process must only use dependencies to parse data, check permissions, and implement logic.

 

Take a look at two of these solutions (code written without any reference to any frameworks).

 

Can you choose which is easier to understand?

 

 

 

All the details of the case are brought to the surface in the first example.

 

Every change has an impact.

 

For example, updating the method of querying a database can change permissions.

 

We inject and manage dependencies in the second solution.

 

It is much easier to read the code since we make changes where responsibilities are clearly defined.

 

Support For Git Is Also An Issue

 

Projects often find it challenging to treat git as a tool to zip code.

 

A clear commit message and the inhibition of commits that do the same thing, in my opinion, are critical.

 

The Candidate's approach is not reflected well in five commits in a row with a "fixes" or "asdf" message.

 

Code that contains protected data should also not be committed.

 

The commit needs to be deleted if a private key was accidentally put into the repository. 

 

Each feature should ideally be in its own branch.

 

Create a single protected branch that only contains code that passes automated tests, if possible.

 

As a side note, Continuous Integration is always welcome.

 

GitHub and GitLab let you run tests for free, so make sure you take advantage.

 

Nonetheless, assessments are still necessary for this situation.

 

Sometimes it is a mandatory requirement, other times it is not.

 

If it is really required, it must be written down.

 

Even if they don't... write them anyway. 

 

Even if we don't use TDD, writing tests makes life better and besides, we should write the application as if we were going to maintain it.

 

Occasionally there isn't enough time to test everything.

 

So, what should we do?

 

 

During testing, we check the most critical functionalities.

 

For example, if access to some resources is only permitted for logged-in users, at least check whether we blocked access for non-logged-in users. 

 

We should at least test the algorithm's accuracy outside of context HTTP requests, databases, and so on.

What about the other things we haven't finished yet? Testing isn't the only one.

 

I prefer the second approach.

 

Some companies may prefer the first but at this point, it's worth assessing whether we want to work with companies that do things halfway.

 

It is natural, in my personal view, that doing recruitment work in one's spare time means that one cannot always spend enough time to get it all done well.

 

As I evaluate assigned tasks, I consider how the candidate thinks rather than whether the application adds "value" to the company.

 

You might be able to negotiate an extra couple of days to complete the task, or perhaps what we've implemented will be sufficient.

 

It's worth discussing this.

 

 

SUMMARY

 

These pointers account for approximately 75% of my comments on the code that I evaluate.

 

I've seen these pain points in the code of candidates at all levels, so I'm willing to bet this isn't widely known.

 

Following these guidelines won’t guarantee you a job, but will give you better chances. Best of luck!