How should a code test evaluate a developer?


As a developer, is it important to have excellent skills in vanilla javascript and algorithms? It might be in cases where the most common tools and frameworks do not provide what’s needed to fulfil the customers’ requirements. Or, where the everyday work is to develop very complicated calculations and new programming languages. I once had a contract at one of these companies. They never tested my algorithm skills, but I think it would have made sense to do it.

I have never had any interest in binary trees, and I don’t have a deep mathematical education. And not surprisingly, I usually do quite bad at algorithm tests. Does this mean that I didn’t do a good job at this company? I wouldn’t say so. As in most
companies, the majority of programming tasks and challenges were very different from developing a new programming language.

Complementary skills

I was fully productive solving these other tasks, as well as providing skills that most of the other developers didn’t have. For example, I lead discussions about code structure and technology choices, introduced domain-driven design and clean code, talked about clean architecture, isolating business rules and defined a strategy for automatic testing. So, while I didn’t fulfil their wish that all developers should be excellent algorithm solvers, I added other highly valuable qualities.

My role became complementary, rather than competing with the skills of the other team members. This made the team stronger. With improved psychological safety and an including atmosphere, the team members increased their contributions both with spirit and skills they didn’t know they had. Read more about this approach in one of my blog posts: Teamwork – complement instead of compete.

The code test paradox

When a team is asked to set up a code test for new team members, they will often make the test cover areas of their own interest. So, even if there is an aim of broadening the range of skills within the team, they will end up finding new team members with the same skills and interests as of the already existing.

So, how should we formulate the tests?

I was recently part of an interesting team exercise. We were asked us to write some C# code to find the newest debutant in a list of musicians. Everybody wrote their code and uploaded it to Git. Together, we went through every solution and discussed it, having the person who wrote it explaining the different choices that were made. It was a simple task, but I was amazed by the number of different solutions! Some made it as short as possible, some used a more functional approach with Linq, some were more object oriented and yet others focused on class responsibilities.

When having a team with different personalities and different skills, the team output and code quality increase. We should adapt the code tests to find a person with a specific skill. If we need a team member with mathematical skills who should improve performance of our algorithms, then we use an algorithm test. If we need a techlead that should lead others and ensure code quality and technology choices, a technical discussion might be more clarifying than a code test.

In many cases, a test that shows how the developer handles business logic and structure their code is more interesting than if they are smart enough to solve a tricky problem.


A code test should evaluate the skills needed for a specific role or profile in the team. Preferably, the different test types are not only decided by the developers, but also by the team leader who might have a better overview.

Also, the purpose of tests is not only a way for the team to evaluate a new team member, but also a way for a job applicant to evaluate whether the role is a good match, or not. If the day-to-day development that should be performed is simple and repetitive, an extensive and algorithm-based code test might select a candidate that is smart but who will be bored by the actual job. This person might try to make the job more exciting by, e.g., overcomplicate the solutions, or leave for another job.

You can read more software engineering blogs from LTL here

Similiar Articles


Sign up today for monthly newsletters containing:

  • News and insights from your industry
  • Relevant thought leadership articles
  • Engaging video content
  • Notifications of our upcoming events
  • Networking opportunities with C-Suite leaders