> If you’re a developer who’s been asked to debug legacy PHP or build a mini-app from scratch in just a few hours, you know what I’m talking about. It’s becoming a trend, and it’s not helping anyone.
I once got the equivalent of the "build a mini-app from scratch in just a few hours" test in game development. They weren't actually expecting, to my understanding, that candidates would get very far - which is to say: just because the test conditions seem terrifying, the standard being set isn't necessarily very high.[0]
That was 15 years ago, by the way.
> These high-stress, solo coding assignments don’t reflect the actual job. Instead, they put developers in situations they’d never face in the workplace, where collaboration and support are standard.
It pretty well did for me. The test did come with a direct link to documentation (for an API I'd heard of but never used) and an offer of support from existing employees (but I was too busy reasoning things out by myself to come up with good questions to ask them). And after that, just about all the code I wrote was done solo. Some projects (and companies) are just like that. Pair programming does involve some overhead, and it doesn't come naturally to a lot of programmers. I don't like being taken out of flow, and I don't like feeling like I could inadvertently do it to someone else.
> When was the last time you had to debug an ancient codebase without documentation or help from a team?
Have you never revisited your own solo hobby projects after a few months? Or is your own documentation that good?
> Yet companies claim this somehow measures “problem-solving” skills.
... And why would you doubt that?
> Developers don’t just jump into an assignment; they research the company, study the job requirements, and meticulously work to polish the project.
This is the part where I start to suspect the entire article is AI generated[1]. The clauses of this ascending tricolon[2] have little to do with each other, and the overall logic is absurd. Yes, of course an interview candidate may spend additional time outside the coding test. But that has nothing to do with the test itself, and would be the same when interviewing for a place that didn't offer such a test. Of course candidates research the company and study the job requirements; that's expected, and completely unrelated to the test. On the other hand, they certainly do not "meticulously work to polish the project" (a description that doesn't even make sense for "debugging legacy PHP", although it could for "building a mini-app") - especially not outside of the time actually allotted for the test.
> This is like asking a Ruby developer to debug PHP as a test of flexibility.
Similes are supposed to come from outside the domain they're being used to explain.
But debugging is problem-solving.
> This turns away skilled candidates who could do the job well but don’t thrive in these artificial, high-pressure situations.
How would you know? Are you one? What if they don't find the situation "high-pressure" because they're skilled enough that the task is easy for them?
> Hiring processes should focus on problem-solving, collaboration, and growth in relevant areas.
[2] again; also, "growth in relevant areas" a) is awfully vague and b) doesn't come across as something that could in principle be tested. Unless the argument is that candidates should talk about how they developed their skills rather than just what they can do now. Doesn't seem very relevant to me.
And, again, debugging is problem-solving.
> If companies want adaptable developers, they should focus on the long-term ability to learn, not how fast someone can tackle an arbitrary test.
> a better, more inclusive tech culture.
One of the things I find scariest about today's world is that I can read such a complete non sequitur[3...
2 comments
[ 5.0 ms ] story [ 17.0 ms ] threadI once got the equivalent of the "build a mini-app from scratch in just a few hours" test in game development. They weren't actually expecting, to my understanding, that candidates would get very far - which is to say: just because the test conditions seem terrifying, the standard being set isn't necessarily very high.[0]
That was 15 years ago, by the way.
> These high-stress, solo coding assignments don’t reflect the actual job. Instead, they put developers in situations they’d never face in the workplace, where collaboration and support are standard.
It pretty well did for me. The test did come with a direct link to documentation (for an API I'd heard of but never used) and an offer of support from existing employees (but I was too busy reasoning things out by myself to come up with good questions to ask them). And after that, just about all the code I wrote was done solo. Some projects (and companies) are just like that. Pair programming does involve some overhead, and it doesn't come naturally to a lot of programmers. I don't like being taken out of flow, and I don't like feeling like I could inadvertently do it to someone else.
> When was the last time you had to debug an ancient codebase without documentation or help from a team?
Have you never revisited your own solo hobby projects after a few months? Or is your own documentation that good?
> Yet companies claim this somehow measures “problem-solving” skills.
... And why would you doubt that?
> Developers don’t just jump into an assignment; they research the company, study the job requirements, and meticulously work to polish the project.
This is the part where I start to suspect the entire article is AI generated[1]. The clauses of this ascending tricolon[2] have little to do with each other, and the overall logic is absurd. Yes, of course an interview candidate may spend additional time outside the coding test. But that has nothing to do with the test itself, and would be the same when interviewing for a place that didn't offer such a test. Of course candidates research the company and study the job requirements; that's expected, and completely unrelated to the test. On the other hand, they certainly do not "meticulously work to polish the project" (a description that doesn't even make sense for "debugging legacy PHP", although it could for "building a mini-app") - especially not outside of the time actually allotted for the test.
> This is like asking a Ruby developer to debug PHP as a test of flexibility.
Similes are supposed to come from outside the domain they're being used to explain.
But debugging is problem-solving.
> This turns away skilled candidates who could do the job well but don’t thrive in these artificial, high-pressure situations.
How would you know? Are you one? What if they don't find the situation "high-pressure" because they're skilled enough that the task is easy for them?
> Hiring processes should focus on problem-solving, collaboration, and growth in relevant areas.
[2] again; also, "growth in relevant areas" a) is awfully vague and b) doesn't come across as something that could in principle be tested. Unless the argument is that candidates should talk about how they developed their skills rather than just what they can do now. Doesn't seem very relevant to me.
And, again, debugging is problem-solving.
> If companies want adaptable developers, they should focus on the long-term ability to learn, not how fast someone can tackle an arbitrary test.
> a better, more inclusive tech culture.
One of the things I find scariest about today's world is that I can read such a complete non sequitur[3...