Why programmers cant program

What is certainly true though is that most candidates are not suitable for anything above entry-level positions. I think we can all agree that during the recruiting process, we turn away a lot of people with average resumes, but with impressive programming skills. One problem is that for each position you can get even hundreds of resumes. It is impossible to interview all or even most of the candidates who apply. Ok, but who is going to interview the candidates who made it through the screening process?

You need someone who knows what they are talking about, probably you need to pull one of your lead programmers away from their work to interview the candidates. Most of the programmers that I know complain about this part of their job because it pulls them them away from responsibilities that they were hired for. When this happens, HR tries to minimize the number of interviews in which a programming specialist need to be present.

The vast divide between those who can program and those who cannot program is well known. I assumed anyone applying for a job as a programmer had already crossed this chasm. Apparently this is not a reasonable assumption to make. Apparently, FizzBuzz style screening is required to keep interviewers from wasting their time interviewing programmers who can't program.

Lest you think the FizzBuzz test is too easy — and it is blindingly, intentionally easy — a commenter to Imran's post notes its efficacy:. 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.

Maybe it's foolish to begin interviewing a programmer without looking at their code first. At Vertigo, we require a code sample before we even proceed to the phone interview stage. And our on-site interview includes a small coding exercise.

I find it truly surprising. From that post:. Everybody has to start somewhere. But I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. So, make sure you practice programming. View all posts by mooreds.

Like Like. Sometimes the tooling changes and opens up the workforce. Folks with older tooling or platforms may or may not be able to attract talent.

You want things to be better? Unions and certifications. While i was studying design, i also studied comp sci in my spare time had real high-end mentors for both paths. Programmers need to be able to communicate about the code they're writing to collect requirements, explain problems, etc. Do you have any good data on this? Maybe those people are right! A programmer is someone who programs.

If one cannot program they cannot be a programmer. It doesn't take a degree in data science to figure this out. Some of these are or can be included in the system design interview. For the rest, is there an objective way to ask the same question of each candidate that won't eventually be gamed with pre-canned answers on leetcode?

Agreed, but you can still find fairly simple questions related to the domain they should know to weed out a lot of people. For applications that will use a lot of SQL back end, I will ask the person to describe what a Left Outer Join does what will it produce. That question lets me know if you have done any SQL beyond a basic query or basic inner join.

RyanDagg on Aug 23, parent prev next [—]. Not knowing about a rarely used operator isn't that big of a deal, but the "hard" part of fizzBuzz is trivial in the couple of languages I am proficient in. If so many well paid people at big companies can't do it, maybe that's an indicator that it's absolutely not a good screen at al The history of FizzBuzz was that it was a screening question for webdevs to work on a bugtracking tool.

I agree, but the test is also dreadfully easy. Literally it's hard to see why anyone would fail. The more interesting question is why did they fail? Why is this a bad barometer or what is making this a bad barometer despite it being so easy? If you took a career software engineer that would otherwise fail a fizzbuzz interview and put him alone in a room with a computer for an unlimited amount of available time and made it known that he's just solving a fizzbuzz question for fun and not being judged for a future career I'm willing to bet that he will could walk out of that room in reasonable time with a working fizzbuzz.

If you did this for individuals with the exact same credentials as the person above I'm pretty sure you could get 99 people who walk out of that room with a working fizz buzz in reasonable time. As a software developer, I spend much, much more time reading code, trying to understand code, looking for bugs in code, and tweaking existing code, than I do writing totally new software applications. Although I agree it is surprising that many people can't reason through fizzbuzz, it is very possible to make valuable contribution to a code base in a language that you don't have the syntax for the "main" function memorized.

This would be a fascinating, probably more reliable way to test someone: ask them to explain in as much detail as possible what a code sample did - what problem it appeared to be solving, and what edge cases it attempted to handle as well as perhaps some it would have failed to handle.

If you provide them a good sample, the function names and behaviors should give a really good sense of direction to the candidate, and the harder questions would be answered by the details of the code. At this point, coding is the easy part for many applications[1].

Developers end up spending much more time trying to understand what it is they are being tasked to build by either understanding the business or clarifying requirements. Jun8 on Aug 23, prev next [—]. Is it really relevant? My experience with candidates I've seen is that the ratio of 1 to 2 is about equal! Depending on the number and the of errors, 1 could be worrisome but the issue that people generally bring up in discussions on FizzBuzz is the utter incredulity of 2.

I'm mechanically challenged and have never changed a tire, yet , if asked to do so, will make some movements that are roughly aligned with the goal, albeit may be laughable to more knowledgeable people. Ditto for cooking a simple dish, e. I think this residual knowledge is acquired by osmosis through being around people or watching TV doing the task.

So, the most unnerving aspect of 2 to me is that it shows that the candidate does not even has this residual knowledge about programming. As a counterpoint, your real-world equivalent example is kind of bad. A normal person who had never changed a tire and got a flat would, as step 1, Google or YouTube "how to change a tire" and follow the steps.

Or perhaps look in the owner's manual. Similarly, in real-world programming if you get to a requirement to do something you've never seen before, the first step most programmers I've worked with would take is looking up potential solutions that already exist.

The problem, of course, is that if you're in the middle of an interview and someone throws a programming problem at you, your first instinct to go look up potential solutions would generally lose you the job opportunity.

A better test of real-world skill needed would be to give them some variant of fizzbuzz code then ask them what it does, or put a bug in it and ask them to find the bug and fix it based on the expected output of the function. I think "roughly aligned with the goals" is ok - from having worked with some people trying to start out in software development the biggest hurdles are in trying to apply the knowledge to the problem at hand.

That some people really struggle with properly defining the problem and what needs done in such a way that it's tractable. What you are measuring here is the skill of speculating.

Let's assume everyone gets a job in industry. Those people who couldn't program their way out of a paper bag in the first interview probably went on to solve whatever issue it is they were having that day nerves, not ever having heard of modulo etc and subsequently get more practiced by at least the 3rd interview. All of a sudden they can magically program. I just don't buy the premise that these people can't program, get rejected from every interview, give up and drop out of industry.

I'd say the vast majority of them get jobs. And you're hiring filter can't calibrate for how the previous interviews have set the current candidate up for your interview. If you could be a fly on the wall for every interview the candidate you just hired had done, there would likely be some in which you would have assessed "this person isn't capable of doing the job".

I can usually tell when I lose an interviewer. They stop paying attention and start fiddling with their smartphone. Every time I start a new job hunt, I have to fail a few interviews before I get practiced up again. Since interviewing is a skill and interview skill is used as a proxy for job skill and interview skill is a function of recent interview experience, job experience, and your mix of personality traits, and only two of those are roughly stable.

Job experience is a slowly changing dimension, but recent interview experience changes very rapidly and it has a huge effect on interview skill, and the interviewer has no way to calibrate for it. Instead they always try to calibrate for job experience. Interviewers also don't have any hope of calibrating for your mix of personality traits. The whole thing is basically a crapshoot.

But I take comfort in that. I don't ever feel bad if I get rejected. I just see the process as essentially random. Was a fairly new engineer, when an engineer with a few years of experiencein the office, who was taking classes on the employer's dime towards a masters degree, asked me for assistance. She was trying to run a C program she'd created, but it wouldn't run. I asked if she'd compiled it. She asked what a compiler was.

How can a person could survive in an office where C was the main language, and be taking courses that assumed familiarity with C, and still not know what a compiler is? Turned out she was very skilled at taking credit for other people's work. Hitton on Aug 23, parent next [—]. To be honest such scenario is not so hard to imagine. When I think of my studies, it was probably some introduction to Java, we learned how to use javac during first lesson, but never used it since, because we just clicked button in IDE.

Someone who missed the lesson, might never noticed he misses basics. With advanced build systems in some companies, someone who arrives from scripting language, is shown build system and told to look up the syntax might not ever realize the gap in his knowledge and at the same time might even be productive part of the team. This is so true. Mostly due to not remembering or even knowing about the modulo operator or a suitable workaround. I've had the same experience.

I can forgive an interviewee for not remembering what symbol the modulo operator is, but not for not knowing what it is in the first place. I've had the same experience asking applicants to reverse a string in a language of their choice. I can't help myself: In Python to reverse a string or other sequence In [1]: "? True, but remember that: Explicit is better than implicit. Readability counts. If mod isn't something needed for whatever their normal work is, is it a valid test? Or are you potentially throwing away otherwise good candidates because of it?

In my experience one sees roughly similar results with: "Write a function which counts the number of a's in the input string.

Print out each word which appears more than 3 times in the array. Print out each word which is in exactly one of the arrays. These are toy problems for difficulty but they're not "implement the rules to a children's game"; with a few seconds of effort you can describe a boringly plausible business reason for having to implement them during a fairly pedestrian career.

Bear with my potentially dumb solution, but i'm trying to understand what an interviewer would look for in answering questions like these. For the third, in python, could you make both sets and print the symmetric difference? Does this a demonstrate practical knowledge of python or b necessitate a follow up from the interview to provide a solution that does more of the "work"?

Since these are riffs on fizzbuzz, the goal is just to evaluate whether a candidate can use programming to solve these at all, i. The goal of fizzbuzz in a phone screen should not be to see if someone can solve it in an optimal memory-efficient framework-idiomatic way. Clever syntax and data structure use is lovely, but these are really about finding whether someone can use a 'for' loop and an 'if' condition.

If they take that shortcut in Python, it tells you that they probably know Python, which also likely suggests they could think it out if they had to. If they think it out the harder way, that shows they can do that, which suggests they can get some things done. It isn't rare to find applicants who have more than 10 years of experience who somehow can't do either. The thing is, you don't need mod.

You can, in more steps, arrive at the same output just using arithmetic. But everyone If the test is interactive, the candidate can express, "I need to find out if this number is evenly divisible by that number; if so, then blah blah". I would argue that every single programmer with at least the tiniest bit of tenure in the field or a kid straight out of college who took at least some math classes will have run into this at some point in their life.

Even if you somehow don't know about it, figure something out? You probably are rejecting potentially good candidates, but I would personally suggest that of the developers that I want to hire, most of them are members of the set of developers who know what the modulo operator is for. And since hiring is a numbers game, it seems like a reasonable filter. Besides, you are allowed to ask other questions in the interview. I never use the mod function, and I still could do this test.

You are being tested on finding a solution that works, not on what function you use. I think this is becoming less true, but I think it was rightfully seen as a test of basic competence. Would you hire a chef that didn't know what a fork was even though you never use one to cook? I had to learn C at some point though, and that used to be common. I suppose it's becoming a less useful test.

JimBrimble35 on Aug 23, parent prev next [—]. I've written tens of thousands of lines of code, solved a plethora of complex problems, worked on a number of projects from requirements to production in an assortment of different languages and technologies and I can count on one hand how many times I've had to use the modulo operator.

This is first year-out-o-school, junior gate-keeping bullshit. We need better methods to evaluate intermediate and senior devs, and FizzBuzz ain't it.

And if the only way you can think of to do this program requires to do the mod function, you are not that good a programmer. Think solutions. They don't have to recognize that it is fib or do it in their head, on paper is fine. No perfect syntax under pressure to worry about. Works out nicely. While I agree there are some people who just can't program, I think it's worth pointing out that in many cases, the candidate who simply cannot FizzBuzz in one interview, will do so or other similar tests perfectly well after a few interviews.

Have you even blanked out on something you knew the day before the test? Most people have. Some not all of these interview bombs, are by people who know perfectly well how to program, but can't do it in an interview until they've done a few interviews and get over that.

I was just thinking about programming and how to get better at it today. I think a huge crutch for a lot of people is the immediate feedback loop execution gives you. I think practicing programming without the feedback loops the computer provides, e. This is basically just a hacker news comment, but instead on someone's blog.

I failed at FizzBuzz in a coding interview, my first coding interview in fact. I just completely choked and my mind went blank.

Hot Shame! I work well under pressure. I generally have no issues with speaking in public or performing; I majored in music in college. It sucked to fail at FizzBuzz. Even when I am typing something with a friendly coworker causally looking over my shoulder, I tend to make way more mistakes then I would if I was by myself.

I've been interviewing a lot of people, and it is very, very important to make them feel as comfortable and as much at ease as possible in couple of first minutes etc. Otherwise you're going to be testing their stress resistance, and not creative thinking. And it is just impossible to completely remove the stress. People at big companies, respected places. I regularly do technical phone screens at my company and it is amazing the number of people with masters degrees or very pedigreed backgrounds who are unable to solve a relatively simple problem.

I've done it before and compiled manually using javac, but if someone asked me to do that in an interview I might struggle.

The IDE just does too much in java, from generating boilerplate code, to managing packages and imports, and autocompletion. Maybe that's the reason I've almost never done interview questions in java. Tools like coderpad naturally lend themselves to dynamically typed languages. If I opened a Vim cheatsheet in a browser tab would you write me off?

I do know :wq. ZZ is better to save and exit. I chuckled thinking about how much coding I've learned in interviews. Early on in my career I messed up on SQL joins and the interviewer walked me through my mistake before excusing me. Plus there's a lot of older devs who prefer to use only vim or emacs. In the workplace we don't write katas, thats all there is to it This is both efficient and lazy.

There's also nuance to the "fizzBuzz" thing that people always leave out when they say that developers can't do "a simple fizzBuzz". Gun to their head, IDE in hand, and stack overflow at their beckon, the vast majority of those programmers wouldn't have a problem stringing together fizzBuzz I am one of the people who was involved in the original discussion twelve years ago.

It is incorrect to say that there are a surprising number of programmers who can't program something as simple as FizzBuzz. The vast, vast, vast majority of working programmers have no trouble with such ridiculously simple toy problems. However, although the overall proportion of self-identified programmers who can't program FizzBuzz is very, very small, the proportion of job applicants who can't program FizzBuzz is surprisingly large.

The entirety of the "surprise" as originally described was that the percentage is so out-of-whack. But once you think about it, it is not so difficult to understand why this may be so. Competent programmers spend most of their careers working, not interviewing. If they are looking for a job, they tend to only go to a few interviews. Whereas, incompetent programmers spend more time looking for jobs, and when they are looking, they tend to apply over and over and over again to job after job after job.

So every company that has an opening gets "spammed" with the same couple of hundred applications from the same people the are applying for job after job after job. And many of them can't program FizzBuzz. Whereas, the few competent people looking for a job tend to get an interview or two through referrals, then get an offer, accept it, and they are back in the workforce. But the couple of hundred applicants who can't program FizzBuzz shoulder grimly on, applying for the next job opening they find.

TL;DR: The sample of programmers applying for a job is not representative of the set of all programmers, not even close. I am someone who has changed development jobs quite a lot, far more than the average for my seniority.

Skill in software engineering can't just be measured by skill at writing the language, and this is trending forward faster and faster. The really accomplished engineer is one who has experienced many teams, many managers, many processes, and many deployments. The accomplished engineer is opinionated about testing methods and about code readability, because he has suffered under many misconceptions about these things and taken the time to consider the alternatives.

Even if you change jobs frequently, and take long sabbaticals I took a year off for the birth of my first child, and another to write one of my books , you probably still spend much, much, much more time working than actively seeking jobs from strangers.