Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
There is I think a tendency for software developers to signal their superior intelligence. The job interview is a way to invent tests which exist simply to communicate how wonderfully intelligent they are. I won't be crude, but this is just a member measurement exercise for intellect.
Okay, so what are we aiming for when we give developers a test? Are we trying to find out if they know the syntax? That they have memorized the API to the point they don't need completion? Do they know how to do binary shifting? Generally no.
We are not trying to test the basic language skills as they should have already been excluded if they don't have these skills. We are not trying to perform some kind of intelligence test. Some companies give tests that are meant to test intelligence, but there is an underground market in training to pass these tests. So again, no.
Instead we need to focus on higher level understanding and coding practice in everyday coding. We want to see if a developer asked to modify an application can recognize and correct poor design or anti patterns. Such a test must respect the value of time for a developer, and so must not be too complex. Providing an existing project of small size with a explicit objective means the task can be completed quickly by a competent developer.
This is not a pass fail type of test, but rather a exercise to flesh out whether the developer picks up on common development mistakes and will refactor as they go.
I wrote a article covering the test I wrote. This is good not only for interviews but also as a training exercise.
There is I think a tendency for software developers to signal their superior intelligence. The job interview is a way to invent tests which exist simply to communicate how wonderfully intelligent they are. I won't be crude, but this is just a member measurement exercise for intellect.
Okay, so what are we aiming for when we give developers a test? Are we trying to find out if they know the syntax? That they have memorized the API to the point they don't need completion? Do they know how to do binary shifting? Generally no.
We are not trying to test the basic language skills as they should have already been excluded if they don't have these skills. We are not trying to perform some kind of intelligence test. Some companies give tests that are meant to test intelligence, but there is an underground market in training to pass these tests. So again, no.
Instead we need to focus on higher level understanding and coding practice in everyday coding. We want to see if a developer asked to modify an application can recognize and correct poor design or anti patterns. Such a test must respect the value of time for a developer, and so must not be too complex. Providing an existing project of small size with a explicit objective means the task can be completed quickly by a competent developer.
This is not a pass fail type of test, but rather a exercise to flesh out whether the developer picks up on common development mistakes and will refactor as they go.
I wrote a article covering the test I wrote. This is good not only for interviews but also as a training exercise.
The Test:
dev.to/cheetah100/java-developer-l...
The Solution:
dev.to/cheetah100/java-developer-l...