Challenging technical challenges

#challenge #interview #career #job

As a software developer, I can state that having job opportunities has been (and it currently is) quite easy. You may think that it is not 100% true, and you're right, depends on which is the position you want to get into. But generally speaking, and compared to other jobs, I think I can still maintain the original assertion.

Sometimes I have the feeling that people from other professions, or even from ours but with less experience, see us like living among unicorns: moving from one company to another quite frequently, raising the salary in each of this movements, obtaining good benefits & perks, and also having a strong position to take riskier decisions.

But not everything are unicorns living in peace in a never ending paradise.

And now I want to focus on one of the things we have to deal with when in a hiring process: coding challenges. You can find them in a variety of names and shapes, but with the same theoretical purpose: evaluate candidate's development skills. And I say theoretical because I don't believe that they're going to give real and fair feedback.

The Coding Challenge

Here the typical scenario where you have a code base/scaffolding, and then you have to develop whatever is needed on top of it...

... and I have a lot of concerns about this way of assessment. Let me try to summarise them briefly:

You need to invest non-paid time to first understand what you are asked to do.
Then you need to invest non-paid time to develop the solution.
But as is a challenge that will be reviewed in detail, then you need to invest more non-paid time to do things in an elegant and reliable solution.
As we want to do things in a proper way, this leads us to think about going the famous extra mile. And this means, doing something that we were not asked to do, with the conviction that it will dazzle the reviewer. And this means investing more non-paid time.
And if you over engineer too much, the reviewer couldn't potentially understood what you did, for example because maybe is not as experienced as you, and then potentially you're going to receive feedback like "the candidate doesn't follow KISS principle".
As you may have noticed, there's a non-paid factor that is very important, and that it is also very tight to the time factor. Both, for us and for the company, time means money... it's a simple rule. But it seems that when you are a candidate, magically your time becomes cost-free, and you as a candidate can invest all the amount of personal time that you may need. That doesn't sound fair.
Coming back to the time factor, being fair I should instead say personal-time factor. Honestly, sometimes I have the feeling that as developers we just assume there is no other option. And we sacrifice our personal life (kids, friends, hobbies, etc.) just to find the time to do something that can just be finally rejected. And opportunities always come back, but time doesn't.
I just mentioned it briefly, but what about the reviewer? Who is going to assess that the reviewer has the proper knowledge to evaluate the candidate, and that is going to do a fair code-evaluation?
Potentially the company could also design a big/complex challenge, because they may think they are going to have a better technical coverage. But this may also lead the candidate to think that the company is assessing this way because they are working this way, and the company wants to be sure that you are familiar working like this. But maybe they are not, and this may lead the new joiner to frustration as the expectations vs reality where not correctly aligned at all.
Finally, I want to point out that there is people that trains themselves to be able to pass the technical assessments, mostly the ones that are time boxed like: you have 20 minutes to implement a FizzBuzz algorithm, or similar. If you practice enough, it's quite easy to pass those kind of coding challenges, but this doesn't make the candidate a better developer, they just know how to pass the assessment.

So, how can I be sure that the candidate has the desired skills?

If you are looking for a process that fully guarantees that the candidates has the skills you want, you are not going to find it. Instead, there are other things that the company can do and are not that time consuming. Here a couple of hints:

During the interview process, having a technical discussion with the candidate and the team can be very useful. And it's very important that is a discussion, and not a one way speech.
Also doing a whiteboard session, where the candidate can design a solution, is a good way to get very useful insights about their thinking process.

As a final consideration, knowing that the absolute certainty does'n exists, we should consider that companies always have probatory periods. And being far from ideal, and knowing they're not going to remove it, we then have to take that into consideration as an extra layer of "protection".

I honestly think that sometimes is more important the cultural fit in a company, rather than the desired technical excellence. And this cultural fit have lots of different perspectives to be considered...