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.
"Again, you came in with a resumé or a CV. That should be good enough. "
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.
I've seen code test in recruitment process for a tiny company. Candidates who had really amazing CVs (multiple projects, leading roles) who were applying for a position of PHP developer when actually sat down in front of a computer with google, text editor and PHP couldn't write the simplest programs. And I'm not talking about reversing binary tree whatever that is or even fizzbuzz. They couldn't reserve a string! Or use any other basic features of PHP language that were all painfully easy to google. One manged to copy paste a solution to a single problem not showing any original thought anywhere. And that was the best candidate. Most of them just crumled and ran away when they saw that they actually are expected to write a bit of code.
If they were hired on the CV alone they would be fired on the first week, possibly first day.
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.
There's too many bad programmers that are able to get by because of clueless managers. And schools aren't good indicators either. So for that reason I have to disagree very strongly. CV/Resume is a VERY BAD way to evaluate candidates. At a minimum you miss super talented self taught individuals, and at worst you end up with posers.
The problem is that the majority of so called programmers in the market cannot actually write code, and there's currently no other way to weed them out.
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’ve encountered this claim a number of times and since it is repeated without any evidence - I will offer the following rebuttal to this claim also without offering any evidence - In my opinion and experience this claim is nonsense and an attempt to gaslight developers, or to gate-keep.
Anyone who has interviewed more than a handful of developers knows this is true. It is a very painful experience for both sides of the table. Any kind of evidence is difficult to provide without potentially leaking personal information - unless you just want pipeline stats, which could just as easily be made up if you're not believing what the other person is saying...
And yet somehow I’ve managed to not encounter any of those fabled Paula Bean developers. Though I did encounter a fair share of the other kind - toxic know-it-alls who are immediately dismissive of anyone who doesn’t immediately regurgitate some in-crowd trivia that they favor, and are quick to call them idiots.
Maybe so, I wouldn’t dismiss your claim of that experience.
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.
I’ve conducted probably approaching a 100 interviews in my career. I don’t know if it’s a low or a high number, being that I am not a recruiter.
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.
My post was written from direct experience of having run and being on multiple interviews over the last decade. It's not a one-off thing. It's a depressing majority of applicants.
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.
A code test is fine, so long as failing it simply leads to discussion. Some people exceed and/or enjoy tests, some people (especially non-academic) may fail them or be too anxious to apply even though they are highly capable.
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.
15 comments
[ 4.6 ms ] story [ 49.1 ms ] threadI 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.
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.
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.
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.