I was 16 when I first read this article, learning Java on a cheap computer in high school, and I was all too willing to call bullshit when I read it. After all, a high school student could easily...
I'd hate interviewers to dismiss [the FizzBuzz] test as being too easy - in my experience it is genuinely astonishing how many candidates are incapable of the simplest programming tasks.
I was 16 when I first read this article, learning Java on a cheap computer in high school, and I was all too willing to call bullshit when I read it. After all, a high school student could easily solve something like that, and someone applying for an actual job as an actual programmer actually couldn't?
Fifteen years later (oh wow, this article is nearing its 15th anniversary), I want to slap 16 year old me and say trust me, it's even worse than you may think. Things haven't changed in the actual process, from the POV of an interviewer. I've helped conduct a few interviews and devised/collected a few concrete programming questions to get around the "everyone knows fizzbuzz now" problem. It's still baffling how many people can't solve something relatively basic.
Not only do some programmers not know how to program, some of them pretended they can and are now architecting entire systems without the barest clue of what things are supposed to do, or what they even can do. This isn't a hypothetical "other programmers suck" thing; I've seen it at companies I worked at. I still have no idea how they got to that point.
I'm kind of curious to know how these people fail the fizzbuzz test. I wonder how many people get stuck on the "divisible" part. If you're self taught, you probably breezed through the part where...
I'm kind of curious to know how these people fail the fizzbuzz test. I wonder how many people get stuck on the "divisible" part. If you're self taught, you probably breezed through the part where you were reading about things like the modulus operator. Or maybe it's more simple - maybe they just don't understand the basic math behind it?
This highlights one of the problems w/ coding interviews, but I think that a person's response to this roadblock is very telling as it also demonstrates their way of thinking. I'd be just fine...
This highlights one of the problems w/ coding interviews, but I think that a person's response to this roadblock is very telling as it also demonstrates their way of thinking. I'd be just fine with continuing to interview a person if they just said "I don't know how to determine if it's evenly divisible by 3 or 5, so for now let me stub out this method, here's the function prototype, and here's a hard-coded implementation that passes for a few known values as proof of concept..."
This would show to me that they know how to decompose the problem at least, understand the core algorithm, and to document the areas that need further research.
I find a person who's willing to identify the areas that they know and don't know clearly, not just guess and hope that I don't notice, and talk through the problem to be a much better candidate than either the person who memorized the solution already or the person who just shuts down and says "I don't know" as the person who does the former is doing exactly what we do with real problems on a regular basis.
Ugh. The most infuriating thing in my professional career is encountering people who won't say "I don't know". Shutting down and giving up is a definite red flag, but people who try to bluster or...
not just guess and hope that I don't notice, and talk through the problem to be a much better candidate than either the person who memorized the solution already or the person who just shuts down and says "I don't know"
Ugh. The most infuriating thing in my professional career is encountering people who won't say "I don't know". Shutting down and giving up is a definite red flag, but people who try to bluster or dodge their way through a problem are the ones that infuriate me. Those are the people I inevitably end up cleaning up after later when they copy-paste some code around from StackOverflow that they don't understand.
I think this is because there are many places that value the Illusion of Competence and few places that value the Pursuit of Truth. So many people over their careers learn that it's better to...
I think this is because there are many places that value the Illusion of Competence and few places that value the Pursuit of Truth. So many people over their careers learn that it's better to bluff and find the real answer later than it is to admit not knowing the answer and being penalized.
I think a lot of this is culture-dependent. I've worked with Israelis and have noticed that they're very willing argue fiercely and be honest about what they really think and know.
I definitely think it is, and not just in terms of country/ethnicity. Individual company cultures can shape people a significant amount as well. I never really dug into enough people's past jobs...
I think a lot of this is culture-dependent
I definitely think it is, and not just in terms of country/ethnicity. Individual company cultures can shape people a significant amount as well. I never really dug into enough people's past jobs to have a definitive picture, but I strongly suspect that the first job people have and the culture there has a huge impact on their behavior for the rest of their career.
Sometimes I've met people where it's obvious. It's usually apparent as a mismatch between their personality and their behavior around managers/supervisors/clients etc. One place I worked at had a phrase for such people, they were "burn victims". Where you could see they knew the right thing to do (admit failure/ignorance, don't bullshit/lie) but they would become extremely evasive or non committal. It can be trained back out of people, but that's a long-term exercise in trust building.
First, learn to recognize toxic behavior. What's toxic? Aside from the obvious things like sexual harassment, here are a few examples. Some of these are actual toxic behaviors, some are symptoms...
First, learn to recognize toxic behavior. What's toxic? Aside from the obvious things like sexual harassment, here are a few examples. Some of these are actual toxic behaviors, some are symptoms of general toxicity.
Discouraging people from asking questions
When someone doesn't know something, they don't admit it. Or worse, they try to ad-lib a bullshit answer
Being punished (directly or indirectly) for challenging someone else's idea, especially if that person is considered more senior
Always ignoring certain team members ideas (not to be confused with having ideas challenged, or debated and then not chosen)
When someone in management says "we need X done in Y time" and the developers say "we don't think we can do that", and are then punished/berated when the deadline isn't met
And my personal favorite: After a meeting ends with something similar to "everyone good? everyone clear?" and everyone says yes or nods their head. And then immediately afterward a bunch of whispered conversations or 1:1 emails are exchanged while everyone is trying to clarify all the things they didn't understand. I have acquired a very weird skill over the course of my career. When in a meeting and I hear something I don't understand, I often raise a hand or wait for Q&A, and then I ask the obvious question. Almost without fail, someone will come up to me after meetings where this happened and thank me for asking that question because they weren't sure if they should have.
So there's some examples of toxic behavior. Now what to do about it? If it occurs, try to talk to someone about it. If they aren't at least willing to listen, talk to their/your supervisor about it. If the supervisor gives you the brush off, or just offers platitudes, or says "oh yes very concerning" but then doesn't do anything, call them out on it (discreetly). If the supervisor doesn't help you, you're likely facing a toxic work environment, and you should GTFO immediately. And when you quit, tell them very plainly and specifically the reason you're quitting, don't sugar coat it.
I realize that boiling down my advice to "if your job sucks you should quit" is a fairly privileged thing to say. Not everyone has the economic freedom to just walk away. Everyone's situation is going to be different, but the thing I want to emphasize the most is, if your job seems toxic, start looking for a way out long before you think you need to. Worse case scenario, you interview a few places and then decline an offer because your existing company got their shit together. Best case scenario, you leave a toxic environment before developing behavioral scars that you will carry with you the rest of your career. Life is too short to put up with bullshit from employers when you don't have to.
Ha ha ha! That's a unique worldview, and I'm certain you're not wrong there! I've long ago noticed that there is a certain 'programmer's machismo' which is rather pervasive. That ego that says "I...
Ha ha ha! That's a unique worldview, and I'm certain you're not wrong there!
I've long ago noticed that there is a certain 'programmer's machismo' which is rather pervasive. That ego that says "I can do anything," and "It's too hard for me to explain, I might as well just code this for you instead". And sometimes they have the skill to back it up, but most of the time I'd bet they're frantically googling answers to get them started. If you criticize their implementation they will fight you to the end of the earth and never admit that it's not pure gold even if they did an absolutely terrible job that only seems to work by complete coincidence.
But for the most part, businesses are going to value results. It doesn't matter so much if your programmers can't program if they know enough to crawl stackoverflow to find their copy-paste solution that solves your problem. If we're being honest, it's a very useful skill to have, even if it is just the bare minimum. You don't need an army of coding gurus in order to solve every problem - and in the case of real-world businesses there's a good chance that they're simply unwilling to pay what they're worth anyways.
Sure, but from my experience, the Venn diagram of people who don't know how to solve Fizzbuzz and those that respond by applying problem solving skills is just two circles. Edit: "Problem" 3 times...
I'd be just fine with continuing to interview a person if they just said "I don't know how to determine if it's evenly divisible by 3 or 5, so for now let me stub out this method, here's the function prototype, and here's a hard-coded implementation that passes for a few known values as proof of concept..."
Sure, but from my experience, the Venn diagram of people who don't know how to solve Fizzbuzz and those that respond to a problem by applying problem solving skills for a programming problem is just two circles.
Edit: "Problem" 3 times in 10 words looks super weird.
I've written code for the past 17 years. Just eight years ago, I froze during an interview with spotify when writing a recursive fibonacci function. It's only slightly more advanced than fizzbuzz...
I've written code for the past 17 years. Just eight years ago, I froze during an interview with spotify when writing a recursive fibonacci function. It's only slightly more advanced than fizzbuzz and I failed it hard.
You've got a point. I remember a few years back I had one and I was given a very simple task to do in php and was so taken aback by the request to do it in writing that I forgot what letters were...
You've got a point. I remember a few years back I had one and I was given a very simple task to do in php and was so taken aback by the request to do it in writing that I forgot what letters were supposed to look like.
It's a real shitty situation too, since the interviewers have sat in a lot of interviews before and asked the same question and gotten good answers for it. They don't feel the pressure of having...
It's a real shitty situation too, since the interviewers have sat in a lot of interviews before and asked the same question and gotten good answers for it. They don't feel the pressure of having to solve it, and they already know the answer (now if they could do it themselves if they were put to the task, that's a different story), so they feel like it should be easier than it may feel to the interviewee.
Interviewing has turned in to its own skill, where a great way to ensure success is to practice being under the pressure of having to solve random problems in a short timeframe while a bored looking person watches you. It's a skill that mostly only helps you when you try to find another job, and not on the job itself.
To be fair almost all of the problems I've administered are the same ones I passed to get the job I'm currently acting as an interviewer for. I don't know if that's often the case but it's a...
To be fair almost all of the problems I've administered are the same ones I passed to get the job I'm currently acting as an interviewer for. I don't know if that's often the case but it's a general rule that's applied to my last few jobs.
A good chunk of them get stuck on that. A bunch get ordering wrong, so it'd print Fizz on 15 (which isn't a problem in and of itself on a first run, but when you spend a lot of time not...
I wonder how many people get stuck on the "divisible" part.
A good chunk of them get stuck on that. A bunch get ordering wrong, so it'd print Fizz on 15 (which isn't a problem in and of itself on a first run, but when you spend a lot of time not understanding why it's not working and giving up...). A bunch of others get it to print Fizz\nBuzz on two lines instead of FizzBuzz on a single line. A few others don't even write the for loop. One person forgot/didn't know about loops, so he just wrote return 1, 2, 3, 4, 5, ... up to 100, then went to each individual number which fit the criteria, deleted it, and wrote fizz/buzz/fizzbuzz as appropriate. I should note the absolute obvious: this wasn't a "make it run the first time" challenge, so they had time to work on and fix their mistakes, and they just... didn't.
One standout was a guy who forgot about the modulo operator, so he abused integer truncation by writing something like if ((n / 3) * 3 == n) { print("Fizz"); } and repeated as appropriate. Neat workaround, and technically worked, but considering that he was applying for a principal engineer role and there were other issues...
Although it's not the first article where the fizz buzz test appeared (which might be this one), I believe this is the article that popularized it. Selection bias is one reason why interviewers...
Although it's not the first article where the fizz buzz test appeared (which might be this one), I believe this is the article that popularized it.
Selection bias is one reason why interviewers might have seen this a lot. People who don't get a job keep interviewing.
But programming interviews are often harder these days. I'm out of touch and don't know how much of a problem this is now.
I've interviewed countless people, and completely agree with what Joel is saying in that article. I keep trying to tell our recruiters and my manager that, but it seems that my Zoom call is muted...
I've interviewed countless people, and completely agree with what Joel is saying in that article. I keep trying to tell our recruiters and my manager that, but it seems that my Zoom call is muted whenever I try to make that point.
He says:
In fact, one thing I have noticed is that the people who I consider to be good software developers barely ever apply for jobs at all. I know lots of great people who took a summer internship on a whim and then got permanent offers. They only ever applied for one or two jobs in their lives.
I don't want to toot, but this, combined with this:
Those consist of the one guy who happened to be good, but he’s only applying for a job because his wife wants to be nearer to her family,
...exactly describe my career path. In high school I used to help a boss's son with his comp sci homework, so he knew me, recruited me to my first internship, then from there it was all being actively recruited rather than searching for jobs. I've interviewed exactly once, and that was when I moved to an entirely new area -- every other job has been them asking me to work for them rather than me asking them for a job.
I hate to express that too much because it does sound a bit like being a braggart, but the reality is that the best developers that I know don't interview for jobs, and if they do it's more of a formality than an interview.
Meanwhile, I interview 2 or 3 per week and they can't answer even the most basic problems, even if they have an MS from a prestigious university specialized in the topic at hand. Just today I interviewed somebody for a cybersecurity position, with almost 30 years of accreditations and experience on his resume, who couldn't tell me the difference between symmetric and asymmetric encryption. (this isn't ageism on my part, I graduated the same year that he did)
If you want good candidates you need to find people that are on their way up the ladder. If it looks like the candidate is making a lateral move they are far less likely to succeed than a fresh...
If you want good candidates you need to find people that are on their way up the ladder. If it looks like the candidate is making a lateral move they are far less likely to succeed than a fresh grad from a decent school.
I've found fresh grads to do well in interviews because all of the implementation details for the foundational algorithms and data structures are still fresh in their minds, and they have the free...
If it looks like the candidate is making a lateral move they are far less likely to succeed than a fresh grad from a decent school.
I've found fresh grads to do well in interviews because all of the implementation details for the foundational algorithms and data structures are still fresh in their minds, and they have the free time to grind leet-code puzzles, so they're still very familiar with those kinds of common interview questions and toy problems. In the industry, such knowledge is not frequently used directly, so it gets forgotten; most of these are abstracted away with core language methods and data types, and most situations don't require (re)writing one from scratch.
Plus, fresh grads are tend to be anywhere between a little and a lot cheaper, are easier to overwork to squeeze out a little more value (note: I don't agree with it, but it's extremely common), and don't have many external connections or reputation to leverage against you. "Safer" to hire and fire, if the role can handle a junior ramping up.
I've often heard the sentiment that to solve some problems 'you have to be a genius'; however my impression isn't that the average programmer can't solve relatively simple problems, it's that...
I've often heard the sentiment that to solve some problems 'you have to be a genius'; however my impression isn't that the average programmer can't solve relatively simple problems, it's that their code is virtually indecipherable. Not labelling variables or functions (when they are used) or structuring code in a way that makes the flow easy to understand makes bug fixing and adding new features an arduous task.
My impression is that, for some people's code, the requirement of being a genius is to read their code in the first place.
I was 16 when I first read this article, learning Java on a cheap computer in high school, and I was all too willing to call bullshit when I read it. After all, a high school student could easily solve something like that, and someone applying for an actual job as an actual programmer actually couldn't?
Fifteen years later (oh wow, this article is nearing its 15th anniversary), I want to slap 16 year old me and say trust me, it's even worse than you may think. Things haven't changed in the actual process, from the POV of an interviewer. I've helped conduct a few interviews and devised/collected a few concrete programming questions to get around the "everyone knows fizzbuzz now" problem. It's still baffling how many people can't solve something relatively basic.
Not only do some programmers not know how to program, some of them pretended they can and are now architecting entire systems without the barest clue of what things are supposed to do, or what they even can do. This isn't a hypothetical "other programmers suck" thing; I've seen it at companies I worked at. I still have no idea how they got to that point.
I'm kind of curious to know how these people fail the fizzbuzz test. I wonder how many people get stuck on the "divisible" part. If you're self taught, you probably breezed through the part where you were reading about things like the modulus operator. Or maybe it's more simple - maybe they just don't understand the basic math behind it?
This highlights one of the problems w/ coding interviews, but I think that a person's response to this roadblock is very telling as it also demonstrates their way of thinking. I'd be just fine with continuing to interview a person if they just said "I don't know how to determine if it's evenly divisible by 3 or 5, so for now let me stub out this method, here's the function prototype, and here's a hard-coded implementation that passes for a few known values as proof of concept..."
This would show to me that they know how to decompose the problem at least, understand the core algorithm, and to document the areas that need further research.
I find a person who's willing to identify the areas that they know and don't know clearly, not just guess and hope that I don't notice, and talk through the problem to be a much better candidate than either the person who memorized the solution already or the person who just shuts down and says "I don't know" as the person who does the former is doing exactly what we do with real problems on a regular basis.
Ugh. The most infuriating thing in my professional career is encountering people who won't say "I don't know". Shutting down and giving up is a definite red flag, but people who try to bluster or dodge their way through a problem are the ones that infuriate me. Those are the people I inevitably end up cleaning up after later when they copy-paste some code around from StackOverflow that they don't understand.
I think this is because there are many places that value the Illusion of Competence and few places that value the Pursuit of Truth. So many people over their careers learn that it's better to bluff and find the real answer later than it is to admit not knowing the answer and being penalized.
I think a lot of this is culture-dependent. I've worked with Israelis and have noticed that they're very willing argue fiercely and be honest about what they really think and know.
I definitely think it is, and not just in terms of country/ethnicity. Individual company cultures can shape people a significant amount as well. I never really dug into enough people's past jobs to have a definitive picture, but I strongly suspect that the first job people have and the culture there has a huge impact on their behavior for the rest of their career.
Sometimes I've met people where it's obvious. It's usually apparent as a mismatch between their personality and their behavior around managers/supervisors/clients etc. One place I worked at had a phrase for such people, they were "burn victims". Where you could see they knew the right thing to do (admit failure/ignorance, don't bullshit/lie) but they would become extremely evasive or non committal. It can be trained back out of people, but that's a long-term exercise in trust building.
Any advice for people starting out their careers, to avoid becoming a "burn victim"?
First, learn to recognize toxic behavior. What's toxic? Aside from the obvious things like sexual harassment, here are a few examples. Some of these are actual toxic behaviors, some are symptoms of general toxicity.
And my personal favorite: After a meeting ends with something similar to "everyone good? everyone clear?" and everyone says yes or nods their head. And then immediately afterward a bunch of whispered conversations or 1:1 emails are exchanged while everyone is trying to clarify all the things they didn't understand. I have acquired a very weird skill over the course of my career. When in a meeting and I hear something I don't understand, I often raise a hand or wait for Q&A, and then I ask the obvious question. Almost without fail, someone will come up to me after meetings where this happened and thank me for asking that question because they weren't sure if they should have.
So there's some examples of toxic behavior. Now what to do about it? If it occurs, try to talk to someone about it. If they aren't at least willing to listen, talk to their/your supervisor about it. If the supervisor gives you the brush off, or just offers platitudes, or says "oh yes very concerning" but then doesn't do anything, call them out on it (discreetly). If the supervisor doesn't help you, you're likely facing a toxic work environment, and you should GTFO immediately. And when you quit, tell them very plainly and specifically the reason you're quitting, don't sugar coat it.
I realize that boiling down my advice to "if your job sucks you should quit" is a fairly privileged thing to say. Not everyone has the economic freedom to just walk away. Everyone's situation is going to be different, but the thing I want to emphasize the most is, if your job seems toxic, start looking for a way out long before you think you need to. Worse case scenario, you interview a few places and then decline an offer because your existing company got their shit together. Best case scenario, you leave a toxic environment before developing behavioral scars that you will carry with you the rest of your career. Life is too short to put up with bullshit from employers when you don't have to.
Ha ha ha! That's a unique worldview, and I'm certain you're not wrong there!
I've long ago noticed that there is a certain 'programmer's machismo' which is rather pervasive. That ego that says "I can do anything," and "It's too hard for me to explain, I might as well just code this for you instead". And sometimes they have the skill to back it up, but most of the time I'd bet they're frantically googling answers to get them started. If you criticize their implementation they will fight you to the end of the earth and never admit that it's not pure gold even if they did an absolutely terrible job that only seems to work by complete coincidence.
But for the most part, businesses are going to value results. It doesn't matter so much if your programmers can't program if they know enough to crawl stackoverflow to find their copy-paste solution that solves your problem. If we're being honest, it's a very useful skill to have, even if it is just the bare minimum. You don't need an army of coding gurus in order to solve every problem - and in the case of real-world businesses there's a good chance that they're simply unwilling to pay what they're worth anyways.
Sure, but from my experience, the Venn diagram of people who don't know how to solve Fizzbuzz and those that respond
to a problemby applying problem solving skillsfor a programming problemis just two circles.Edit: "Problem" 3 times in 10 words looks super weird.
I've written code for the past 17 years. Just eight years ago, I froze during an interview with spotify when writing a recursive fibonacci function. It's only slightly more advanced than fizzbuzz and I failed it hard.
Coding interviews are … a warped reality.
You've got a point. I remember a few years back I had one and I was given a very simple task to do in php and was so taken aback by the request to do it in writing that I forgot what letters were supposed to look like.
It's a real shitty situation too, since the interviewers have sat in a lot of interviews before and asked the same question and gotten good answers for it. They don't feel the pressure of having to solve it, and they already know the answer (now if they could do it themselves if they were put to the task, that's a different story), so they feel like it should be easier than it may feel to the interviewee.
Interviewing has turned in to its own skill, where a great way to ensure success is to practice being under the pressure of having to solve random problems in a short timeframe while a bored looking person watches you. It's a skill that mostly only helps you when you try to find another job, and not on the job itself.
To be fair almost all of the problems I've administered are the same ones I passed to get the job I'm currently acting as an interviewer for. I don't know if that's often the case but it's a general rule that's applied to my last few jobs.
A good chunk of them get stuck on that. A bunch get ordering wrong, so it'd print
Fizzon 15 (which isn't a problem in and of itself on a first run, but when you spend a lot of time not understanding why it's not working and giving up...). A bunch of others get it to printFizz\nBuzzon two lines instead ofFizzBuzzon a single line. A few others don't even write theforloop. One person forgot/didn't know about loops, so he just wrotereturn 1, 2, 3, 4, 5, ...up to 100, then went to each individual number which fit the criteria, deleted it, and wrotefizz/buzz/fizzbuzzas appropriate. I should note the absolute obvious: this wasn't a "make it run the first time" challenge, so they had time to work on and fix their mistakes, and they just... didn't.One standout was a guy who forgot about the modulo operator, so he abused integer truncation by writing something like
if ((n / 3) * 3 == n) { print("Fizz"); }and repeated as appropriate. Neat workaround, and technically worked, but considering that he was applying for a principal engineer role and there were other issues...Although it's not the first article where the fizz buzz test appeared (which might be this one), I believe this is the article that popularized it.
Selection bias is one reason why interviewers might have seen this a lot. People who don't get a job keep interviewing.
But programming interviews are often harder these days. I'm out of touch and don't know how much of a problem this is now.
I've interviewed countless people, and completely agree with what Joel is saying in that article. I keep trying to tell our recruiters and my manager that, but it seems that my Zoom call is muted whenever I try to make that point.
He says:
I don't want to toot, but this, combined with this:
...exactly describe my career path. In high school I used to help a boss's son with his comp sci homework, so he knew me, recruited me to my first internship, then from there it was all being actively recruited rather than searching for jobs. I've interviewed exactly once, and that was when I moved to an entirely new area -- every other job has been them asking me to work for them rather than me asking them for a job.
I hate to express that too much because it does sound a bit like being a braggart, but the reality is that the best developers that I know don't interview for jobs, and if they do it's more of a formality than an interview.
Meanwhile, I interview 2 or 3 per week and they can't answer even the most basic problems, even if they have an MS from a prestigious university specialized in the topic at hand. Just today I interviewed somebody for a cybersecurity position, with almost 30 years of accreditations and experience on his resume, who couldn't tell me the difference between symmetric and asymmetric encryption. (this isn't ageism on my part, I graduated the same year that he did)
If you want good candidates you need to find people that are on their way up the ladder. If it looks like the candidate is making a lateral move they are far less likely to succeed than a fresh grad from a decent school.
I've found fresh grads to do well in interviews because all of the implementation details for the foundational algorithms and data structures are still fresh in their minds, and they have the free time to grind leet-code puzzles, so they're still very familiar with those kinds of common interview questions and toy problems. In the industry, such knowledge is not frequently used directly, so it gets forgotten; most of these are abstracted away with core language methods and data types, and most situations don't require (re)writing one from scratch.
Plus, fresh grads are tend to be anywhere between a little and a lot cheaper, are easier to overwork to squeeze out a little more value (note: I don't agree with it, but it's extremely common), and don't have many external connections or reputation to leverage against you. "Safer" to hire and fire, if the role can handle a junior ramping up.
I've often heard the sentiment that to solve some problems 'you have to be a genius'; however my impression isn't that the average programmer can't solve relatively simple problems, it's that their code is virtually indecipherable. Not labelling variables or functions (when they are used) or structuring code in a way that makes the flow easy to understand makes bug fixing and adding new features an arduous task.
My impression is that, for some people's code, the requirement of being a genius is to read their code in the first place.