13 ms·

99 Out Of 100 Programmers Can’t Program – I Call BS

132 points by duck 16y ago

kloncks 16y ago
Honestly, as a CS major, I really believe that just looking at the rest of the people in my class. College only teaches you theory, for the most part. Some will not teach you any programming besides some generic C++. You have to learn that on your own; I'll believe that the vast majority don't have the drive to learn that on their own for years to perfect their skills. I really agree with your points on the problem being with the interview process though.
- iamjustlooking 16y ago
  Agreed, It's funny how if I take a look at facebook and view classmates profiles I appear to be the only one who still programs despite us all taking software engineering in College. Maybe that's the effect of the current economic climate but at the time everyone else seemed to just view it as a high paying career path and couldn't tell you the difference between a variable and a constant.
  - ToastOpt 16y ago
    It's still high paying, and still has a lot of job openings, for the A, B, and C level programmers (as it were, keep the "F-level" out). I see two likely posibilities here. One, you classmates were all terrible -- i doubt that is true, but maybe one or two never 'got it' in industry. Two, most of them discovered that they didn't love programming, and if you don't love this line of work, it's really easy to hate it. Maybe they just found their passion elsewhere?
- fiveo 16y ago
  This might not be a valid excuse but look around at our industry: overtime everywhere. If you've been working 10-12 hours a day, you don't necessary have the power to learn on your own at the end of the day. That's why sometime I'm not surprised to see any type of programmers wanting to move to management unless he/she is really uber geek; you know, the type who have social issues and only focus on one thing. Let's face it: our industry is as bad as the quality it produced.
- techiferous 16y ago
  "College only teaches you theory...You have to learn...on your own." Agreed. My experience was that I got into programming as a kid. By the time I enrolled in college, I had written hundreds of thousands of lines of BASIC code and had written a ton of Pascal programs. College enhanced my programming abilities with concepts like big O notation but for the most part did not give me any hard technical skills that were hirable. My first job out of college was programming in Java which I picked up on my own and via an internship.
  - bad_user 16y ago
    Did you know that "I" is the most used English word?
- robryan 16y ago
  I agree, but I think that at times there is some more talent about in peers, just need to give them the benefit of the doubt and see how they go. I was thinking about it recently, if I had spent my 4 years of uni (just finish up now) focusing solely on the course content and not spending time reading things like books and hacker news and hacking my own projects/ freelancing/ startup, where would I be as a programmer? I think I would be so far behind where I am now, especially on the business side of things but also the programming. I know for a fact the thesis I'm finishing up would be nowhere near the level I have go it to. It's interesting that in uni in terms of ability I would be close to the top, but when I've seen some of the amazing talent in Melbourne through coworking I'm just average.
- ashitvora 16y ago
  I've seen people say this alot these days, "Degree is not that important". But I kinda disagree with it. I would rather say, "Grades" are not that important. You don't go to Engineering school just to learn programming. Programming is something you learn to apply what you are learning at school.
  - gaius 16y ago
    You need it all. A degree can get you over the "you don't know what you don't know" hump that many self-taught programmers never get past. My lightbulb moment was linear programming. Up 'til then I was a competent programmer, mind, but suddenly a whole new world opened up, I had no idea you could do this stuff by any means other than brute force...
- gaius 16y ago
  As a professional I can believe it too. Most of my colleagues are fine if they have some existing code and need to modify it, or add a feature following the pattern of the existing code, and that is 90% of what a developer does in the real world. A completely blank screen tho' and even I hesitate. Almost every new project I start actually starts as a skeleton from another, here's my Makefile, here's my usual basic imports, command-line parsing block, etc etc. Once I get some momentum going it's fine... The fact is that computer science is not software development, any more than you could take an astronomer, drop him on a ship and say "navigate!".
  - btilly 16y ago
    There is a simple solution to this. Start with a working program that doesn't do what you want, and incrementally make it into the one you want. It doesn't matter what the original program does. I cannot count how many times I started with a program that printed Hello, world and wound up with with something useful and unrelated.
    - gaius 16y ago
      That is how most programs are written, but it really helps to have some existing structure, such as an app framework. Also I suspect there has only ever been one Makefile, that has been copied and tweaked millions of times by millions of people over the years...
      - DisposaBoy 16y ago
        Why do you think that? Personally I write all my makefiles from scratch. I'm always baffled by other makefiles though. They always look so huge and for some unknown reason just overly complex.
        gaius 16y ago
        Really? I've been using the same one for the last 15 years, and before me it was owned by an old geezer. Some people say I should try some newfangled nonsense like Ant, but make has never let me down.
- _delirium 16y ago
  I don't think it's quite the theory/practice split here. A large percentage of CS majors would probably fail the theory version of fizzbuzz too; say, ask them to analyze a simple sort algorithm for asymptotic complexity on the whiteboard.
- city41 16y ago
  I've had the opportunity to interview/hire a lot of people over my career. The candidates who completely learned how to program from their college courses and never pushed themselves to learn, try or do more are really easy to spot. They always get a firm "no" from me. I'm looking for the candidate who programs because they truly enjoy it, almost regardless of having a degree or not. If your resume doesn't have at least a few side projects you've done I'm almost guaranteed to not even bother interviewing you.
- Daishiman 16y ago
  I don't know how good or bad my courses are, but really, just how shitty are most CS degrees? In the 4 years (and counting) that I've spent studying CS, my assignments have included writing: - a kernel driver in Linux - Writing and analyzing graph metaheuristic algorithms (and the test case generators in Python) - nontrivial data structures in C, C++, and assembly - Writing graphics and matrix math functions in Assembly - Simple OS schedulers in Java - Recursive functions in Haskell - software contracts in academic verification languages - 95% of all reports in LaTex And this is basically for the equivalent of an undergraduate's degree. I'm not saying all degrees should have this level of variety, but are people really coming out of Uni without at least having written a linked list in a low-level language?
  - Dylanlacey 16y ago
    My degree was pretty hardcore as well. Did it prepare me for work? Yes, but only in the abstract, and that's because I was lucky enough to have a natural talent that uni enhanced through practice (That of rapidly picking new stuff up). Not once did I use an MVC beyond a crappy Java implementation. We didn't do maintenance practice, or log file spelunking, or customer interaction. I learned how to create multi-user, networked, stateless applications editing one source. I created a compiler and language, learned assembly, studied algorythms and z-schemas. I switched between languages every day and solved some annoyingly abstract and difficult problems. Number of bugs I solved in other people's code outside of an exam? 0. Number of incredibly obscure projects I took from start to finish? 0. CS Degrees only teach people to be potentially good programmers IF those people are able to learn how to fix shit by themselves. Otherwise you're teaching greek to a deaf person. Sure, they know what they're asked, but they can't talk back.
- scott_s 16y ago
  It depends on the department. Some have a heavy focus on implementation projects in courses.
gvb 16y ago
[Interviewers] ask simple coding questions like the fizzbuzz, but [their] applicants still fail – even ones that shouldn't. [...] [Y]ou're using the wrong medium for what you're trying to achieve (e.g. coding over the phone). Clap clap clap. The same people that insist that the minimum development station is a tricked out computer with two (three?) big monitors, SSDs, the best IDE money can buy, etc. don't understand why someone is uncomfortable writing a program on a whiteboard or, even worse, over the phone. Unfortunately, I don't have the solution. Perhaps pg can add "Interviewing that doesn't suck" to his list http://ycombinator.com/ideas.html http://ycombinator.com/ideas.html - obviously this is included in "7. Something your company needs that doesn't exist." and is the company version of "8. Dating." Personally, I think Steve Newcomb has a 90% (maybe better) solution. http://blognewcomb.squarespace.com/essays/2010/10/14/cult-creation.html http://blognewcomb.squarespace.com/essays/2010/10/14/cult-cr... (discussed here http://news.ycombinator.com/item?id=1793095 http://news.ycombinator.com/item?id=1793095).
- Tuna-Fish 16y ago
  The problem with the Newcomb solution is that it is aimed at the high-end of tech companies, which are ultimately willing to pay very high portion of the company worth for the top talent. Most companies employing programmers today are not such companies -- they cannot possibly hope to hire A+ employees, but they are trying to build a solid team of B- or C-level programmers, just hoping to keep the F-level out. As far as I know, this is a total crapshoot and the ones succeeding in it do so mostly by luck.
  - gvb 16y ago
    Understood and agreed. I thought about editing my comment to add a disclaimer about "if you can implement it" because many companies cannot. On the other hand, the same companies that are decrying "99 out of 100 cannot program" also claim to be in the same high-end tech company space as Newcomb.
- RodgerTheGreat 16y ago
  The general principle, as I understand it, is that if you can't write a very simple program like FizzBuzz under pressure, you will also do poorly when you're doing harder tasks with less pressure. This aligns pretty well with my experiences, both in school and industry. Really, if you can't write a few lines "on the spot", what use are you going to be to an employer? In the real world there is always some deadline. I don't always expect perfection in a whiteboard scenario, but there's a world of difference between a blank stare and a 90% correct solution with an off-by-one.
makuro 16y ago
I was hoping for something more concrete. For instance, consider that terrible programmers stay in the job market for a long time, so you may encounter them more often. Also, if you're not doing your own recruitment, non-technical, keyword-seeking recruiters can be a hindrance to finding good people. This post just seems to be emphatically reasking the question "Really, guys? Really??"
- philcrissman 16y ago
  But "Really?" is actually a very good question; it's an appeal to common sense. Do we all work at places where only 1% of the programmers can actually program? I know I haven't... even when I just started and was clearly the least experienced person on the team, I could still get things done...
- japherwocky 16y ago
  +1 for the concrete thing. Spolsky was using real numbers from real experience with real applicants, but this article seems to be pure speculation and anecdote. The author is saying, "Well, my personal experience doesn't match up with this so it must be inaccurate."
  - gvb 16y ago
    Citation? I'm serious - I looked but could not find an article with real numbers. The one linked in the OP http://www.joelonsoftware.com/items/2005/01/27.html http://www.joelonsoftware.com/items/2005/01/27.html is using made up numbers. Joel actually has a pretty good theory - the same 199 incompetents plus one good programmer apply to all job openings. The good programmer gets hired and the other 199 flock to the next job opening. Occam's razor selects that explanation.
    - japherwocky 16y ago
      hm, actually I might be wrong. Shame on me for trusting my memory. :) Double flame then! Someone give us some real statistics!
Construct 16y ago
On the first day of my first job out of college, the sales engineer of the company took me out to lunch to give me some career advice. He said the best thing he ever did for his career was not learning how to code. Apparently he had graduated as a CS major and went straight for a software company, but really just could not program. Of course, as he put it he chose not to program, but I ultimately saw some of his work and it was beyond terrible. Instead, he made sure never to actually be useful to the programming or hardware teams, but talk to them just enough to know the basics and keep updated. Since he wasn't actually ever working on anything, he used his free time to mingle with management and used his inside knowledge from the programming teams to announce potential problems to management before the actual programming teams could communicate this info. Sure enough, he slowly moved into management and higher salary brackets by never actually learning how to program. Of course, the programmers and hardware teams caught on to his game and cut him off from any useful information, and without any actually knowledge he hit a ceiling within the company pretty quickly. Still, it was an important business lesson for me, and ever since watching this all take place I've made sure to carve out some time from my heads-down work to maintain visibility and directly communicate with management.
- gvb 16y ago
  The really sad thing is that he had something incredibly valuable - the ability to translate between geek-speak and manager-speak - and chose the dark side. If he worked as a collaborating liaison instead of a back-stabbing asshat, he probably would have climbed faster and definitely farther.
devmonk 16y ago
You aren't something unless you do it. First, define programming. I think I program, but I might not be programming if someone's sense of the word is 100% test complete.
- philcrissman 16y ago
  That might get into a distinction between programming (let's make the computer do what we tell it) and developing (let's follow these processes while we program). But it's a good point. That said, if I were interviewing someone who was clearly a good coder but who said they didn't test their code, I would still hire them as long as they would be willing to start writing some tests.
fiveo 16y ago
Our field is such a weird place to be. I live in a city where most people are looking for .NET, WCF, WWF, WPF, WebServices, SQL-Server (T-SQL), and some Windows Administration, either that set or this one: JSF, Struts2, Spring, Hibernate, Maven/Ant, XML, XSLT, XSL, XQuery, XPath with Oracle/DB2. Most programmers in my area are no longer care about Algorithm, Data Structure, Operating System principles, Database principles, or basic Math. Most companies, that I work for or heard from employees, don't have good codebase, don't have good automation tests, don't have good culture. Sometime I do wonder what does it mean to "be able to program". Can deciding to use MVC (Spring, ASP.NET, Rails) to spit out XML/JSON so that it can be consumed by AIR, pure JS/jQuery, or even your iPhone app be counted as "be able to program"? Can writing good code that can be easily testable be counted as "be able to program"? Can producing code that consumed WebServices from other payment provider be considered as "be able to program"? Or, can solving tricky algorithm problems is the de-facto "can program" filter? Some of the "can..." produce business values. Some others, might not necessarily produce business values, but instead, just to show that "yeah, I can sling code the way you want me to". Tricky field...
- mahmud 16y ago
  Ugh! Please don't enumerate buzzwords like that. Or at least ROT13 it to be kind to some people's refined slacker sensibilities. Right now I am digging my nails into the desk and biting my teeth: please, don't give the scumbags any of your attention. Hack outside what you see on corporate job descriptions, even if you have to wait tables to support your console habit. Everyday you spend learning something to meet a job requirement, you're being someone's #&@! And someone who doesn't know you or give a crap about you. Do this shit for yourself. Do what you* want. Forty years from now, at the end of your career, what do you want to remember? What do you want to be remembered by? Surely, not that pile of inventory reporting macros you wrote in Vector SQL-PowerG# 2020. I see these ghosts at bookstores, discussing how they're certified in Java, Oracle, CISCO, and A+, and now need to add Ruby and Scala because they saw it on an ad. I am sure a great many of them can code and code "well", as much as their tools allow them. But at what cost to themselves, their ego, karma, mental health, personal growth, and fucking COJONES .. tienes algo? Don't choose to remain adequate, and acceptable. Aim to excel, exceed, and if necessary, offend. Today's challenges and good times are tomorrow's fond-memories. Take a shot at something great, even if you fail, do it, and enjoy yourself.
jdp23 16y ago
Excellent article. And I think the parenthetical comment here cuts to the chase > And as much as I want to just accept it (for reasons of self-aggrandisement) For people who identify as "great programmers", there's a huge amount of ego and status that comes with this view. Don't get me wrong, I think that computer science education in the US is pretty bad, and lots of people come out of school without having great programming skills, but there's a huge difference between the elitism of "almost everybody but me is a bozo" and the more complex reality.
damoncali 16y ago
The end of the article explains this all quite well: Programming is very easy to get into professionally. I know we all like to think of ourselves as super smart and that our knowledge is somehow hard to come by, but in reality, it can be as easy as picking up a book. You just can't do that in most fields, even "easy" ones. As a result, you get a wide variance of commitment, and therefore talent.
- gaius 16y ago
  It is also perceived to be easy to get into, walk into a bookstore and see all the "whatever for dummies" books. So there is a huge army of low-grade "programmers", many of whom are now unemployed. That is true across the entire planet, mind. So while there is a shortage of true talent, that won't be solved by importing the "... for dummies" crowd from overseas.
Maro 16y ago
Recently we started interviewing 4-5th year CS students for a C++/database programming job/internship. One of our questions is, if you have 10 computers and all are connected, how many connections do you have in the network (45)? Even after drawing the n=3,4 cases on the whiteboard as graphs, most CS majors cannot answer the question. As we spend more time on these interviews, we're considering making this our first question, and if somebody cannot answer it, however long it takes, interview is over, let's stop wasting each other's time. Similar no-go questions that people have problems with are: what's a JOIN, what does ACID actually mean, the difference between TCP and UDP.
- endtime 16y ago
  Are you specifying that you want students with database and networking experience? If not, your expectations may be off. I did both my BS and MS in CS (both at schools you've heard of), but concentrated on theory and AI, and I'm not sure I'd get the last two questions right. TCP guarantees packet delivery and UDP doesn't, though I only happened to learn that in passing - for all I know there are other differences too. And I don't actually know what ACID stands for, though if I had to guess I'd say it describes a set of properties that a database may or may not have. But that guess, even if vaguely right, also comes from happening to have seen it in context somewhere, not from my education. Hmm...a friend of mine from grad school just started at Google and I don't think she'd be able to answer those either.
  - deleted 16y ago
    [deleted]
  - Maro 16y ago
    Our ad is "Database startup looking for C++ programmers". Also, here in Hungary CS majors take at least one semester of database, where they learn ACID. Also, we're not looking for exhaustive answers, eg. in the TCP/UDP case all we want to hear is guaranteed delivery, packet reordering, stream oriented, packet oriented, UDP is good for audio, that's about it. You should know we're a startup writing a distributed database (hence the n(n-1)/2 question), so virtually all code involves fairly low-level networking, and ACID is an everyday issue. This all of course is obvious from our website, which the interviewee presumably checks. The code is open-source, so they could actually look at the code to see what kind of questions to expect.
known 16y ago
Interview != Quiz
KirinDave 16y ago
I've definitely come across candidates that simply couldn't code well. They couldn't handle basic things, and they didn't have a strong grasp of the fundamentals of their preferred languages. Then again, I've been in interviews that were so brutally hard I stormed off rather than keep dealing with the issue. No exaggeration: I've been plopped down at an unfamiliar machine with only 1 putty window to a unix box (that didn't have emacs!) and told to write an ls clone in 30 minutes, without being allowed to open a web browser (and that was only one of three tasks to do in 1.5 hours) But I also can't help but wonder if the author is in his own self-selected world. Now that I'm in startup-land, I see fewer incompetent people. Even being in Silicon Valley strongly ups your odds of meeting people who are competent. When I was interviewing outside of the Valley, things sometimes were confusingly bad.
- kemayo 16y ago
  I tend to think that if you're going to insist that someone write code without access to documentation and in an unfamiliar environment then you shouldn't ask for anything more than pseudocode. Otherwise you're just testing whether or not someone has memorized the standard library of whatever language you want. You can argue that someone who has memorized the [Foo] standard library might be better at some things than someone who hasn't, of course. But I think that what you're testing for is at best tangental to the ability to design/write good code.
Encosia 16y ago
I think the fizzbuzz thing is a myth reinforced by confirmation bias. No one takes to the Internet to talk about how an interview went as expected, and rarely to mention a better than expected outcome. We're only hearing from the subset of interview processes that attracted subpar candidates or had particularly bad luck.
agentultra 16y ago
Blame Your Interview Process First Maybe it's the dogmatic zealotry, but it seems like 9 out of 10 programmers just repeat what they hear to be common wisdom so that they don't stick out like a sore thumb. Who would want to be one of these mythical programmers that cannot program? Who wants to be called "dead weight" and cast out of the group? Who would ever admit to being one of these fabled creatures? We programmers need to stop being so nasty and elitist. Programming is hard and I'd be impressed if you could write down a working solution to a toy computer science problem you probably slaved over for months in university on a napkin in 10 minutes. You should go on Jeopardy. You'd make a killing. I can't do that; I don't have a mind for trivia. We need to stop entertaining our egos and thinking of everyone as "dead weight." We can all stand to improve the code we write. We should be encouraging one another and learning together. We don't "interview" people anymore. We "screen" them. I suspect it has something to do with the elitism in the industry as well as the inherent anxiousness and dread of interviewing people you don't know. It's become a terribly broken process, yet it seems precious few people such as the OP realize this. We could do something about this. Here are some tips I have from my experiences: 1. Know the person's name before they walk into the room. Don't shake their hand as you look down at their resume to figure out their name. At least make it look like you put thought and care into who you invite into your office for an interview. 2. Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper. The tools of the trade are debuggers, compilers/interpreters, and text editors. If you want to see how they approach problems, tell them to come prepared with code samples to share or something. Make sure they're aware that they'll be talking about their solution, the tools they used, etc. One last thing (and a bit of a shameless plug), I think software can be used to ease some of the pain of the hiring process. I'm working on a project to amalgamate meta-data from repository analysis tools and social networks into a single candidate profile that should give you a pretty clear indication of their skills and abilities. The idea is that you should only invite people you are interested in hiring into the interview. To be able to do that you need to know as much about this person as you can and be comfortable that you have an accurate picture of their abilities and work history. The volume of resumes can make this hard... why not automate it? Just sayin'
- dlo 16y ago
codyguy 16y ago
Agree - The interview process needs to be questioned too. How relevant is writing a linked list to the current position? Maybe it is. Mostly it isn't. Canned interview processes end up in disappointment for both sides.
dawgr 16y ago
Assuming that by singly linked list, he means that each node only has a pointer to the next node and not to the previous one. For each node, I'd save a pointer to it and to the next node. Then replace its next pointer with the pointer to the previous node which should have been saved. Move to the next node and do the same. Done in t(n)=n. If the list was doubly linked, you could do it in half the time by switching 1 and n, 2 and n-1, etc...Would I get the job? EDIT: also change the list to point to the new first node.
rickmb 16y ago
The thing is, agree with most of this post (when it comes to interviewing and assessing ability)... except I don't buy that that explains it. Take this part for example: 'Somehow though I don't reckon there are 99 working programmers sitting there reading those posts thinking "…yeah I am a bit of a failure, I wish I was one of those 1 in a 100 dudes"'. Well, 99 out of 100 programmers don't read those posts. That's how they get by. They never confront themselves with what they don't know, don't read tech blogs, don't visit HN and never go to conferences, user groups etcetera. I've been working in this business for over 20 years, I have no illusions about my own limited abilities, but yeah, 99 out of 100 doesn't seem that unreal to me. The vast majority of programmers I worked with are utterly incompetent. BTW, in interviews I prefer to let the candidate talk about code rather than writing it. Conceptual understanding, and the ability to express that already tells me more than enough. Only when it comes to juniors fresh out of college I may want some confirmation that they can do more than talk a good game.
berntb 16y ago
I have a theory on this. Let me make an analogy to advice I gave to a naive female friend (personal theory, I'm not a psychologist). Consider psychopaths. They are not many (in percent of the male population), but if you go out and meet guys socially, you will meet a much larger fraction of them. That is because they use people and have to get new social environments quite often... I think it is the same when you interview programmers; the bad ones tend to apply for jobs much more. The interview process has a built in selection bias, so people doing interviews go crazy because most people they see are ass hats. And about white boards -- there are lots of subjects where I have good experience, but not recent enough to do a white board test. OTOH, one of the smartest people I studied with aced all the math courses but could never learn to program. [Edit: What I was trying to say here, an interviewer couldn't see a difference between us two by asking about e.g. a language I haven't used in a few years.] Disclaimer: I don't know how good I am, but I only look for work at most every few years... :-)
moron4hire 16y ago
This is why I don't give programming problems as questions. I've written numerous database applications and I really couldn't tell you off of the top of my head all of the parameters to make a proper database connection. When a mathematician writes a formula, it's a communication from one mathematician to another of intent. When a programmer writes code, it's primarily instructing the machine how to perform a given calculation; as such, it's an exercise in tedium and not very appropriate for person-to-person communication. So, that's why I ask design problems. I ask candidates to draw diagrams of databases that meet a certain need. I ask them to draw flow charts and state diagrams. These are much more conducive to human communication. I need to know that they can think before they can program. I'd hire someone with no experience in Python to start a brand new project in Python if they showed they had excellent problem solving skills because the hows of writing Python code is just going to be one more problem to solve for them. They'll figure it out and do what they need to do. When was the last time you know everything about how to program something before you started on the project? If the answer is "ever", did you stick around for the end or quit because you were bored?
stcredzero 16y ago
X% of programmers can program. But they do so in such a way that when they've added N thousands of lines of code, it starts to suck. An easy metric for suck doesn't immediately pop into my head.
- nene 16y ago
  WTF's / minute ? http://www.osnews.com/images/comics/wtfm.jpg http://www.osnews.com/images/comics/wtfm.jpg
  - stcredzero 16y ago
    Good in the aesthetic sense. Bad in that this can be easily gamed.
fnl 16y ago
Great post, good points (had a good laugh about the loop and arithmetic assumption ;-)) and I mostly agree - although probably 1/3 of [academic/scientific] programmers [at least] really can't program (although that is much less than what got you about to post). [see Nature Oct 14, 2010] However, that is definitely less than the "majority".
nevinera 16y ago
>All of a sudden the headline is: X out of Y Applicants for Positions Advertised By My Company Can't Program Theres an important point here that he didn't make. The ones that aren't remotely qualified to even apply for the position? They applied to all the positions at every company they could find. Of course they seem to outnumber the remotely competent programmers; they sent out far more resumes, and by all the non-scientific metrics they get counted that many more times. In particular, this line bothers me: 'How much time did you spend making sure your ad was sufficiently attractive to the star developers and a sufficient deterrent to the crappy ones?' Making the ad attractive to 'star developers' is not the issue here, making it less attractive to resume-spammers is.
jasonkester 16y ago
Strange article. The author deliberately mis-quotes a bunch of sources to get his outrageous title, then calls bullshit on it. Then he goes in and actually reads the articles he's calling out, using quotes from them to support his point, which is also the point of the articles he's calling out. Everybody knows that this statistic refers to people applying for jobs, not working programmers. Everybody who's ever tried to hire in this industry has observed it first hand. Every article about it goes to pains to explain that it's a problem involving unemployable programmers applying for jobs they don't deserve. I'm not sure who this author thinks he's arguing with.
jdoliner 16y ago
As someone who does a lot of interviewing at RethinkDB I agree that these numbers are in many ways bullshit. Firstly they're pretty clearly hyperbolic (I think we all knew that already). However I think they also tend to be the result of a short memory span. Whatever the actual numbers may be (we should keep track) they are bad enough that every once in a while you get a run of ~5 interviews that really make you scratch your head. Which is about the time that these posts get written. The linked list question is designed as a smoke test. Admittedly it's a piece of code that one can do loads of coding without ever having to write. But bear in mind that in an interview we're looking for some code indicative of one's ability in the space of an hour, code that you actually write for production takes weeks-months-years and we simply don't have that kind of time. Questions like this have a high signal to noise; they're just esoteric enough that few people actually have a full implementation committed to memory but simple enough that anyone who gets the concepts of pointers and recursion should know just what to do. When runs of bad candidates pop up we do indeed reinspect our process. One major improvement to the process is to ask people question their resume suggests they should be more comfortable with. Ask questions in the more esoteric languages they know, ask questions in the field they did their research on. Obviously this greatly increases the chance of correct answers, thus these type of questions have a smaller correlation between a correct answer and a good hire. But what these questions can really do well is convince you that when this person understands something, he really understands it; he gets it well enough that he can very quickly explain it to me. This is very good sign in a potential hire.
davidmathers 16y ago
This is utter bullshit strawman trolling hyperbole. I remember reading Joel's post alluding to this back in the day, then Jeff's a couple of years ago Hmmm. The Raganwald post that Jeff's is based on says this at the top: 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. Wait, so what did Joel's post say back in the day? That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%. Ok, let's see how low you can go in your quest for faux controversy: One question immediately springs to mind: Is that x out of y applicants, or x out of y working developers? There is a massive distinction. O RLY? All of a sudden the headline is: X out of Y Applicants for Positions Advertised By My Company Can't Program. That's a whole lot less impressive/sensational and whole lot closer to reality. Actually, Joel's impressive/sensational headline was: News. I think you might be projecting.

132 points by duck 16y ago

Honestly, as a CS major, I really believe that just looking at the rest of the people in my class. College only teaches you theory, for the most part. Some will not teach you any programming besides some generic C++. You have to learn that on your own; I'll believe that the vast majority don't have the drive to learn that on their own for years to perfect their skills. I really agree with your points on the problem being with the interview process though.

iamjustlooking 16y ago
Agreed, It's funny how if I take a look at facebook and view classmates profiles I appear to be the only one who still programs despite us all taking software engineering in College. Maybe that's the effect of the current economic climate but at the time everyone else seemed to just view it as a high paying career path and couldn't tell you the difference between a variable and a constant.
- ToastOpt 16y ago
  It's still high paying, and still has a lot of job openings, for the A, B, and C level programmers (as it were, keep the "F-level" out). I see two likely posibilities here. One, you classmates were all terrible -- i doubt that is true, but maybe one or two never 'got it' in industry. Two, most of them discovered that they didn't love programming, and if you don't love this line of work, it's really easy to hate it. Maybe they just found their passion elsewhere?
fiveo 16y ago
This might not be a valid excuse but look around at our industry: overtime everywhere. If you've been working 10-12 hours a day, you don't necessary have the power to learn on your own at the end of the day. That's why sometime I'm not surprised to see any type of programmers wanting to move to management unless he/she is really uber geek; you know, the type who have social issues and only focus on one thing. Let's face it: our industry is as bad as the quality it produced.
techiferous 16y ago
"College only teaches you theory...You have to learn...on your own." Agreed. My experience was that I got into programming as a kid. By the time I enrolled in college, I had written hundreds of thousands of lines of BASIC code and had written a ton of Pascal programs. College enhanced my programming abilities with concepts like big O notation but for the most part did not give me any hard technical skills that were hirable. My first job out of college was programming in Java which I picked up on my own and via an internship.
- bad_user 16y ago
  Did you know that "I" is the most used English word?
robryan 16y ago
I agree, but I think that at times there is some more talent about in peers, just need to give them the benefit of the doubt and see how they go. I was thinking about it recently, if I had spent my 4 years of uni (just finish up now) focusing solely on the course content and not spending time reading things like books and hacker news and hacking my own projects/ freelancing/ startup, where would I be as a programmer? I think I would be so far behind where I am now, especially on the business side of things but also the programming. I know for a fact the thesis I'm finishing up would be nowhere near the level I have go it to. It's interesting that in uni in terms of ability I would be close to the top, but when I've seen some of the amazing talent in Melbourne through coworking I'm just average.
ashitvora 16y ago
I've seen people say this alot these days, "Degree is not that important". But I kinda disagree with it. I would rather say, "Grades" are not that important. You don't go to Engineering school just to learn programming. Programming is something you learn to apply what you are learning at school.
- gaius 16y ago
  You need it all. A degree can get you over the "you don't know what you don't know" hump that many self-taught programmers never get past. My lightbulb moment was linear programming. Up 'til then I was a competent programmer, mind, but suddenly a whole new world opened up, I had no idea you could do this stuff by any means other than brute force...
gaius 16y ago
As a professional I can believe it too. Most of my colleagues are fine if they have some existing code and need to modify it, or add a feature following the pattern of the existing code, and that is 90% of what a developer does in the real world. A completely blank screen tho' and even I hesitate. Almost every new project I start actually starts as a skeleton from another, here's my Makefile, here's my usual basic imports, command-line parsing block, etc etc. Once I get some momentum going it's fine... The fact is that computer science is not software development, any more than you could take an astronomer, drop him on a ship and say "navigate!".
- btilly 16y ago
  There is a simple solution to this. Start with a working program that doesn't do what you want, and incrementally make it into the one you want. It doesn't matter what the original program does. I cannot count how many times I started with a program that printed Hello, world and wound up with with something useful and unrelated.
  - gaius 16y ago
    That is how most programs are written, but it really helps to have some existing structure, such as an app framework. Also I suspect there has only ever been one Makefile, that has been copied and tweaked millions of times by millions of people over the years...
    - DisposaBoy 16y ago
      Why do you think that? Personally I write all my makefiles from scratch. I'm always baffled by other makefiles though. They always look so huge and for some unknown reason just overly complex.
      - gaius 16y ago
        Really? I've been using the same one for the last 15 years, and before me it was owned by an old geezer. Some people say I should try some newfangled nonsense like Ant, but make has never let me down.
_delirium 16y ago
I don't think it's quite the theory/practice split here. A large percentage of CS majors would probably fail the theory version of fizzbuzz too; say, ask them to analyze a simple sort algorithm for asymptotic complexity on the whiteboard.
city41 16y ago
I've had the opportunity to interview/hire a lot of people over my career. The candidates who completely learned how to program from their college courses and never pushed themselves to learn, try or do more are really easy to spot. They always get a firm "no" from me. I'm looking for the candidate who programs because they truly enjoy it, almost regardless of having a degree or not. If your resume doesn't have at least a few side projects you've done I'm almost guaranteed to not even bother interviewing you.
Daishiman 16y ago
I don't know how good or bad my courses are, but really, just how shitty are most CS degrees? In the 4 years (and counting) that I've spent studying CS, my assignments have included writing: - a kernel driver in Linux - Writing and analyzing graph metaheuristic algorithms (and the test case generators in Python) - nontrivial data structures in C, C++, and assembly - Writing graphics and matrix math functions in Assembly - Simple OS schedulers in Java - Recursive functions in Haskell - software contracts in academic verification languages - 95% of all reports in LaTex And this is basically for the equivalent of an undergraduate's degree. I'm not saying all degrees should have this level of variety, but are people really coming out of Uni without at least having written a linked list in a low-level language?
- Dylanlacey 16y ago
  My degree was pretty hardcore as well. Did it prepare me for work? Yes, but only in the abstract, and that's because I was lucky enough to have a natural talent that uni enhanced through practice (That of rapidly picking new stuff up). Not once did I use an MVC beyond a crappy Java implementation. We didn't do maintenance practice, or log file spelunking, or customer interaction. I learned how to create multi-user, networked, stateless applications editing one source. I created a compiler and language, learned assembly, studied algorythms and z-schemas. I switched between languages every day and solved some annoyingly abstract and difficult problems. Number of bugs I solved in other people's code outside of an exam? 0. Number of incredibly obscure projects I took from start to finish? 0. CS Degrees only teach people to be potentially good programmers IF those people are able to learn how to fix shit by themselves. Otherwise you're teaching greek to a deaf person. Sure, they know what they're asked, but they can't talk back.
scott_s 16y ago
It depends on the department. Some have a heavy focus on implementation projects in courses.

gvb 16y ago

[Interviewers] ask simple coding questions like the fizzbuzz, but [their] applicants still fail – even ones that shouldn't. [...] [Y]ou're using the wrong medium for what you're trying to achieve (e.g. coding over the phone). Clap clap clap. The same people that insist that the minimum development station is a tricked out computer with two (three?) big monitors, SSDs, the best IDE money can buy, etc. don't understand why someone is uncomfortable writing a program on a whiteboard or, even worse, over the phone. Unfortunately, I don't have the solution. Perhaps pg can add "Interviewing that doesn't suck" to his list http://ycombinator.com/ideas.html http://ycombinator.com/ideas.html - obviously this is included in "7. Something your company needs that doesn't exist." and is the company version of "8. Dating." Personally, I think Steve Newcomb has a 90% (maybe better) solution. http://blognewcomb.squarespace.com/essays/2010/10/14/cult-creation.html http://blognewcomb.squarespace.com/essays/2010/10/14/cult-cr... (discussed here http://news.ycombinator.com/item?id=1793095 http://news.ycombinator.com/item?id=1793095).

Tuna-Fish 16y ago
The problem with the Newcomb solution is that it is aimed at the high-end of tech companies, which are ultimately willing to pay very high portion of the company worth for the top talent. Most companies employing programmers today are not such companies -- they cannot possibly hope to hire A+ employees, but they are trying to build a solid team of B- or C-level programmers, just hoping to keep the F-level out. As far as I know, this is a total crapshoot and the ones succeeding in it do so mostly by luck.
- gvb 16y ago
  Understood and agreed. I thought about editing my comment to add a disclaimer about "if you can implement it" because many companies cannot. On the other hand, the same companies that are decrying "99 out of 100 cannot program" also claim to be in the same high-end tech company space as Newcomb.
RodgerTheGreat 16y ago
The general principle, as I understand it, is that if you can't write a very simple program like FizzBuzz under pressure, you will also do poorly when you're doing harder tasks with less pressure. This aligns pretty well with my experiences, both in school and industry. Really, if you can't write a few lines "on the spot", what use are you going to be to an employer? In the real world there is always some deadline. I don't always expect perfection in a whiteboard scenario, but there's a world of difference between a blank stare and a 90% correct solution with an off-by-one.

makuro 16y ago

I was hoping for something more concrete. For instance, consider that terrible programmers stay in the job market for a long time, so you may encounter them more often. Also, if you're not doing your own recruitment, non-technical, keyword-seeking recruiters can be a hindrance to finding good people. This post just seems to be emphatically reasking the question "Really, guys? Really??"

philcrissman 16y ago
But "Really?" is actually a very good question; it's an appeal to common sense. Do we all work at places where only 1% of the programmers can actually program? I know I haven't... even when I just started and was clearly the least experienced person on the team, I could still get things done...
japherwocky 16y ago
+1 for the concrete thing. Spolsky was using real numbers from real experience with real applicants, but this article seems to be pure speculation and anecdote. The author is saying, "Well, my personal experience doesn't match up with this so it must be inaccurate."
- gvb 16y ago
  Citation? I'm serious - I looked but could not find an article with real numbers. The one linked in the OP http://www.joelonsoftware.com/items/2005/01/27.html http://www.joelonsoftware.com/items/2005/01/27.html is using made up numbers. Joel actually has a pretty good theory - the same 199 incompetents plus one good programmer apply to all job openings. The good programmer gets hired and the other 199 flock to the next job opening. Occam's razor selects that explanation.
  - japherwocky 16y ago
    hm, actually I might be wrong. Shame on me for trusting my memory. :) Double flame then! Someone give us some real statistics!

Construct 16y ago

On the first day of my first job out of college, the sales engineer of the company took me out to lunch to give me some career advice. He said the best thing he ever did for his career was not learning how to code. Apparently he had graduated as a CS major and went straight for a software company, but really just could not program. Of course, as he put it he chose not to program, but I ultimately saw some of his work and it was beyond terrible. Instead, he made sure never to actually be useful to the programming or hardware teams, but talk to them just enough to know the basics and keep updated. Since he wasn't actually ever working on anything, he used his free time to mingle with management and used his inside knowledge from the programming teams to announce potential problems to management before the actual programming teams could communicate this info. Sure enough, he slowly moved into management and higher salary brackets by never actually learning how to program. Of course, the programmers and hardware teams caught on to his game and cut him off from any useful information, and without any actually knowledge he hit a ceiling within the company pretty quickly. Still, it was an important business lesson for me, and ever since watching this all take place I've made sure to carve out some time from my heads-down work to maintain visibility and directly communicate with management.

gvb 16y ago
The really sad thing is that he had something incredibly valuable - the ability to translate between geek-speak and manager-speak - and chose the dark side. If he worked as a collaborating liaison instead of a back-stabbing asshat, he probably would have climbed faster and definitely farther.

devmonk 16y ago

You aren't something unless you do it. First, define programming. I think I program, but I might not be programming if someone's sense of the word is 100% test complete.

philcrissman 16y ago
That might get into a distinction between programming (let's make the computer do what we tell it) and developing (let's follow these processes while we program). But it's a good point. That said, if I were interviewing someone who was clearly a good coder but who said they didn't test their code, I would still hire them as long as they would be willing to start writing some tests.

fiveo 16y ago

Our field is such a weird place to be. I live in a city where most people are looking for .NET, WCF, WWF, WPF, WebServices, SQL-Server (T-SQL), and some Windows Administration, either that set or this one: JSF, Struts2, Spring, Hibernate, Maven/Ant, XML, XSLT, XSL, XQuery, XPath with Oracle/DB2. Most programmers in my area are no longer care about Algorithm, Data Structure, Operating System principles, Database principles, or basic Math. Most companies, that I work for or heard from employees, don't have good codebase, don't have good automation tests, don't have good culture. Sometime I do wonder what does it mean to "be able to program". Can deciding to use MVC (Spring, ASP.NET, Rails) to spit out XML/JSON so that it can be consumed by AIR, pure JS/jQuery, or even your iPhone app be counted as "be able to program"? Can writing good code that can be easily testable be counted as "be able to program"? Can producing code that consumed WebServices from other payment provider be considered as "be able to program"? Or, can solving tricky algorithm problems is the de-facto "can program" filter? Some of the "can..." produce business values. Some others, might not necessarily produce business values, but instead, just to show that "yeah, I can sling code the way you want me to". Tricky field...

mahmud 16y ago
Ugh! Please don't enumerate buzzwords like that. Or at least ROT13 it to be kind to some people's refined slacker sensibilities. Right now I am digging my nails into the desk and biting my teeth: please, don't give the scumbags any of your attention. Hack outside what you see on corporate job descriptions, even if you have to wait tables to support your console habit. Everyday you spend learning something to meet a job requirement, you're being someone's #&@! And someone who doesn't know you or give a crap about you. Do this shit for yourself. Do what you* want. Forty years from now, at the end of your career, what do you want to remember? What do you want to be remembered by? Surely, not that pile of inventory reporting macros you wrote in Vector SQL-PowerG# 2020. I see these ghosts at bookstores, discussing how they're certified in Java, Oracle, CISCO, and A+, and now need to add Ruby and Scala because they saw it on an ad. I am sure a great many of them can code and code "well", as much as their tools allow them. But at what cost to themselves, their ego, karma, mental health, personal growth, and fucking COJONES .. tienes algo? Don't choose to remain adequate, and acceptable. Aim to excel, exceed, and if necessary, offend. Today's challenges and good times are tomorrow's fond-memories. Take a shot at something great, even if you fail, do it, and enjoy yourself.

jdp23 16y ago

Excellent article. And I think the parenthetical comment here cuts to the chase > And as much as I want to just accept it (for reasons of self-aggrandisement) For people who identify as "great programmers", there's a huge amount of ego and status that comes with this view. Don't get me wrong, I think that computer science education in the US is pretty bad, and lots of people come out of school without having great programming skills, but there's a huge difference between the elitism of "almost everybody but me is a bozo" and the more complex reality.

damoncali 16y ago

The end of the article explains this all quite well: Programming is very easy to get into professionally. I know we all like to think of ourselves as super smart and that our knowledge is somehow hard to come by, but in reality, it can be as easy as picking up a book. You just can't do that in most fields, even "easy" ones. As a result, you get a wide variance of commitment, and therefore talent.

gaius 16y ago
It is also perceived to be easy to get into, walk into a bookstore and see all the "whatever for dummies" books. So there is a huge army of low-grade "programmers", many of whom are now unemployed. That is true across the entire planet, mind. So while there is a shortage of true talent, that won't be solved by importing the "... for dummies" crowd from overseas.

Maro 16y ago

Recently we started interviewing 4-5th year CS students for a C++/database programming job/internship. One of our questions is, if you have 10 computers and all are connected, how many connections do you have in the network (45)? Even after drawing the n=3,4 cases on the whiteboard as graphs, most CS majors cannot answer the question. As we spend more time on these interviews, we're considering making this our first question, and if somebody cannot answer it, however long it takes, interview is over, let's stop wasting each other's time. Similar no-go questions that people have problems with are: what's a JOIN, what does ACID actually mean, the difference between TCP and UDP.

endtime 16y ago
Are you specifying that you want students with database and networking experience? If not, your expectations may be off. I did both my BS and MS in CS (both at schools you've heard of), but concentrated on theory and AI, and I'm not sure I'd get the last two questions right. TCP guarantees packet delivery and UDP doesn't, though I only happened to learn that in passing - for all I know there are other differences too. And I don't actually know what ACID stands for, though if I had to guess I'd say it describes a set of properties that a database may or may not have. But that guess, even if vaguely right, also comes from happening to have seen it in context somewhere, not from my education. Hmm...a friend of mine from grad school just started at Google and I don't think she'd be able to answer those either.
- deleted 16y ago
  [deleted]
- Maro 16y ago
  Our ad is "Database startup looking for C++ programmers". Also, here in Hungary CS majors take at least one semester of database, where they learn ACID. Also, we're not looking for exhaustive answers, eg. in the TCP/UDP case all we want to hear is guaranteed delivery, packet reordering, stream oriented, packet oriented, UDP is good for audio, that's about it. You should know we're a startup writing a distributed database (hence the n(n-1)/2 question), so virtually all code involves fairly low-level networking, and ACID is an everyday issue. This all of course is obvious from our website, which the interviewee presumably checks. The code is open-source, so they could actually look at the code to see what kind of questions to expect.

known 16y ago

Interview != Quiz

KirinDave 16y ago

I've definitely come across candidates that simply couldn't code well. They couldn't handle basic things, and they didn't have a strong grasp of the fundamentals of their preferred languages. Then again, I've been in interviews that were so brutally hard I stormed off rather than keep dealing with the issue. No exaggeration: I've been plopped down at an unfamiliar machine with only 1 putty window to a unix box (that didn't have emacs!) and told to write an ls clone in 30 minutes, without being allowed to open a web browser (and that was only one of three tasks to do in 1.5 hours) But I also can't help but wonder if the author is in his own self-selected world. Now that I'm in startup-land, I see fewer incompetent people. Even being in Silicon Valley strongly ups your odds of meeting people who are competent. When I was interviewing outside of the Valley, things sometimes were confusingly bad.

kemayo 16y ago
I tend to think that if you're going to insist that someone write code without access to documentation and in an unfamiliar environment then you shouldn't ask for anything more than pseudocode. Otherwise you're just testing whether or not someone has memorized the standard library of whatever language you want. You can argue that someone who has memorized the [Foo] standard library might be better at some things than someone who hasn't, of course. But I think that what you're testing for is at best tangental to the ability to design/write good code.

Encosia 16y ago

I think the fizzbuzz thing is a myth reinforced by confirmation bias. No one takes to the Internet to talk about how an interview went as expected, and rarely to mention a better than expected outcome. We're only hearing from the subset of interview processes that attracted subpar candidates or had particularly bad luck.

agentultra 16y ago

Blame Your Interview Process First Maybe it's the dogmatic zealotry, but it seems like 9 out of 10 programmers just repeat what they hear to be common wisdom so that they don't stick out like a sore thumb. Who would want to be one of these mythical programmers that cannot program? Who wants to be called "dead weight" and cast out of the group? Who would ever admit to being one of these fabled creatures? We programmers need to stop being so nasty and elitist. Programming is hard and I'd be impressed if you could write down a working solution to a toy computer science problem you probably slaved over for months in university on a napkin in 10 minutes. You should go on Jeopardy. You'd make a killing. I can't do that; I don't have a mind for trivia. We need to stop entertaining our egos and thinking of everyone as "dead weight." We can all stand to improve the code we write. We should be encouraging one another and learning together. We don't "interview" people anymore. We "screen" them. I suspect it has something to do with the elitism in the industry as well as the inherent anxiousness and dread of interviewing people you don't know. It's become a terribly broken process, yet it seems precious few people such as the OP realize this. We could do something about this. Here are some tips I have from my experiences: 1. Know the person's name before they walk into the room. Don't shake their hand as you look down at their resume to figure out their name. At least make it look like you put thought and care into who you invite into your office for an interview. 2. Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper. The tools of the trade are debuggers, compilers/interpreters, and text editors. If you want to see how they approach problems, tell them to come prepared with code samples to share or something. Make sure they're aware that they'll be talking about their solution, the tools they used, etc. One last thing (and a bit of a shameless plug), I think software can be used to ease some of the pain of the hiring process. I'm working on a project to amalgamate meta-data from repository analysis tools and social networks into a single candidate profile that should give you a pretty clear indication of their skills and abilities. The idea is that you should only invite people you are interested in hiring into the interview. To be able to do that you need to know as much about this person as you can and be comfortable that you have an accurate picture of their abilities and work history. The volume of resumes can make this hard... why not automate it? Just sayin'

dlo 16y ago

codyguy 16y ago

Agree - The interview process needs to be questioned too. How relevant is writing a linked list to the current position? Maybe it is. Mostly it isn't. Canned interview processes end up in disappointment for both sides.

dawgr 16y ago

Assuming that by singly linked list, he means that each node only has a pointer to the next node and not to the previous one. For each node, I'd save a pointer to it and to the next node. Then replace its next pointer with the pointer to the previous node which should have been saved. Move to the next node and do the same. Done in t(n)=n. If the list was doubly linked, you could do it in half the time by switching 1 and n, 2 and n-1, etc...Would I get the job? EDIT: also change the list to point to the new first node.

rickmb 16y ago

The thing is, agree with most of this post (when it comes to interviewing and assessing ability)... except I don't buy that that explains it. Take this part for example: 'Somehow though I don't reckon there are 99 working programmers sitting there reading those posts thinking "…yeah I am a bit of a failure, I wish I was one of those 1 in a 100 dudes"'. Well, 99 out of 100 programmers don't read those posts. That's how they get by. They never confront themselves with what they don't know, don't read tech blogs, don't visit HN and never go to conferences, user groups etcetera. I've been working in this business for over 20 years, I have no illusions about my own limited abilities, but yeah, 99 out of 100 doesn't seem that unreal to me. The vast majority of programmers I worked with are utterly incompetent. BTW, in interviews I prefer to let the candidate talk about code rather than writing it. Conceptual understanding, and the ability to express that already tells me more than enough. Only when it comes to juniors fresh out of college I may want some confirmation that they can do more than talk a good game.

berntb 16y ago

I have a theory on this. Let me make an analogy to advice I gave to a naive female friend (personal theory, I'm not a psychologist). Consider psychopaths. They are not many (in percent of the male population), but if you go out and meet guys socially, you will meet a much larger fraction of them. That is because they use people and have to get new social environments quite often... I think it is the same when you interview programmers; the bad ones tend to apply for jobs much more. The interview process has a built in selection bias, so people doing interviews go crazy because most people they see are ass hats. And about white boards -- there are lots of subjects where I have good experience, but not recent enough to do a white board test. OTOH, one of the smartest people I studied with aced all the math courses but could never learn to program. [Edit: What I was trying to say here, an interviewer couldn't see a difference between us two by asking about e.g. a language I haven't used in a few years.] Disclaimer: I don't know how good I am, but I only look for work at most every few years... :-)

moron4hire 16y ago

This is why I don't give programming problems as questions. I've written numerous database applications and I really couldn't tell you off of the top of my head all of the parameters to make a proper database connection. When a mathematician writes a formula, it's a communication from one mathematician to another of intent. When a programmer writes code, it's primarily instructing the machine how to perform a given calculation; as such, it's an exercise in tedium and not very appropriate for person-to-person communication. So, that's why I ask design problems. I ask candidates to draw diagrams of databases that meet a certain need. I ask them to draw flow charts and state diagrams. These are much more conducive to human communication. I need to know that they can think before they can program. I'd hire someone with no experience in Python to start a brand new project in Python if they showed they had excellent problem solving skills because the hows of writing Python code is just going to be one more problem to solve for them. They'll figure it out and do what they need to do. When was the last time you know everything about how to program something before you started on the project? If the answer is "ever", did you stick around for the end or quit because you were bored?

stcredzero 16y ago

X% of programmers can program. But they do so in such a way that when they've added N thousands of lines of code, it starts to suck. An easy metric for suck doesn't immediately pop into my head.

nene 16y ago
WTF's / minute ? http://www.osnews.com/images/comics/wtfm.jpg http://www.osnews.com/images/comics/wtfm.jpg
- stcredzero 16y ago
  Good in the aesthetic sense. Bad in that this can be easily gamed.

fnl 16y ago

Great post, good points (had a good laugh about the loop and arithmetic assumption ;-)) and I mostly agree - although probably 1/3 of [academic/scientific] programmers [at least] really can't program (although that is much less than what got you about to post). [see Nature Oct 14, 2010] However, that is definitely less than the "majority".

nevinera 16y ago

>All of a sudden the headline is: X out of Y Applicants for Positions Advertised By My Company Can't Program Theres an important point here that he didn't make. The ones that aren't remotely qualified to even apply for the position? They applied to all the positions at every company they could find. Of course they seem to outnumber the remotely competent programmers; they sent out far more resumes, and by all the non-scientific metrics they get counted that many more times. In particular, this line bothers me: 'How much time did you spend making sure your ad was sufficiently attractive to the star developers and a sufficient deterrent to the crappy ones?' Making the ad attractive to 'star developers' is not the issue here, making it less attractive to resume-spammers is.

jasonkester 16y ago

Strange article. The author deliberately mis-quotes a bunch of sources to get his outrageous title, then calls bullshit on it. Then he goes in and actually reads the articles he's calling out, using quotes from them to support his point, which is also the point of the articles he's calling out. Everybody knows that this statistic refers to people applying for jobs, not working programmers. Everybody who's ever tried to hire in this industry has observed it first hand. Every article about it goes to pains to explain that it's a problem involving unemployable programmers applying for jobs they don't deserve. I'm not sure who this author thinks he's arguing with.

jdoliner 16y ago

As someone who does a lot of interviewing at RethinkDB I agree that these numbers are in many ways bullshit. Firstly they're pretty clearly hyperbolic (I think we all knew that already). However I think they also tend to be the result of a short memory span. Whatever the actual numbers may be (we should keep track) they are bad enough that every once in a while you get a run of ~5 interviews that really make you scratch your head. Which is about the time that these posts get written. The linked list question is designed as a smoke test. Admittedly it's a piece of code that one can do loads of coding without ever having to write. But bear in mind that in an interview we're looking for some code indicative of one's ability in the space of an hour, code that you actually write for production takes weeks-months-years and we simply don't have that kind of time. Questions like this have a high signal to noise; they're just esoteric enough that few people actually have a full implementation committed to memory but simple enough that anyone who gets the concepts of pointers and recursion should know just what to do. When runs of bad candidates pop up we do indeed reinspect our process. One major improvement to the process is to ask people question their resume suggests they should be more comfortable with. Ask questions in the more esoteric languages they know, ask questions in the field they did their research on. Obviously this greatly increases the chance of correct answers, thus these type of questions have a smaller correlation between a correct answer and a good hire. But what these questions can really do well is convince you that when this person understands something, he really understands it; he gets it well enough that he can very quickly explain it to me. This is very good sign in a potential hire.

davidmathers 16y ago

This is utter bullshit strawman trolling hyperbole. I remember reading Joel's post alluding to this back in the day, then Jeff's a couple of years ago Hmmm. The Raganwald post that Jeff's is based on says this at the top: 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. Wait, so what did Joel's post say back in the day? That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%. Ok, let's see how low you can go in your quest for faux controversy: One question immediately springs to mind: Is that x out of y applicants, or x out of y working developers? There is a massive distinction. O RLY? All of a sudden the headline is: X out of Y Applicants for Positions Advertised By My Company Can't Program. That's a whole lot less impressive/sensational and whole lot closer to reality. Actually, Joel's impressive/sensational headline was: News. I think you might be projecting.