
The Non-Programming Programmer - alexandros
http://www.codinghorror.com/blog/2010/02/the-nonprogramming-programmer.html
======
patio11
This is why I think that Codility (covered on HN earlier here:
<http://news.ycombinator.com/item?id=1039140> ) is such an amazing idea. You
can administer a web-based company-appropriate FizzBuzz for rounding error
next to the cost of doing an interview or (worse) hiring someone who can't do
FizzBuzz.

Incidentally, if you think Java programmers who can't figure out how to count
the number of occurrences of the letter "a" in the string "Java java java" are
bad, you should see how many interpretations of "advanced oral and written
Japanese proficiency" we've had. Oh boy. Let's hypothetically say you're a
recruiting company and you get a candidate as far as our door without
disclosing that their exposure to Japanese is, I kid you not, "I loved
watching Kenshin in high school" -- we will not be doing business with you
again. Hopefully ever.

~~~
gfodor
See, honestly I think something like Codility misses the point of these coding
exercises.

For me, a coding exercise is more than just a way for me to see if the person
can produce something that works. It's also a kick-off point for other
questions. Often there are things the person will do along the way to a
solution that reveals some lack of knowledge, so I keep my eyes peeled as they
talk through their solution for these potential gaps.

One of the biggest problems now is that you have people who can even pull of
FizzBuzz but don't know much of anything beyond how to get something like that
working. They don't understand data structures, algorithms, or how a computer
really works.

A simple coding exercise like FizzBuzz _can_ reveal these gaps too, even if
they get the problem right. The trick is to use their implementation as a way
to probe their thinking.

For example, if they are just using a "sort" function, like in Ruby, ask them
how it contributes to the runtime of their algorithm. Or, if they are loading
a file into RAM instead of just iterating over reads on a file handle, ask
them about it. Or, if they are iterating over the keys of a hash (h.keys), ask
them how they think that works. (This recently revealed to me the candidate
did not understand that a hash function was irreversible.)

None of the major gaps in knowledge I've found that separate mediocre from
good candidates were found by just looking at their code and giving them a
thumbs up or thumbs down. That's good for separating the mediocre from the
morons. To find out if they're good, you have to probe.

To find out if they're great, well, that's another story entirely that is far
afield from FizzBuzz :)

~~~
jlampart
"That's good for separating the mediocre from the morons."

That's a lot, if you ask me - the morons usually make up the vast majority of
candidates, so by filtering them out effortlessly at an early stage, you get
to spend your time more effectively - identifying the great ones among those
who at least hold a promise.

~~~
gfodor
Yeah a good point, actually. I actually am just subconsciously responding to
the implicit meme that seems to be spreading that if they get the coding
question right, they win. I think for screening out morons, that is probably a
good bar. But don't forget to do the next coding question in person, and drill
into areas where they gloss over things that they may not understand.

------
bshep
We were once hiring programmers for a small consulting firm.

We asked the prospective employees if the knew how to program for Windows, VB,
etc...

They almost all answered 'yes', when we asked them to write a sample program
the couldn't, so we asked them to describe how the would program something for
windows...

Their answer: 'You put the CD in the drive and run the setup.exe'

They all thought that programming meant 'installing' software... Needless to
say we ended up not hiring anyone.

------
SMrF
Whenever the FizzBuzz topic pops up on Hacker News in the back of my mind
there is a nagging anxiety: am I one of these programmers that can't program?
There is always some comment in the ensuing discussion that makes me question
my own competence.

~~~
RiderOfGiraffes
If you had contact information

1\. I'd send you one of my regular tests

2\. You could reply with your code

3\. I could tell you if I think you can code at this point in time, under the
conditions you used.

Or you could email me. 30 seconds of searching didn't find contact details on
the blog in your profile.

EDIT: amended 3 in light of insightful comment(s) below.

~~~
edw519
It's very easy for someone to misinterpret 3. as "I could tell you if I think
you can _ever_ code, so I would amend it to "I could tell you if I think you
can code _now_ ".

"Can't code now" could become "Is a great coder" later.

Everyone is at their own place on their path. We've all traveled that path. I
look at some of my code as recently as a year or two ago and I'm embarrassed.

Nobody here should get discouraged. You should just get better.

------
cake
Could this phenomenon happen because of stress ?

I've done several interviews where I was asked to code and I really don't
think it's easy, because you're under intense pressure of doing your task
right the first time and under a very tight time frame. Sometimes even with
your interviewer sitting next to you.

~~~
RiderOfGiraffes
The whole point is to use a task so trivial that even moderate amounts of
stress won't prevent your fingers from taking over. That's why people who
criticize "FizzBuzz" as not testing the true requirements for a job are simply
wrong. All you want is some real code that produces a correct answer.

My programmers wrote FizzBuzz in under 60 seconds. If you can't write FizzBuzz
in 15 minutes in an interview then you are either unable to program, or _any_
level of stress will prevent you from doing your job. Either way, you couldn't
work for me. I don't routinely stress my programmers, but stress is a matter
of observable fact.

~~~
Retric
I don't think it's just stress. Few programmers actually write correct code on
a whiteboard / pen and paper so expecting them to accurately program outside
of their preferred environment can be vary hard for some people. It's
something like asking an author to spell out an essay, plenty of people can do
it but it's a separate skill from being a good writer.

PS: Try composing your response by saying one letter out loud at a time
without typing it before you type it.

~~~
j_baker
I've had employers ask me to bring my own laptop and have me write my code on
it in front of them. That reduces the "whiteboard effect" tremendously.

~~~
Luyt
That would be a good solution for me, too. For example: It's years ago since I
used Visual C on Windows, but I use C++Builder daily. I can whip up a good
looking, surprise-free, standards-adhering, well behaved GUI in minutes and
flesh it out to a fully functional application without hesitation in the hours
after. If you'd put me behind Visual C I'd probably be looking for minutes to
find the Dialog Editor (errr.... is that Windows Forms nowadays? Hmmm, I
should give .Net a look someday).

------
forkandwait
I can't remember the link, but I read about one job where they gave candidates
an ssh login and asked them to write a simple, running, perl script. Something
like 10% actually finished the assignment, and they hired one of them, but
avoided screwing around with LOTS of screening phone calls, enthusiastic
people who "were familiar" with Perl, Windows programmers who didn't really
know what ssh was, etc.

~~~
RiderOfGiraffes
<http://neil.fraser.name/news/2005/09/03/>

------
geebee
I think this article does a good job covering the second best way of selecting
programmers - the technical job interview.

The best "interviews" aren't really interviews, though, they're recruiting
sessions. A really strong, experienced software development manager who plans
to employ programmers should have 1) a strong background in programming, and
2) a strong network of programmers who would jump at the chance to work with
him again.

You already know your potential hires are good programmers, because you've
worked with them before - in school, on side projects, at work, in various
collaborations. You don't need to ask them to print all the nodes in a binary
tree, and if you did, well, you'd probably lose the candidate.

I think Joel (on software) put it this way (I'm paraphrasing): if you're a
small independent film maker, and Uma Thurman expresses an interest in your
movie, you don't ask her to audition, you ask what you can do to get her on
board. I think 37Signals is another example of a company that mainly recruits
people they already know through programming projects (esp contributions to
rails).

I won't say the technical interview is evidence of a "broken" recruiting
system the way some people do, because let's face it, we don't all have the
recruiting mystique to wave the magic wand and get top people to join us, and
our networks just aren't big enough. So we _have_ to interview relative
unknowns.

But I will readily admit that this shows that I'm not doing it the best way.
This goes both ways. If I'm in an interview and people start asking me how to
implement a singleton, I start to wonder if I'm going about my job search the
wrong way. If I have to ask the candidate this, then maybe I'm going about the
recruitment in the wrong way as well.

But if that's your reality, then yeah, make sure you screen well.

~~~
barrkel
Except that even headline actors do audition - if the role is good, there will
be competition.

~~~
geebee
Wow, I didn't know that. Brad Pitt actually has to audition for roles? Jeez.
Well, that's the problem with analogies.

But I'm not really a fundamentalist about the code test. I've gone through
many, many, many of them. I just had a little epiphany the last time I was in
one. I was thinking, "why don't these guys already know that I'm a good
programmer? Why don't they already know good programmers?"

It made me realize as a programmer and as a manager that I wasn't really
building my career the right way. I decided that I wanted to build a network
and a reputation that went both ways - essentially, I wanted to have a large
number of people out there, in different organizations, who are both confident
in my tech skills and my value as a manager. I'll step outside that network
constantly, and when I do, I'll certainly validate programming ability (and
I'd expect people to do the same for me).

But every time I do this, it's a reminder that I failed on Plan A, which is
the best way to do things.

~~~
jimbokun
"I decided that I wanted to build a network and a reputation that went both
ways - essentially, I wanted to have a large number of people out there, in
different organizations, who are both confident in my tech skills and my value
as a manager."

How did you accomplish this?

~~~
geebee
Well, I can't entirely say that I did!

So far, it hasn't been much more than doing a decent job in the different
positions I've held, and working in a few different industry sectors. I've
worked for a large silicon valley company, a couple of public sector
organizations, and a couple of small startups, and I've taken on management
and dev roles. I keep up my contacts.

When the startup I was working for folded, I got a bunch of interviews (lots
of tech questions), but my best offer came from a former coworker who didn't
bother with a tech test because he'd already worked with me.

While I wish I could say I'd done more (presented at conferences, made big
contributions to open source, etc...), but in some ways this is a better
story, because people start to think that if they need to be a total rock
star. You really don't have to, just keep up your contacts and make sure you
have a reputation for good work.

------
mootothemax
I remember interviewing for the first time, where I'd asked lots of questions,
and then called back potential candidates for a proper coding test if they
passed the talking test. I know better now, but anyway, it was scary! The
amount of people who can talk about the inner workings of compilers, internet
protocols etc, and then can't do the fizzbuzz test is shocking!

The next time, I started with fizzbuzz and made life a lot better ;)

------
javajones
Part of the problem here is that not all interviewers can recognize a
candidates learning aptitude. Typically the interviewer is so enamored with
his own coding style that if the candidate can't mimic his style the candidate
is not acceptable. If the candidate does not communicate in the interviewers
style the candidate is not acceptable and so on. As well, most programming
projects are not about such simple problem solving tasks as printing out the
contents of a text file backwards. Of course most people could figure this out
and as my experience has been this is when most people think about such
issues, when they are required to apply it to a larger problem at hand.

------
timwiseman
First, as someone who has done a fair number of technical interviews, there
are a lot of posers. I have had people claim to be experienced that had no
clue how to do even very basic programming, just as described in this article.
Even more common, I have had people that grossly exaggerate their skills and
experience. One that stuck with me was someone who was a "senior DBA" but when
I probed further it turned out he mostly ran stored procedures written by
consultants and didn't really have the knowledge right then to do much more
than that.

I would also like to point out that if you are up front about your lack of
skills and applying for an entry level post, it can work out. I had one
interviewee who had no programming skills, but was ready and willing to learn.
She was up front about it, convinced the whole team of her sincerity, and
willing to start for less than most people with a CS degree. By the end of her
3 month probationary period, she was competent. Still junior and with a lot to
learn of course, but quite competent and a good hire overall.

------
calebgilbert
Just to state the obvious but all fizzbuzz really tests for is whether someone
is familiar with the modulo operator or not. Arguably any good programmer
should know about it, but I think it's not a very comprehensive check on the
knowledge of any one particular individual. Suppose for instance, that the
only bit of code someone has _ever_ written was something which required them
to get very familiar with the modulo operator, but virtually nothing else.
They could pass fizzbuzz, but not much else.

Note: The author of the 'non-programming programmer post' saw took my comment
down when I had posted it there (which is why I posted it here). Guess there's
no knocking of the fizzbuzz test allowed... :p

~~~
pavel_lishin
The first interview's purpose - whether in person, over the phone, or via
e-mail - should be to weed out the obvious idiots.

If you don't know what the modulo operator is, door is right this way, operate
it by placing your hand around the knob, turning clockwise, and pushing
forward.

~~~
calebgilbert
I've been programming for 3-4 years now, have memorized tons of functions and
operators, across a variety of languages, and have never once needed to use
the modulo operator for anything, so I personally don't place it at the top of
list of priorities for what someone should know. As an employer and
interviewer I'm more concerned the person has a grasp on general programming
issues and the ability to problem solve than testing their knowledge of narrow
subjects.

------
ciscoriordan
The post mentions a tool for live coding over the web
(<http://i.seemikecode.com>) that looks simple but good. Etherpad
(<http://www.etherpad.com>) is also real good for those and has some other
features like line numbers.

~~~
gkoberger
Bespin (<http://bespin.mozilllabs.com>) is even better for this. It's slightly
less realtime than EtherPad, however it is made for collaborative programming.
It has syntax highlighting and a bunch of other features for coding.

~~~
telemachos
Check your link: you're missing an 'a'

<http://bespin.mozillalabs.com/>

------
edw519
I was recently contacted by a head hunter for a job I thought was worth
investigating. I wanted to talk to the company directly, but the head hunter
made it clear that Step 1 was _always_ a web-based programming aptitude test,
no matter who you were. 20 questions. 18 correct was considered passing. They
would only talk to candidates who got 19 or 20 correct.

So I took the test and got 20 correct (as I imagine many people here would do
as well). I thought it was very easy. The headhunter later told me that in 9
months, she had sent 52 people to the test, only 2 of us got 19, and I was the
only one who got 20.

I'm not really sure what this means. That there are a lot of posers out there?
That she wasn't very good at screening talent? That the companies seeking the
best talent gladly pay $100 50 times to save their time?

I guess my biggest feeling is one of disappointment. It's just not that hard
to become a good enough programmer to get 20 right every time. All it takes is
study, passion, a lot of dedication, and a lot of hard work. I wish more
people would do that. There aren't enough of us.

~~~
TimothyFitz
Wish I could find the source, but the math is simple. If you're great (at
programming and marketing yourself), you pick where you want to work and apply
once (or more likely, are convinced to leave one good job for another). If
you're good, you pick a few places and apply a handful of times. If you're
bad, you end up applying constantly. The average unscreened resume is the
average person in the job pool, who is well below the average programmer.

~~~
arghnoname
I decided this seems like something one should be able to calculate with
conditional probability.

Let P(A) be the probability that someone is a pretty good programmer. (I said
top ten percent, so .1).

P(A') is 1-P(A) = .9

Let P(E) be the probability someone is employed. I guessed and put that at
1-P(E'), guessing programmer unemployment rate at 6%. P(E) = .94 P(E') = .06

Here is a more wild assumption. Let's say that given that someone is a top 10%
programmer, there is a 98% probability that he or she is employed.

P(E | A) = .98, and conversely, a .02 probability they aren not.

With these assumptions in place, I ran the calculations. I was intending to
type them up, but it would be difficult with just a text area.

Here is the punch line (with those symbols, and assuming I did this correctly,
which I did it on the bus on the way home, so probably not)...

Given that someone is unemployed, there is a .033 probability that they are in
the top 10% and a .96 probability that they are somewhere among the rest. (The
'rest' includes a lot of pretty decent programmers though!)

In other words, 3.3% of applicants would be top 10% candidates, and that's
assuming equal probability of them sending in an application in the first
place.

I might rework it with different assumptions. Anyway, you said the math was
pretty simple. If someone wants to see how I screwed it up I can type it up
into latex and upload it somewhere.

------
donaldc
Some of this may be due to selection bias. The good programmers find jobs
quickly, whereas the non-programmers go to interview after interview, until
they finally find a company dumb enough to hire them.

------
lele
It makes sense to me. Programmers who can program - and don't want to stop
working as employees - give up programming to pursue higher paying careers,
such as project management. Actually, many "programmers" nowadays can get by
simply copying and pasting code from the Internet. If you ask them how things
work, they don't know. That's my experience.

------
Roridge
I think that it is worse that most people who turn up for a Developer job are
just programmers, have no design skills at all.

~~~
barrkel
Most development outside web front-end work doesn't particularly require end-
user UI design skills.

~~~
berntb
That is correct, of course (otherwise, I'd be unemployed!). But what you
comment on might mean "design" as in "system architecture design"?

~~~
Roridge
I do indeed mean architectural design.

------
johnl
I would think "bring a sample of your coding" might be better. Non-programming
might include: Query language "programming". Maintaining an existing "out of
box application" Maintenance programming. End user support. Little real coding
is necessary. These are programming jobs but not really programming as I see
it but. Then there is the ability to learn new languages, processes, dealing
with the end user, is the code maintainable, code by specs?, juggling multiple
projects. I might start an interview by a sample code but that would not be my
only criteria and if the person failed the "programming" test I would see it
as a need for further discussion, not really a big red failure flag. Example:
If the reason the programmer doesn't know sql is because they spent their time
putting out fires and supporting the end users, I would hire that person over
the others any day.

~~~
brown9-2
This is hard-to-impossible for those developers whose entire development
career has been for companies (i.e. no OSS contributions).

~~~
blhack
Do most professional programmers not ever work on personal projects?

~~~
nitrogen
Most professional programmers probably view programming like any other job,
rather than a passion like I expect most HN readers do. As a result, they
leave programming behind when they leave the workplace.

------
radu_floricica
Along with the CV I always used to ask for code samples. I wanted to see the
code before I could develop any biases by talking to the person. I found it
worked best to ask for "the last project/projects you had fun working on, or
developed on your own time". If there are none...

------
yanilkr
In early stages, aspiring programmers need mentors. It would be interesting to
know how many people who consider themselves good programmers, spend a
reasonable amount of time mentoring other jr. programmers. Looking back in 7
years, there were only two good programmers I learnt a lot from. I took every
chance to read their code and ask them to review my code and pair program with
me once a while.

I became convinced recently with a new approach to this problem. If you want
an artist, pick someone with decent interest to learn art and put a brush in
his hand and he becomes a painter. It takes time but this is overall good for
the programing community.

------
ohashi
Out of curiosity, anyone want to share some of the questions they use or would
use in these situations?

~~~
magoghm
This is one test I've used: write a program that reads a text file and then
prints out all the lines in reverse order.

~~~
jbellis
I love interview questions that make Python look awesome.

~~~
Luyt

      python -c "print '\n'.join(open('file.txt').readlines()[::-1])"
    

Hmmm, slightly longer then the Perl version ;-)

    
    
      python -c "print '\n'.join(reversed(list(open('test.py'))))"
    

Somewhat more elegant, but still lots of parentheses.

~~~
RiderOfGiraffes
It's also wrong - "readlines" keeps the "\n", and you've added another one
between lines.

~~~
Luyt
Indeed. A cosmetic refinement, but it should really be:

    
    
      python -c "print ''.join(reversed(list(open('test.py'))))"
    

That's even two characters less!

~~~
spudlyo
Good, but too easy. Assume you can't keep the file in memory.

------
WorkerBee
I'm not sure about that article at all, actually.

My C++ and Java are very rusty, and I don't think I could do it on the spot if
I tried; let alone go into languages like python and ruby that are new to me.
But if you gave me a week or two, I know I could get up to speed.

------
va_coder
Tough questions without also building rapport is also bad.

I've had some interviews where they asked tough questions and I got a job
offer but I declined because I felt there was no rapport or interest in my
career.

------
yason
It seems completely unfathomable to pose for a programming job. It's one of
the rare professions where your skills and understanding can be tested very
quickly, harshly and objectively.

It would probably be easier to lie your way (with mere knowledge and possibly
some experience) into the position of a lawyer, an airline pilot, or a medical
doctor than a programmer.

(At least I hope they don't test doctor applicants as like "Please operate
this unfortunate cardiac surgery patient as an example so that we know you'll
know how to do it.")

------
zarski
Good article but didn't he write the same article in 2007 (as he mentions but
..)? This re-posting is a subtle shill for stackoverflow careers. Not that
there is anything wrong with that.

------
Jeema3000
IMO if you're giving people 'gotcha' programming tests in an interview, then
you don't know how to select candidates or interview in the first place.

You should be looking for competence by looking at their programming
accomplishments, both in and out of work, as well as their ability and desire
to teach themselves (probably the most important trait IMO).

~~~
brown9-2
This article doesn't mention "gotcha" programming tests.

~~~
Jeema3000
I disagree. IMO asking someone whether they can program a loop that
demonstrates the use of a mod operator is a 'gotcha' test because it proves
nothing as far as their suitability as programmer and as an employee and is
designed soley to weed people out based on one thing. Sure, _maybe_ they are
completely ignorant... or maybe they were just nervous that day or unfamiliar
with a particular language's mod operator. Lots of programmers don't do well
in high-pressure situations... which incidentally programming is _not_ most of
the time.

How about asking someone how they got interested in programming, or what sort
of things they've created with their knowledge in and out of work, or what
languages/technologies they've taught themselves in their free time, how they
go about fixing puzzling software problems, or what they consider to be good
vs. bad programming practices, or even what their hobbies are? - those kinds
of things that will tell you IMO whether they are smart, passionate, and will
make a good employee.

~~~
kaib
> unfamiliar with a particular language's mod operator

Just anecdotally, over some hundred interviews, I've never ever ran into a
candidate who failed one of these FizzBuzz style loop writing tests because
the didn't know the mod operator, or were nervous enough not to remember it.

I see a lot of candidates that can't remember what params some standard system
call is supposed to take and I always tell them I'm happy as long as they
define what they think it looks like. Heck, most of the time I have no clue
myself.

I'm not claiming the candidate you describe (competent but can't remember a
for loop) doesn't exist, just that I've never personally encountered such a
beast. Quite the contrary, with a technically open minded interviewer it seems
hard to get even the most introvert candidate to stop talking shop .. :-)

