Code Tests are pointless – doubly so for DevRel
devrelate.io
devrelate.io
When I say they cannot write code, I mean that when presented with a simple problem such as toy robot or fizzbuzz which requires them to break down a problem into steps and implement those steps, they are unable to do so.
There doesn't seem to be any particular pattern to this. I've seen it across different companies, different languages, and different seniority levels. I am at a loss as to explain if these people know they are incompetent, don't care, or are just plain desperate for some kind of work to pay the rent. Nonetheless, until we find a better way to weed out the majority of applicants who can't actually write code, this is the best option we have.
I have encountered them in teams that I’ve inherited, and although I don’t find that it’s the majority of applicants at interview it’s a significant proportion and you get no indication of it from other parts of the interview. I’m talking about people who struggle to work out that they need a loop.
Being able to talk about playing the piano is not the same as being able to play the piano.
My interview approach is simple - I talk to people about the things they’ve done and ask questions based on that. I discuss higher level concepts and don’t worry about syntax. I take about one hour, sometimes a little longer. I have never hired or recommended a hire of a dud.
80% of the people in this industry write CRUD apps, web apps at that, or simple API backends for said apps. Some of course create new languages and kernels, and I don’t know what an interview process needs to be for that skillset, but for 80% what I do is perfectly adequate.
In the spirit of constructive discussion, I have several thoughts about why other people may not see this. One, it's quite possible this is a very locale specific phenomena.
Secondly, I have tended to work in - and therefore interview people for - very mainstream languages, I suspect the experience of someone who works in/interviews for Haskell would be very different.
Finally, it's entirely possible that most of the applicants are by definition, the ones who find it difficult to get and/or hold on to a job, and that throws out the experience of the recruiting process, and that means they make up a disproportionate number of applicants, despite being a minority of programmers in the workplace.
If they were hired on the CV alone they would be fired on the first week, possibly first day.
Did you ask questions about their CV projects that dove into the implementation of the project?
It's possible they were asked about the projects. But if they were it was waste of time. It's easier and faster if you sit someone down and check the basic capacity to do the job they are applying for. Even faster in some cases because some candidates that sent in CVs didn't even show up.
I know someone who is changing fields and has learned to code over the last year. Mostly backend code, Kotlin and Python.
This person has no credentials, and studied something else in college - however the fact that code test are used allowed them get their foot in the door of a large company very recently because they didn't care that she didn't have much in the way of past projects.
She has a strong aptitude for coding, and they decided that was a better way to select for them
Without code test she probably would not have had a real shot of landing the job
>>> End the DevRel candidate test. End the Developer candidate test. It’s hurting everyone and wastes everyone’s time.
It's really not, there are many people who it is helping level the playing field greatly.
Empathetically, no way.
There are a lot of people who have difficulty coding, who are not comfortable outside of certain operating environments, and all of us have holes in our capabilities. Those are often not obvious until you start coding a bit.
Coding tests should not be 'gotchas' or 'secret IQ tests' or 'need preparation' but some bits of coding are necessary.
A GH repo can possibly serve as a substitute however.
By all means have a code test but explain that it is just one part of an overall process and is not in itself a deciding factor. The conversation around it is far more valuable.