Why Can't Programmers.. Program?(blog.codinghorror.com)
blog.codinghorror.com
Why Can't Programmers.. Program?
https://blog.codinghorror.com/why-cant-programmers-program/
17 comments
During the interview, you find yourself fending for yourself alone, your corporate framework is gone, and you realise how you miss your desk phone, and somewhere out in space a voice you can't hear is hollering: "The secret is banging those rocks together, dude!"
I don't believe this observation. I've never met a coworker or a person interviewing at my office who is unable to program these simple examples.
In fact I'm repeatedly amazed at how well people program and think about solutions to problems.
In fact I'm repeatedly amazed at how well people program and think about solutions to problems.
I've been asked to explain the following in c++
[](){}(); This doesn't test your programming skills either
[](){}(); This doesn't test your programming skills either
It’s a do-nothing lambda expression applied (executed). If it is one of many questions then it does help revealing what you know and don’t know.
What this would reveal to me is that I know that I have no interest in working for a company that thinks this is a reasonable interview question.
Exception: if the job were for a compiler engineer who needs to know how to handle even the most pathological cases, then it might be reasonable.
I’m gonna hazard a guess and say (based on the brackets at the beginning), it’s something about a lambda with no capture group?
Regardless, what’s the point in asking people how bad practice code works? Why would anyone write a lambda that does absolutely nothing?
Regardless, what’s the point in asking people how bad practice code works? Why would anyone write a lambda that does absolutely nothing?
I'm in the middle of a programming boot camp where they just blaze from topic to topic to topic, we never do any considerable project work to nail any of it down, and even though they state clearly "you need to be studying outside of this class", I know a bunch of students won't because it's 12 hours a week and billed as something you can do on top of a full time job.
So once these people graduate, OF COURSE they're going to stumble over for loops and if statements; the only think they know is how to follow along in vs code while someone builds a react app over zoom.
So once these people graduate, OF COURSE they're going to stumble over for loops and if statements; the only think they know is how to follow along in vs code while someone builds a react app over zoom.
that sounds awful.
(2007)
Why can't imperfect people be less judgmental
I would attribute some of it to translating the word problem into a logic problem, which I think Fizzbuzz is really testing. Once you see it's just one conditional testing multiples of 3 and 5, and understand it covers the whole problem, it becomes trivial.
If you can’t translate word problems into code, in what sense are you a programmer though?
What problems don’t boil down to that?
What problems don’t boil down to that?
Here they are talking about putting a significant time limit on solving the problem. I'd classify myself as being a reasonable programmer (and I get paid for it), but I generally don't dive from reading a specification into complete code within 15 minutes regardless of how simple the problem is. You spend time thinking about edge cases that you will have to make accommodation for, areas where the requirements are not well defined and need clarification and also talking to the person who wrote the requirements to check your understanding. specifications are rarely perfect, if they were, they would be code that could run.
I unfortunately see a lot of developers who struggle with solving problems and want you to solve it so they can simply fill in the blanks. Kind of a code-typist.
The other developer of this type that I've seen can only connect cloud services together.
The other developer of this type that I've seen can only connect cloud services together.
I'm just saying the tricky part is not writing the code, as it is assumed at the surface level. I have done interviews and have accepted explanatory answers for coding problems because it is obvious sometimes that they know the underlying logic that can be translated into whatever language/framework.
I'm mostly self taught other than some basic in high school and R in university. It's taken me years of working on different kinds of projects, reading tons of books and practicing to the point where i became competent enough to work on a decently large project from start to finish and complete something.
I don't feel like i really went from programming stuff to knowing how to program until after i'd finished a bunch of smaller programs in a few different languages. Like a lot. Years worth.
There came a point though where, even if i was working with an unfamiliar language, once the syntax is out of the wat, i started thinking about the problems i was working on differently. I understand now how computers work on a more fundamental level and what the code is actually doing under the hood. What's actually happening when i declare a variable, define a function or compile some code.
Before i understood that stuff I realize now i was always kinda just shooting in the dark only vaguely understanding what i was actually doing.
But, it took a long time. I guess the very first time i ever programmed was i dunno at like 5 or 6 years old when i managed to write a loop on the atari. It took almost two decades learning on and off for me to actually understand what i was doing.
I'm still not sure if i'd feel qualified enough to apply for a professional programming job.
I don't feel like i really went from programming stuff to knowing how to program until after i'd finished a bunch of smaller programs in a few different languages. Like a lot. Years worth.
There came a point though where, even if i was working with an unfamiliar language, once the syntax is out of the wat, i started thinking about the problems i was working on differently. I understand now how computers work on a more fundamental level and what the code is actually doing under the hood. What's actually happening when i declare a variable, define a function or compile some code.
Before i understood that stuff I realize now i was always kinda just shooting in the dark only vaguely understanding what i was actually doing.
But, it took a long time. I guess the very first time i ever programmed was i dunno at like 5 or 6 years old when i managed to write a loop on the atari. It took almost two decades learning on and off for me to actually understand what i was doing.
I'm still not sure if i'd feel qualified enough to apply for a professional programming job.
[deleted]
None of the code/design/architecture I wrote this year will help convince an interviewer I can program. Can’t even show it to them because it breaks the apples to apples system they are trying to do with their robotic standardized questions. Still have to play the game: leetcode drills, whiteboard practice, learning to talk and make jokes while white boarding, re-learning Java for the sole reason of needing it for interviews, picking a good “biggest flaw” ahead of time, etc. I wish I got to write algorithms all day but if you actually want to learn to contribute to a project, design and just reading code trumps algorithms, especially since the algorithms can just be looked up the once-per-year they are needed
There are (edit:almost) zero programmers who can’t write a while loop. There are just 199/200 people who are stressed out by the bizzaro interview process that was designed by aliens to promote leetcode. There are however millions of programmers who can’t write maintainable or readable code
There are (edit:almost) zero programmers who can’t write a while loop. There are just 199/200 people who are stressed out by the bizzaro interview process that was designed by aliens to promote leetcode. There are however millions of programmers who can’t write maintainable or readable code
I interviewed at Apple once. In the second technical call on codepad I was struggling with something really basic in Python (which I have 15+ years experience with) due to nerves and the general weirdness of the situation. My struggling stressed me out, which made it harder to concentrate, which stressed me out, etc. While I was struggling the interviewer said "come on, if you can't answer this then how am I going to convince anyone you're a good programmer?".
That spun me out and I crashed even harder. In his eyes I'm one of those 199 people who "can't even code".
Fuck 'em, if coding is knowing how to implement weird palindrome-related algorithms in a completely alien browser-based IDE (if you can call it that) over a call with a several second delay in your kitchen at 9pm local-time after a hard days work then maybe I can't code.
That spun me out and I crashed even harder. In his eyes I'm one of those 199 people who "can't even code".
Fuck 'em, if coding is knowing how to implement weird palindrome-related algorithms in a completely alien browser-based IDE (if you can call it that) over a call with a several second delay in your kitchen at 9pm local-time after a hard days work then maybe I can't code.
That sounds like an absolutely horrible experience. I detest live programming exercises for the same reason. From both a candidate perspective and mine as a hiring manager now.
At my current place (and before as well) we give the candidates a 'take home test'. The problem is a bit larger than FizzBuzz, so that we can see how they would structure things, if they can write clean code, write tests etc. The 'take home' nature solves quite a few of the problems you mentioned, both for the candidate and us if you ask me. And even there you have to be careful that things don't get out of hand. Nobody good who currently has a job is going to spend any time on a take home test that the employer expects them to spend hours upon hours on over a short period of time.
Of course there are always managers that fear it's too easy to cheat but if you ask me, that's either never happened to us or if so, it was very clear after talking to the candidate in person about their code, that we wouldn't hire them anyway, so at best they cheated us out of some interview time.
At my current place (and before as well) we give the candidates a 'take home test'. The problem is a bit larger than FizzBuzz, so that we can see how they would structure things, if they can write clean code, write tests etc. The 'take home' nature solves quite a few of the problems you mentioned, both for the candidate and us if you ask me. And even there you have to be careful that things don't get out of hand. Nobody good who currently has a job is going to spend any time on a take home test that the employer expects them to spend hours upon hours on over a short period of time.
Of course there are always managers that fear it's too easy to cheat but if you ask me, that's either never happened to us or if so, it was very clear after talking to the candidate in person about their code, that we wouldn't hire them anyway, so at best they cheated us out of some interview time.
> I interviewed at Apple once. In the second technical call on codepad I was struggling with something really basic
I had a very similar experience. Moreover, on the phone call there seemed to be some kind of soft ticking sound in the background, like a clock. It was very distracting. I wonder if the interviewer was actually timing me.
I had a very similar experience. Moreover, on the phone call there seemed to be some kind of soft ticking sound in the background, like a clock. It was very distracting. I wonder if the interviewer was actually timing me.
It's not bizzaro if you think like where the concept originated. It comes from FAANG size companies that do thousands of interviews and need a "standardized" way to evaluate candidates, compare them to each other. Very similar to how SAT scores are supposed to evaluate & compare millions of students.
Smaller companies should absolutely break away from this way of interviewing to find developers that can do great work for them but the pressure (or envy?) to conform is too strong I guess.
Smaller companies should absolutely break away from this way of interviewing to find developers that can do great work for them but the pressure (or envy?) to conform is too strong I guess.
> It comes from FAANG size companies that do thousands of interviews and need a "standardized" way to evaluate candidates, compare them to each other.
The irony is that the founders and initial employees of these companies were never interviewed in this way. They were mostly just school friends. So it's highly dubious whether these specific hiring practices were even crucial to the success of those companies. People are emulating the wrong things and just cargo culting.
The irony is that the founders and initial employees of these companies were never interviewed in this way. They were mostly just school friends. So it's highly dubious whether these specific hiring practices were even crucial to the success of those companies. People are emulating the wrong things and just cargo culting.
Haha yes exactly! The issue is that the list of people you have worked with and can trust without some vetting process turns out not to be that long. So after a while, you run out of those people and have to resort to some kind of interviewing if you need dozens of hundreds of engineers.
> UPDATE: If you think that I just claimed that 199 out of 200 working programmers cannot code, stop immediately and either read my follow-up explaining the math, or read Joel’s article on why companies aren’t as picky as they think they are. Thank you.
http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....
I will note the person making this observation is apparently incapable of securing their website with SSL!
http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....
I will note the person making this observation is apparently incapable of securing their website with SSL!
That's an http page, why would you expect it to be encrypted with SSL??
There is a huge difference between knowing syntax and being able to write code. I have even seen senior developers write very convoluted code because they couldn't break down the problem in its simplest components.
I would say that the ability to write good code is related to problem solving capacity and intelligence.
I would say that the ability to write good code is related to problem solving capacity and intelligence.
And I'm fairly sure I've seen people stumble over the reverse direction: Being optimistic that they remember the syntax for a language they haven't used in a while, and then in a stress situation failing to remember basics.
Someone with experience in a few languages has no difficulty reading code in a lot of languages, and can get going in them quite quickly, but the first few hours/days are going to involve a lot of looking up trivial things, especially if starting with an empty page instead of tweaking in existing code.
Someone with experience in a few languages has no difficulty reading code in a lot of languages, and can get going in them quite quickly, but the first few hours/days are going to involve a lot of looking up trivial things, especially if starting with an empty page instead of tweaking in existing code.
The below github account is making fun of the concept 'Enterprise code' and contains an Enterprise-level FizzBuzz solution. I have never seen that much code do so little.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Been pitching in with the Java backends as a frontender at work and the impl/interface distinction on a per singleton basis in just... why? It's a fucking singleton.
Presumably, so they can stub out the singleton for testing. It makes sense, sometimes, like the way your global database is a singleton that you really don't want on every test.
But in a lot of cases it's overkill and makes everything harder. Following a rule to always do it is simple but using your judgement is better. The best code minimizes side effects and reduces stubs and fakes.
But in a lot of cases it's overkill and makes everything harder. Following a rule to always do it is simple but using your judgement is better. The best code minimizes side effects and reduces stubs and fakes.
well it has tests, this is a plus!
This submission should be labeled (2007).
Or better, bury the article in an unmarked grave and never see it again. Few people have done more harm to hiring in the industry than Atwood and Spolsky.
Or better, bury the article in an unmarked grave and never see it again. Few people have done more harm to hiring in the industry than Atwood and Spolsky.
Oh I’m not sure what you mean but certainly sounds interesting. Can you expand a bit on Atwood and Spolsky’s influence on hiring?
"A new study from North Carolina State University and Microsoft finds that the technical interviews currently used in hiring for many software engineering positions test whether a job candidate has performance anxiety rather than whether the candidate is competent at coding." https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/
Programmers can program, but they usually aren't stage performers. Using auditions to evaluate non-performers is doomed to failure, predictably.
Programmers can program, but they usually aren't stage performers. Using auditions to evaluate non-performers is doomed to failure, predictably.
I agree that programmer interviews (especially ones with whiteboarding) do have a degree of "stage performance" that programmers aren't used to, but what exactly is the better alternative?
Take homes might work if your company isn't very large but that doesn't scale.
Asking domain specific questions can easily have as many false negatives as Ds/A questions - Do you really need to have a precise, perfect definition of what a closure is in JavaScript on the tip of your tongue to be an effective front-end developer in 2021?
Domain specific questions are worse than algorithmic questions IMO because no matter how well you know a subject, there's always going to be pockets you might have missed.
What if you took a more holistic approach and actually went through a person's projects/Github? That's more time consuming and harder to be consistently objective with. Plus, then you get the crowd of people who say you shouldn't have to have side projects to be a programmer on your case.
There's going to be some level of anxiety inherent in interviewing, period. I do agree that making people write code on whiteboards is not good though. They should at least be given a somewhat similar environment to what they use day to day, like being able to type.
I say this as someone who has absolutely bombed in person interviews before on the same level (probably worse) as the guy getting tripped up by basic Python elsewhere in this thread.
Take homes might work if your company isn't very large but that doesn't scale.
Asking domain specific questions can easily have as many false negatives as Ds/A questions - Do you really need to have a precise, perfect definition of what a closure is in JavaScript on the tip of your tongue to be an effective front-end developer in 2021?
Domain specific questions are worse than algorithmic questions IMO because no matter how well you know a subject, there's always going to be pockets you might have missed.
What if you took a more holistic approach and actually went through a person's projects/Github? That's more time consuming and harder to be consistently objective with. Plus, then you get the crowd of people who say you shouldn't have to have side projects to be a programmer on your case.
There's going to be some level of anxiety inherent in interviewing, period. I do agree that making people write code on whiteboards is not good though. They should at least be given a somewhat similar environment to what they use day to day, like being able to type.
I say this as someone who has absolutely bombed in person interviews before on the same level (probably worse) as the guy getting tripped up by basic Python elsewhere in this thread.
> what exactly is the better alternative?
When people ask this question, they almost always mean, what's the alternative to one kind of testing that's still a test?
Nobody seems willing to accept the answer that interviews shouldn't be tests. The demand for testing assumes the idea, the self-fulfilling prophesy, that 99% of programmers can't program. If you start with that assumption, then you'll always end up wanting some kind of test. But it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world.
We know that interviews, not just programmer interviews but interviews in general, are poor predictors of performance. The best predictor of future performance is past performance. In other words, experience.
Our industry is also insanely afraid of the proverbial "bad hire". It's a pervasive mental illness. There's a failure to recognize that perfection is unattainable, and mistakes are a fact of life. Look of professional sports: they spend vastly more time and money on talent evaluation than tech, and yet pro sports teams get talent evaluation totally wrong all the time! Bad draft picks, bad trades, bad contracts, etc. They just accept it, deal with it, and move on. Nobody has the perfect programmer hiring method, and nobody ever will. It's a crapshoot. And just because a programmer "can program" doesn't mean they're not a bad hire. They could still write buggy, overengineered code, they could be a bad teammate, they could be a sexual harasser, or have any number of other issues. Or they could leave for another jobs a few months after getting hired. There's no way to guarantee a good hire.
It's a mistake to turn hiring into an "algorithm". It's not a programming problem, it's a human problem. Programmers are humans, not robots, and they're not going to perform robotically in interviews. The only way to truly know is to give someone a chance. They may unpleasantly surprise you, but they may also pleasantly surprise you.
When people ask this question, they almost always mean, what's the alternative to one kind of testing that's still a test?
Nobody seems willing to accept the answer that interviews shouldn't be tests. The demand for testing assumes the idea, the self-fulfilling prophesy, that 99% of programmers can't program. If you start with that assumption, then you'll always end up wanting some kind of test. But it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world.
We know that interviews, not just programmer interviews but interviews in general, are poor predictors of performance. The best predictor of future performance is past performance. In other words, experience.
Our industry is also insanely afraid of the proverbial "bad hire". It's a pervasive mental illness. There's a failure to recognize that perfection is unattainable, and mistakes are a fact of life. Look of professional sports: they spend vastly more time and money on talent evaluation than tech, and yet pro sports teams get talent evaluation totally wrong all the time! Bad draft picks, bad trades, bad contracts, etc. They just accept it, deal with it, and move on. Nobody has the perfect programmer hiring method, and nobody ever will. It's a crapshoot. And just because a programmer "can program" doesn't mean they're not a bad hire. They could still write buggy, overengineered code, they could be a bad teammate, they could be a sexual harasser, or have any number of other issues. Or they could leave for another jobs a few months after getting hired. There's no way to guarantee a good hire.
It's a mistake to turn hiring into an "algorithm". It's not a programming problem, it's a human problem. Programmers are humans, not robots, and they're not going to perform robotically in interviews. The only way to truly know is to give someone a chance. They may unpleasantly surprise you, but they may also pleasantly surprise you.
I'm with you that there is way more to being an effective developer than just being able to write code. I feel very strongly about that.
But that's not a compelling argument against doing coding assessments in interviews, I could see it as an argument in favor of also having behavioral questions.
>it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world.
There's no standardized licensing for our profession. The closest thing we have really is Computer Science degrees which, as the article this thread is about points out, doesn't churn out job ready programmers unless they're also doing independent study.
Evaluating on past performance alone would be impossible. What if this is to be their first job? What if their previous job won't tell you anything other than "Yes this person worked here" because they're scared of getting sued?
If you're relying on a candidate's self description of their past performance you've just switched out selecting for people who can perform under pressure to selecting for people who are good at bullshitting/charming.
To become a lawyer, you have to sit for a very intense and stressful exam that you took two extra years of schooling for. There are similar processes in place for becoming a doctor, after even more schooling and forced on the job training.
Some form of assessing coding skills is going to happen just like some form of skill assessment happens with any knowledge worker job. It'll just either happen during interviews or eventually through some kind of certification process.
The example you gave of professional sports is odd to me- Yes, they have to deal with it when they make bad hiring choices just like most organizations do but they still clearly feel that it's worth the effort to be very selective in their hiring process.
There is an opportunity cost to "giving someone a chance" - even if you moved to a very permissive system where it's easy in, easy out people still have to onboard that employee and go through the process of firing them. If a simple coding assessment had revealed they can't even complete very basic tasks it would avoid taking up company resources.
This isn't a defense of forcing someone to write perfect code on a whiteboard, I just think it's absolutely valid to ask someone to write code in an interview setting.
But that's not a compelling argument against doing coding assessments in interviews, I could see it as an argument in favor of also having behavioral questions.
>it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world.
There's no standardized licensing for our profession. The closest thing we have really is Computer Science degrees which, as the article this thread is about points out, doesn't churn out job ready programmers unless they're also doing independent study.
Evaluating on past performance alone would be impossible. What if this is to be their first job? What if their previous job won't tell you anything other than "Yes this person worked here" because they're scared of getting sued?
If you're relying on a candidate's self description of their past performance you've just switched out selecting for people who can perform under pressure to selecting for people who are good at bullshitting/charming.
To become a lawyer, you have to sit for a very intense and stressful exam that you took two extra years of schooling for. There are similar processes in place for becoming a doctor, after even more schooling and forced on the job training.
Some form of assessing coding skills is going to happen just like some form of skill assessment happens with any knowledge worker job. It'll just either happen during interviews or eventually through some kind of certification process.
The example you gave of professional sports is odd to me- Yes, they have to deal with it when they make bad hiring choices just like most organizations do but they still clearly feel that it's worth the effort to be very selective in their hiring process.
There is an opportunity cost to "giving someone a chance" - even if you moved to a very permissive system where it's easy in, easy out people still have to onboard that employee and go through the process of firing them. If a simple coding assessment had revealed they can't even complete very basic tasks it would avoid taking up company resources.
This isn't a defense of forcing someone to write perfect code on a whiteboard, I just think it's absolutely valid to ask someone to write code in an interview setting.
> There's no standardized licensing for our profession.
Most professions have no licensing. Doctors and lawyers are the exception, not the norm. This is because doctors have your life in their hands, and lawyers have your freedom in their hands. But usually an App Store app won't kill you or send you to jail. Moreover, licensing is not actually standardized! Every state in the United States has its own different licensing requirements. There are no national or international standards. It's a local government issue. Every time people bring up licensing, they miss these basic facts.
> What if this is to be their first job?
Obviously entry-level jobs and/or internships would hire differently. The crazy thing about software engineering is that they have fresh college grads and 10 year veterans in the same applicant pool for the same jobs! This should never ever happen.
> selecting for people who are good at bullshitting/charming
We already do this to some extent, because "leetcode" tests are bullshit. Anyway, this is just the insane paranoia of the tech industry. Yes, there are liars out there, but it's ridiculous to treat every job candidate like a criminal, guilty until proven innocent. Even our legal system has more respect for people. Remember, hiring is a two-way street: you have to convince the candidate to agree to work for you. Treating the candidate like a liar is not a good first impression. Imagine if you tried that method with dating — you'd never get a second date! You know, there are a lot of bad bosses in the world. I would argue there are more bad bosses than there are bad programmers, because programmers get promoted to management without having any experience or training for management. How about we have job candidates grill the interviewer? If you think "whiteboarding" is bad, then the hiring manager can do a take-home test given by the candidate. ;-) Nothing worse than getting hired by a bad manager.
> they still clearly feel that it's worth the effort to be very selective in their hiring process
I never said companies shouldn't be selective in their hiring process. I actually think they're too unselective in their hiring process. It's a waste of everyone's time to do a whole bunch of "screening" interviews of basically everyone who applies. Instead, companies should only interview the top candidates based on experience and skills, and spend most of their time trying to evaluate those few top candidates.
I would have less objection to doing coding as part of the hiring process if coding tests weren't used so ruthlessly to screen out candidates. Maybe it could be the final step before hiring someone. (Even there, you wouldn't use a "FizzBuzz" test, those just dumb.) But hardly any company uses coding tests in that way. Mass testing of candidates is nothing more than a test of performance anxiety. Mass interviews are just begging for some trivial matter to decide who gets hired.
Let me put it this way: if hiring is based mainly on the interview process and not on the résumé, then it's precisely the bullshitters/charmers you were worried about who will get hired, because those are the kind of people who are best at interviews. And the ability to grind on LeetCode doesn't make you a good programmer.
Most professions have no licensing. Doctors and lawyers are the exception, not the norm. This is because doctors have your life in their hands, and lawyers have your freedom in their hands. But usually an App Store app won't kill you or send you to jail. Moreover, licensing is not actually standardized! Every state in the United States has its own different licensing requirements. There are no national or international standards. It's a local government issue. Every time people bring up licensing, they miss these basic facts.
> What if this is to be their first job?
Obviously entry-level jobs and/or internships would hire differently. The crazy thing about software engineering is that they have fresh college grads and 10 year veterans in the same applicant pool for the same jobs! This should never ever happen.
> selecting for people who are good at bullshitting/charming
We already do this to some extent, because "leetcode" tests are bullshit. Anyway, this is just the insane paranoia of the tech industry. Yes, there are liars out there, but it's ridiculous to treat every job candidate like a criminal, guilty until proven innocent. Even our legal system has more respect for people. Remember, hiring is a two-way street: you have to convince the candidate to agree to work for you. Treating the candidate like a liar is not a good first impression. Imagine if you tried that method with dating — you'd never get a second date! You know, there are a lot of bad bosses in the world. I would argue there are more bad bosses than there are bad programmers, because programmers get promoted to management without having any experience or training for management. How about we have job candidates grill the interviewer? If you think "whiteboarding" is bad, then the hiring manager can do a take-home test given by the candidate. ;-) Nothing worse than getting hired by a bad manager.
> they still clearly feel that it's worth the effort to be very selective in their hiring process
I never said companies shouldn't be selective in their hiring process. I actually think they're too unselective in their hiring process. It's a waste of everyone's time to do a whole bunch of "screening" interviews of basically everyone who applies. Instead, companies should only interview the top candidates based on experience and skills, and spend most of their time trying to evaluate those few top candidates.
I would have less objection to doing coding as part of the hiring process if coding tests weren't used so ruthlessly to screen out candidates. Maybe it could be the final step before hiring someone. (Even there, you wouldn't use a "FizzBuzz" test, those just dumb.) But hardly any company uses coding tests in that way. Mass testing of candidates is nothing more than a test of performance anxiety. Mass interviews are just begging for some trivial matter to decide who gets hired.
Let me put it this way: if hiring is based mainly on the interview process and not on the résumé, then it's precisely the bullshitters/charmers you were worried about who will get hired, because those are the kind of people who are best at interviews. And the ability to grind on LeetCode doesn't make you a good programmer.
[deleted]
This is a solved problem. Since 2007, everyone knows the answer to this: the search population is dominated by the ones who can’t.
It’s the same as when you get that bag of mixed nuts and pick out a bunch, put the almonds back in and eat only the pistachios. About ten minutes in, your search for pistachios becomes ever so hard. You take a handful of almonds out, put them back in and repeat, barely seeing a pistachio.
It’s the same as when you get that bag of mixed nuts and pick out a bunch, put the almonds back in and eat only the pistachios. About ten minutes in, your search for pistachios becomes ever so hard. You take a handful of almonds out, put them back in and repeat, barely seeing a pistachio.
Programmers with degrees claiming years of experience who can't write FizzBuzz - Is this true as of 2021 ?
It would be astonishing to me if it's true though.
It would be astonishing to me if it's true though.
I would imagine not, in part because of how much fizzbuzz is a meme now they’ve probably been exposed to it.
...because humanity seems to have gotten a lot more intelligent in the last fourteen years?
I’ve been sitting in some interviews for the first time from the other side, and there are a handful of observations I’ve made both from the candidates we’ve interviewed and myself. Just to note, this is at a typical boring enterprise type company. No leetcode or take homes. The interviews primarily consist of mostly very simple “trivia” type questions that someone with the bare minimum experience with our stack should understand.
One of the big things I’ve noticed, is people don’t know what they haven’t used. Something pretty common I’ve noticed in some candidates is that when they’re asked how they would X they start going into some over engineered proprietary framework or library that they’ve used at their past company rather the more fundamental answer we’re looking for. They never really get the chance to learn things because their first job out of school has them working on problems that require a very limited skill sort or ability. I can’t speak to how 2007 was, but I wonder how many programmers couldn’t figure out fizzbuzz because they simply never had to use modulo division. I’ve never had to use the modulo operator in my time building CRUD apps and frankly I had never heard of it until I had heard of fizzbuzz many years ago. Keep in mind that many people come from non traditional background and do not have any sort of technical education besides what they learned themselves and that for a number of business that’s been enough to hire them to maintain whatever business applications they’re working on.
I myself am not a particularly good developer either. Though I could pass a fizzbuzz test there’s no way I’m making it through even some of the easier leetcode problems. And so, at this point I’m looking for a way out of the industry. But when you look at how much money even no name companies will pay for a job that is not gatekept by expensive credentials and can be learned on your own time, you’d be dumb not attempt run towards it. Note I’m not arguing for a credentialized gate keeping, I personally can’t stand credentialism, but there are a wide variety of people rushing into the field who can make decent money even if they’re not particularly good as long as they’re providing whatever the employer things is business value.
One of the big things I’ve noticed, is people don’t know what they haven’t used. Something pretty common I’ve noticed in some candidates is that when they’re asked how they would X they start going into some over engineered proprietary framework or library that they’ve used at their past company rather the more fundamental answer we’re looking for. They never really get the chance to learn things because their first job out of school has them working on problems that require a very limited skill sort or ability. I can’t speak to how 2007 was, but I wonder how many programmers couldn’t figure out fizzbuzz because they simply never had to use modulo division. I’ve never had to use the modulo operator in my time building CRUD apps and frankly I had never heard of it until I had heard of fizzbuzz many years ago. Keep in mind that many people come from non traditional background and do not have any sort of technical education besides what they learned themselves and that for a number of business that’s been enough to hire them to maintain whatever business applications they’re working on.
I myself am not a particularly good developer either. Though I could pass a fizzbuzz test there’s no way I’m making it through even some of the easier leetcode problems. And so, at this point I’m looking for a way out of the industry. But when you look at how much money even no name companies will pay for a job that is not gatekept by expensive credentials and can be learned on your own time, you’d be dumb not attempt run towards it. Note I’m not arguing for a credentialized gate keeping, I personally can’t stand credentialism, but there are a wide variety of people rushing into the field who can make decent money even if they’re not particularly good as long as they’re providing whatever the employer things is business value.