
99 Out Of 100 Programmers Can’t Program – I Call BS - duck
http://www.skorks.com/2010/10/99-out-of-100-programmers-cant-program-i-call-bullshit/
======
gvb
_[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> \-
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-
cr...](http://blognewcomb.squarespace.com/essays/2010/10/14/cult-
creation.html) (discussed here <http://news.ycombinator.com/item?id=1793095>).

~~~
rdtsc
The person who is interviewed should be interviewed at least for a full day.
They should be presented with a large set of problems, both "fizzbuzz" type,
design problems, debugging problems. They should talk to the top technical
people in the company, with those they will be working with, and with as many
other people as possible.

This is even more important in a small company. A small company cannot afford
to hire a dead weight. A couple of those will kill the company -- they waste
resources, don't get work done, and, what is perhaps very dangerous, drive
away top technical talent who does not tolerate mediocrity.

~~~
acgourley
This sounds great in theory, but can also be a big time waster for your top
dev talent. Especially so considering you usually start hiring when you're
especially crunched for developer resources.

The interview process should be extensive, yes, but it should also be spread
out in a way that allows you to fail candidates early. Blocking out a day of
interview time at once can be inefficient - rarely will that person be sent
home early (for various reasons) and they are now just wasting a bunch of
peoples time, and their own.

~~~
JanezStupar
Think of all the time they will be wasting with this person if she turns out
not to be a good fit.

You presumably want people who will enhance and help your top talent.

~~~
rdtsc
That's exactly the point and this inversely related to the size of the
company. Imagine if IBM hires a dead weight, the company is so big and there
are so many other positions that the company as a whole will not be terribly
hurt (unless it's the CEO perhaps).

But with a small company, when you have 5 people and you hire the 6 and it
turn out to be a bad choice, it could kill the company.

------
fiveo
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
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.

~~~
fiveo
Those skills are not specifically for corporate jobs by the way. A typical MS
shops (regardless what you build) will require at least .NET 2.0/3.5 with
ASP.NET (not even MVC), WPF, WCF, WWF, Silverlight, and SQL-Server. A typical
Java shops would require you to know J2EE, Servlet, JSP,
Tomcat/Websphere/JBoss, Maven/Ant, JUnit, XML (with some would ask of GWT
experience).

But a couple days ago I told myself to ignore the rat race. I then bought a
Linux book specializing in command-line, a Vim book, and a Rails 3 book. (Why
Rails? um, why not? it's better than those corporate tools). I don't care if I
have to learn PHP. As ugly as it is, it's still better than using .NET tools
(regardless if it's ASP.NET MVC or not).

C# could be a better language, but I just want to use light-weight tools (even
if it means I have to learn many-many tools). No more heavy weight tools.

I noticed that the people who choose the lightweight path (C/C++, or LAMP/RoR)
seems to be able to focus on what matters the most: learning skills that can
last longer than .NET version 2.0.

------
Construct
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
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.

------
kloncks
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.

~~~
gaius
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
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
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
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
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.

~~~
DisposaBoy
Ant, waf, and the rest of them are usually overkill IMHO. With makefiles the
basics are simple and straightforward and I'd argue that most uses only
require the basics, it's like what I've been hearing about autotools these
days but even autotools seems overkill especially on Linux where we've had
proper pkgconfig support everywhere for years. The same is probably true for
the BSDs as well. I can't comment on Windows or OS X as I have no experince
there but I imagine it must be easier to write a couple basic makefiles for 2
differnt platforms if you need. Most cross platform projects don't need as
they either use Gtk, glib, Qt, etc which already pulls in all their
dependencies.

------
agentultra
_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'

~~~
mechanical_fish
_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._

Every physicist can solve first-year physics problems on the back of a napkin.

Every mathematician can solve first-year math problems on the back of a
napkin.

Every machinist can sketch her approach to making a widget on the back of a
napkin. Electrical engineers can sketch schematics. Chemical engineers can
sketch reactions. Architects do nothing _but_ sketch.

Why? Because practice makes perfect: In most technical fields, thinking on
paper is an important part of basic education.

Why? Because even at the highest level so much of the most important creative
work is done on whiteboards or notebooks or lunch-counter napkins, often in
the middle of an impromptu jam session with the smartest peers you can find.
My Ph.D. work was mostly involved with machines and materials, but the
essential plans and conclusions were sketched out on a set of whiteboards in a
series of evening discussions after eating pizza with some folks from my
research group. This was completely typical.

If you can't think about programming without electronic help, does that mean
you can't think about programming while walking down the street, or showering,
or shaving, or doing dishes? If you can't discuss software, even at the oh-so-
basic level of an interview question, without a screen and keyboard in front
of you, does that mean that you can't design software while eating at a nice
restaurant with your collaborators?

If you can't communicate technically in person in real time -- and we're
talking _really basic_ stuff, not formal proofs of Euclid's Algorithm or
anything -- why should you be hired onto a team? The team can just outsource
you.

~~~
Retric
There is no such thing as first year programming problems. At best you provide
a simple problem with minimal constrains, but they have nothing to do with
professional programming.

PS: What would you do if someone said write a function that will sort these
three numbers? Hint: there is no safe answer.

~~~
mseebach
> Hint: there is no safe answer.

I'd be interested in hearing what you're thinking of -- but if you're right
that actually makes it a perfect interview question. The baseline
implementation is simple, but you can keep pointing out deficiencies and
observe how the candidate attacks the revised problem.

The point of interview coding problems isn't to produces production-quality
code with no preparation, it's to gain some insight in the way the candidate
attacks a problem, _particularly_ when approaching the edge of his abilities.

At one of the interviews I went through for my current job, I completely
tanked on a question that fished for a particular design pattern. But while I
didn't figure out I needed to use that particular pattern, I was able to
participate actively in the discussion on how and why the solution I chose
wasn't optimal.

~~~
Retric
Simply put based the type job your applying for there is types of solutions
they are going to want to see. Without knowing more about the job you may be
thinking frameworks while they want ASM.

~~~
ori_b
Then ask for elaboration. It's a discussion, not a monologue.

~~~
Retric
Of course, but that's not a year one problem. If I say how much energy does a
10kg rock gain falling 50m in a 1G gravity field you can just solve it.
However, when handed a simple programming problem the natural instinct is to
ask for just a little more information.

I find many programmers have issues quickly context switching between thinking
about the problem, discovering what the constraints are, coding a solution,
and then debugging that solution. Ask them to do it on a blackboard under a
little pressure and they can't do it. The problem is the better programmers
often do worse in these situations because they think about more things at
each step so they need to keep purging more ideas.

------
jdp23
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.

------
rickmb
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.

------
KirinDave
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
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.

------
makuro
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??"

~~~
japherwocky
+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
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> 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
hm, actually I might be wrong. Shame on me for trusting my memory. :)

Double flame then! Someone give us some real statistics!

------
Maro
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
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.

~~~
Maro
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.

~~~
endtime
Okay, fair enough. I probably wouldn't apply for a job like that, but if I
were I'd make sure to learn a bit about DBs first, if not networking.

------
moron4hire
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?

------
davidmathers
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.

------
jdoliner
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.

------
damoncali
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
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.

------
jasonkester
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.

------
dawgr
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.

------
nevinera
>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.

------
Encosia
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.

------
codyguy
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.

------
stcredzero
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
WTF's / minute ?

<http://www.osnews.com/images/comics/wtfm.jpg>

~~~
stcredzero
Good in the aesthetic sense. Bad in that this can be easily gamed.

------
devmonk
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
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.

------
fnl
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".

------
known
Interview != Quiz

------
berntb
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... :-)

