13 ms·

Any time a company asks me to do a HackerRank test, I immediately reject them. It's just not possible to have a quality engineering team and to also believe the

by p4wnc6 11y ago

Any time a company asks me to do a HackerRank test, I immediately reject them. It's just not possible to have a quality engineering team and to also believe the results of HackerRank tests correspond to on-the-job success. HackerRank is an attempt to commoditize software labor (literally reducing evaluation of your labor fitness to standardized examples). It communicates immediately that creativity is valued less than standardization, and that your uniformity and compliance are more valuable than your experiences. It's also a way to position developers as lower-status employees -- you essentially have to capitulate to the judgement of higher-status employees. Even if you ace the code test, it puts you in a defensive position to justify yourself, which inherently reduces your negotiation power. If you submit something that is even slightly unconventional (even if it's provably just as or more accurate than conventional submissions), then your negotiation power is extremely damaged. For example, think of the difference between actors who must audition and actors who are "offer only" -- they won't respond to your inquiry about hiring them unless you're prepared, based on their previous work, to make an offer already. If you ask Robert De Niro to audition, you'll get laughed out of the room. HackerRank is often like asking Robert De Niro not only to audition, but to do some kind of two-bit community improv class warm up exercise for his audition, then grilling him because he didn't enunciate clearly. Ridiculous. Employers often say they want to "see how you think" -- when they say this, it's a good idea to run the other way. No one can grok some whiteboard code or some timed code test on standardized examples and draw any meaningful conclusions about "how you think" or how it will relate to job success. Someone who believes they can "see how you think" from narrow, time-constrained examples is going to be a terrible colleague or, worse, a very dysfunctional boss. I think the trend of cultivating "full-stack" developers (instead of benefiting from specialization and separation of concerns) is the number one problem facing the software industry right now (and folks are largely in denial about it). This nonsense with commodity interviews via HackerRank is the number two problem, followed closely by the prevalence of open-plan offices and the prevalence of Agile-like workflow management processes.

extrapickles 11y ago
Full-stack developers should be generalist in nature to make sure the issues that cross domains (front/backend, etc) are taken care of. Also, they can plug any gaps in the development that crop up from time to time (eg: someone on vacation, or next feature needs more back-end people). The downside is that they will not be spectacular or as quick at any one domain. Basically, a full-stack developers specialization is to be flexible and have knowledge and experience in working the entire application stack. Another way of thinking about it is that they are like a general practitioner doctor/dentist, while they generally don't do surgery, they can refer you to the correct specialists who can and take care of any minor/common ailments. This is also why you don't want an entire team of them is that they don't go into depth in any domain. I don't doubt that the current full-stack education path does a poor job of education on issues that specifically cross domains or when a task is better suited to a specialist.
- p4wnc6 11y ago
  The desire for this sort of flexibility is a mistake. It sounds good, but it's naive. It's sort of like saying you want a single class in your OO design to be "flexible" so you make the class into an undifferentiated mess. Having a monolith class that "does it all" is a red flag of bad design. It's truly no different when the layer of abstraction is human software developers being organized for complex business problems. Having "flexible" people whose job is a little bit of everything is a major red flag of a bad design (bad management) that took the lazy way out instead of the harder but unequivocally more successful route of actually meaningfully dividing the workload between clean interfaces and having employees mostly specialize. "Sometimes you just need somebody to work across every system" is just flat out wrong. If you find you need that, it means you've been doing things in a very wrong way and patching over it by commanding positions to be full-stack is only going to perpetuate the problem.
frcknfrckn 11y ago
Ugh. Using a coding test shouldn't be a red flag. They are an incredibly useful tool for weeding out the applicants who, quite frankly, don't know their ass from their keyboard. I've done hiring at several companies over the years, and I can honestly say that the signal-to-noise ratio for programmers tends to be very low. Even eliminating the obviously unqualified resumes leaves us with dozens of supposedly 'qualified' developers. Further followup however in most cases (probably 60 to 80% of the time, depending on the seniority of the position) reveals that the applicant is all talk, and can't solve even the simplest of problems. Eliminating that 60-80% of applicants is an issue. We could have, say, a brief phone interview with each applicant, trying to figure out which ones are garbage and which are good. But that would tie up actual employees for hours and hours, doing something that most of them would much rather not be doing. Instead, using a coding test to weed out the morons can work wonders. We set them all up with a simple problem set, and a day later it becomes very obvious which of the applicants are worth bringing in for a real interview. Now don't get me wrong - if an employer rejects you because of a spelling mistake or judges you because they say you solved a problem 'wrong', then yeah, that employer likely sucks and you should be happy to have been passed over. But rejecting an employer simply because they asked you to do a test? The only one you're hurting is yourself.
- p4wnc6 11y ago
  The flip side of this is that most companies are "garbage" as you put it, and a lot of them simply do cargo cult imitations of the more popular companies. If a startup is saying they're going to disrupt the online vegan running shoes market and then tells me they have to weed out the "80% garbage applicants" with some parochial trivia about binary search trees that let's be honest none of us has given a shit about since we passed the exam on it in undergrad, then the code test absolutely is a big red flag to nope on out of there. Since so many jobs are just shitty talent wasters, and you are just treated horribly, given poor equity terms, not paid what you're worth, etc., it unfortunately means that unless you have special knowledge that some particular job is non-shitty (like a trusted recommendation) then you're just better off erring on the side of nope.
  - frcknfrckn 11y ago
jblow 11y ago
This analogy is correct, except ... you're not Robert De Niro, and neither is almost any programmer in the valley. Just like almost no actor is Robert De Niro, and most actors are lucky to even be able to audition for commercials.
- p4wnc6 11y ago
  Your company is not Robert De Niro either! And, to boot, you don't have to be way up at the level of a Robert De Niro to be an offer-only actor. Basically, anyone with a decent and verifiable acting record is offer only. It's actually pretty common. And some actors are offer-only for some kinds of work, such as voice-over work if that's what they're known for, but not for feature films. Anyway, I think your reply totally misses the point. The companies who are so obsessed with needing to weed out the bottom 60% are themselves well in the bottom 60% of employers. What gives them the audacity to claim that certain developers are too low skilled, if the company itself is not any good? A good developer is going to see that and immediately walk away. Unless the company is already verifiably a great place to work with great technical prowess, then their obsession with getting rid of "garbage" programmers makes them seem extremely dysfunctional. (Just look at how people here on HN are speaking about other developers -- so now you're "garbage" if you're in the bottom 60%, even though that still places you well into the top 5% of humanity in terms of technological skills and quantitative thinking. It's absurd!)

by p4wnc6 11y ago

extrapickles 11y ago

Full-stack developers should be generalist in nature to make sure the issues that cross domains (front/backend, etc) are taken care of. Also, they can plug any gaps in the development that crop up from time to time (eg: someone on vacation, or next feature needs more back-end people). The downside is that they will not be spectacular or as quick at any one domain. Basically, a full-stack developers specialization is to be flexible and have knowledge and experience in working the entire application stack. Another way of thinking about it is that they are like a general practitioner doctor/dentist, while they generally don't do surgery, they can refer you to the correct specialists who can and take care of any minor/common ailments. This is also why you don't want an entire team of them is that they don't go into depth in any domain. I don't doubt that the current full-stack education path does a poor job of education on issues that specifically cross domains or when a task is better suited to a specialist.

p4wnc6 11y ago
The desire for this sort of flexibility is a mistake. It sounds good, but it's naive. It's sort of like saying you want a single class in your OO design to be "flexible" so you make the class into an undifferentiated mess. Having a monolith class that "does it all" is a red flag of bad design. It's truly no different when the layer of abstraction is human software developers being organized for complex business problems. Having "flexible" people whose job is a little bit of everything is a major red flag of a bad design (bad management) that took the lazy way out instead of the harder but unequivocally more successful route of actually meaningfully dividing the workload between clean interfaces and having employees mostly specialize. "Sometimes you just need somebody to work across every system" is just flat out wrong. If you find you need that, it means you've been doing things in a very wrong way and patching over it by commanding positions to be full-stack is only going to perpetuate the problem.

frcknfrckn 11y ago

Ugh. Using a coding test shouldn't be a red flag. They are an incredibly useful tool for weeding out the applicants who, quite frankly, don't know their ass from their keyboard. I've done hiring at several companies over the years, and I can honestly say that the signal-to-noise ratio for programmers tends to be very low. Even eliminating the obviously unqualified resumes leaves us with dozens of supposedly 'qualified' developers. Further followup however in most cases (probably 60 to 80% of the time, depending on the seniority of the position) reveals that the applicant is all talk, and can't solve even the simplest of problems. Eliminating that 60-80% of applicants is an issue. We could have, say, a brief phone interview with each applicant, trying to figure out which ones are garbage and which are good. But that would tie up actual employees for hours and hours, doing something that most of them would much rather not be doing. Instead, using a coding test to weed out the morons can work wonders. We set them all up with a simple problem set, and a day later it becomes very obvious which of the applicants are worth bringing in for a real interview. Now don't get me wrong - if an employer rejects you because of a spelling mistake or judges you because they say you solved a problem 'wrong', then yeah, that employer likely sucks and you should be happy to have been passed over. But rejecting an employer simply because they asked you to do a test? The only one you're hurting is yourself.

p4wnc6 11y ago
The flip side of this is that most companies are "garbage" as you put it, and a lot of them simply do cargo cult imitations of the more popular companies. If a startup is saying they're going to disrupt the online vegan running shoes market and then tells me they have to weed out the "80% garbage applicants" with some parochial trivia about binary search trees that let's be honest none of us has given a shit about since we passed the exam on it in undergrad, then the code test absolutely is a big red flag to nope on out of there. Since so many jobs are just shitty talent wasters, and you are just treated horribly, given poor equity terms, not paid what you're worth, etc., it unfortunately means that unless you have special knowledge that some particular job is non-shitty (like a trusted recommendation) then you're just better off erring on the side of nope.
- frcknfrckn 11y ago

jblow 11y ago

This analogy is correct, except ... you're not Robert De Niro, and neither is almost any programmer in the valley. Just like almost no actor is Robert De Niro, and most actors are lucky to even be able to audition for commercials.

p4wnc6 11y ago
Your company is not Robert De Niro either! And, to boot, you don't have to be way up at the level of a Robert De Niro to be an offer-only actor. Basically, anyone with a decent and verifiable acting record is offer only. It's actually pretty common. And some actors are offer-only for some kinds of work, such as voice-over work if that's what they're known for, but not for feature films. Anyway, I think your reply totally misses the point. The companies who are so obsessed with needing to weed out the bottom 60% are themselves well in the bottom 60% of employers. What gives them the audacity to claim that certain developers are too low skilled, if the company itself is not any good? A good developer is going to see that and immediately walk away. Unless the company is already verifiably a great place to work with great technical prowess, then their obsession with getting rid of "garbage" programmers makes them seem extremely dysfunctional. (Just look at how people here on HN are speaking about other developers -- so now you're "garbage" if you're in the bottom 60%, even though that still places you well into the top 5% of humanity in terms of technological skills and quantitative thinking. It's absurd!)