

Some Developers Just Can't Develop - gnosis
http://www.richard-banks.org/2009/08/some-developers-just-cant-develop.html

======
geebee
"Now one of the things I was doing with new hires at the time was getting them
to work on bugs – it helped me knock down the backlog and gave them exposure
to a variety of areas across the system. I also gave them plenty of time early
on to learn the ropes and get up to speed and it would typically take a few
days to get through the first few bugs and start having some ah-ha! moments
with the codebase."

This is a little bit of an aside, but how many people out there take this
approach with a new hire? If you're a manager/team lead, do you start new
developers out fixing bugs? If you're a developer, how do you feel when bug
fixes are your first assignments?

Personally, I think that fixing someone else's bugs is one of the hardest
tasks in programming. Depending on how the interview went, it can also be a
very depressing and alarming task (autonomy? creativity, opportunity to
influence the project? we've found that our recruitment success increased by
10% every time we used one of those words. now here's your task list, go fix
some bugs).

I want to be sure that I emphasize that people have the right to pick their
own management style, and I'm not questioning it. It also sounds like Richard
was very reasonable about this - giving programmers adequate time to navigate
the system (though "adequate" is a relative term... if "a few days" is enough
for new devs to have their a-ha moments and fix several bugs, you probably
have very high quality code and documentation).

But let's add this as reason #458 why young programmers prefer to start their
own companies: their first "assignment" is creating a product, not fixing
someone else's crap code.

~~~
j_baker
Well, two things:

1\. It's a great way to learn a new codebase.

2\. It's a good way to get some political capital so that you can get autonomy
more easily.

You just don't usually start out with the plum assignments when you start a
new job. If you do, you won't be given the autonomy to make them satisfying.
So in my opinion, it's better to start off with jobs that you know will be
drudgery to prove your worth than it will be to get a neat-sounding task where
you'll be kept on a short leash.

~~~
geebee
Fair enough. I think this is an important thing for developers to understand
about themselves before taking a job. Do I want to work with a large existing
code base? Do I want to work for an organization where I need to build
political capital to gain autonomy?

For some people, the answer will always be "no". For others, it's complicated,
and potentially impossible to answer without trying out the company for a
while.

Suppose the code is well organized and understandable. The bugs are not the
product of bad design, they're just the inevitable side effect of any real
software project. The programmers who created these bugs are largely still
with the organization, they are highly competent, and are more than willing to
help a new dev get up to speed - and the documentation (and code quality) is
so good that it usually isn't necessary. Lastly, the team and management is
eager to give autonomy and flexibility to a talented, proven dev, so it's not
a problem to build up that "political capital" you mentioned. Well in this
case, what you said is reasonable and more than acceptable to many good devs,
even if it isn't right for everyone.

Then there's the nightmare scenario - the team is not highly competent, and
the reason you were hired is that the good programmers keep quitting and
there's nobody to help you. The code base is a mess, and documentation doesn't
exist or is useless. Even getting a build to work is difficult and painful.
The reason the management is giving you bug fixes is that they don't really
know what to do with a new hire, so they assign some bug fixes, that'll keep
you busy for a while. Lastly, they're aren't interested in listening to new
suggestions, so political capital won't get you anywhere. O course, in this
case, I suppose it doesn't really matter what your assignments are.

By the way, there is another way to get political capital. In my first real
programming job, I had an almost ludicrous amount of autonomy. Like, "find
something that might be useful and write software for it" levels of autonomy.
This was the dot com boom, and there was enough money to hire people for this
kind of thing. Of course, they didn't give me high impact assignments, but
they did give me broad flexibility in meeting (and even determining) my
assignments. This can be an alternate way to build up the political capital
you mentioned. Instead of having a limited role on a high impact project, you
have a broad role on a low impact project. That can work well for some people
- however, these jobs are very rare. Usually, you have to trade the stability
of a paycheck for that kind of freedom, especially early in your career.

------
vimes656
As many blog posts this one focuses on the "false positive" candidates, the
guys who get hired but turn out to be bad.

But I would be curious about the false negatives, the guys who were rejected
(or almost rejected) but turned out to be truly good. Why they gave the
impression they were bad in the first place? How did they proof the initial
assumptions were wrong? What were they doing bad in the interview?

Does anyone have experience with these "false negatives"? How not to miss them
in spite of a bad interview?

~~~
bluesnowmonkey
I've been a false negative several times, I'm sure. Here are some of the
reasons why.

1\. Poorly defined questions. One time, the interviewer kept referring to the
browser as "the server" (in the context of a web app), despite my questioning
him about it several times. After 5 or 10 minutes of trying to figure out what
he even wanted, I told him I didn't want the job and ended it. From his
perspective, he'd successfully weeded out an incompetent. From my perspective,
I avoided working for someone with terrible communication skills.

2\. Unclear objectives. One interviewer asked me to extend a small language by
adding string support. No problem.

"OK, I'd start by modifying the parser."

"That's not what I had in mind."

"But that's clearly the first step. This isn't even a real language. What's
the point here?"

"To get a feel for how you approach a problem in the real world."

"Well in the real world I'd modify the parser."

"Well just don't."

3\. Pointless questions. "List some design patterns." Seriously? Sometimes my
mind blanks on such questions. There's GoF over there on my bookshelf, and I
could talk about the nuances of when and when not to use (almost) any
particular pattern if they'd mention one, but from their perspective I know no
design patterns at all. From my perspective, I'm glad I didn't end up working
at a place whose screening process selects for rote memorization.

4\. Insulting questions. "Write a for loop." I mean, I just told you I've been
coding for 17 years. You're basically calling me a liar. I don't respond well
to that. Enough of these and I might turn you down and walk out. A
professional relationship (like any relationship) requires a certain amount of
trust, so an interviewer this jaded/distrustful casts doubt on my ability to
be accepted and productive there.

5\. Trick questions. I hate them and I might have to count down from 10 if you
ask me how many square manholes are in Beijing or whatever. You'll probably
think I'm googling the answer.

6\. The "figure out on the fly what I learned by reading a paper" question.
Frequently I'll respond with a working but sub-optimal solution, then they'll
prod me with hints until I come up with (or more often don't) the _exact_
algorithm they had in mind. Sometimes they can't even explain what I need to
improve about my answer, they just tell me to try something else. Sometimes
this is the first question of the interview, and if I don't figure out the
clever trick it becomes the only question, because they let me spend an hour
banging my head against it without moving on. From their perspective, I
answered zero questions and might not know anything at all. From my
perspective... well I have no perspective by the end because I'm so tired and
angry from being put through such a process.

~~~
kgrin
RE #4 - note that the context here is the embarrassing inability of many
applicants to, in fact, write a simple for loop.

~~~
Tycho
I suppose good developers should be glad when these basic questions come up in
interviews, cause then we can rest assured that no incompetents are nicking
our jobs (or warming the seats for a few months until they get sacked, thus
slowing the hiring process down for everybody else).

~~~
cpeterso
Plus these questions can assure that you get hired to a team where everyone
knows how to write a for() loop. :)

~~~
pnathan
Oh, goody. I would feel assured that I would work with people at the level of
CS 1, as a professional.

------
gaius
We phone screen candidates and you would be _astonished_ how often you'll ask
a basic question then the phone goes dead silent (i.e. on mute) then 20
seconds later he's back and rattles off an answer. Sometimes they don't even
mute and you can hear the keyboard clicking as they desperately Google.
Sometimes while doing the phone screen _I_ Google, and read what they've just
said from the top result back to them, y'know, for lulz.

These days there's so much content around that some people in surprisingly
senior positions can wing it, Googling some stuff then c'n'p, and slyly
passing the rest to cow-orkers, at least for day-to-day tasks, and at least in
the short term. Then one day everyone's busy and Jo(e) Faker has to do some
real work.

But you've got to watch out. The very slyness that makes them do this will
also get them promoted to management...

~~~
jarpadat
The joke's on you if your interview process consists of asking googleable
questions.

Asking "Define X" questions is a really bad proxy for assessing development
skill. If you think developers are winging it by c'n'p--any interviewer who
asks the candidate to produce a bunch of facts for an hour is the same, if not
worse. You don't interview a classical pianist by asking him what notes are on
the keyboard.

~~~
gaius
The questions are on an ascending scale - this weeds out the bad candidates
early on. Things like keywords and syntax are easily Googlable sure, but
people who really do this stuff every day will rattle through that section of
e interview in 5 minutes.

------
code_duck
I hear this a lot. Which attractive positions can I apply for where my
competition will be people who can't code a CSS rule for a class versus an ID?
Are we really trapped in a competency bubble on sites like HN and don't
realize the vast incompetence of the majority of computer professionals?

~~~
cpeterso
I read about (and have interviewed a few) "developers who can't develop". Is
this phenomenon unique to the software industry, since it has no formal
licensing boards and the technology changes so rapidly? I can't imagine
doctors who don't know medicine or lawyers who don't know the law.

The lesson is that interviewers must give coding questions even to "senior"
developers. See, for example, the "FizzBuzz" interview question:

[http://www.codinghorror.com/blog/2007/02/why-cant-
programmer...](http://www.codinghorror.com/blog/2007/02/why-cant-programmers-
program.html)

~~~
code_duck
I've run into doctors, specifically a psychiatrist or two, who have not kept
up with changes in their fields. Considering psychiatry is fairly fast moving,
that's somewhat like if one went to college in the 80s and learned COBOL and
DOS, and glossed over everything since then. Definitely harder to get away
with doing that as a lawyer, though!

~~~
cpeterso
To remain certified, MDs must taking Continuing Medical Education classes
every year and a recertification exam every 6-7 years (I think). I believe
attorneys have some similiar requirements

------
alex_h
Assuming these inept candidates are not Frank Abagnale types just doing it for
the thrill, I wonder how they are expecting the job to actually turn out. I
mean what was the guy expecting to do all day if he couldn't write a single
line of code?

~~~
X-Istence
But Frank Abagnale proved that he was at least able to learn as he was going
along, like he studied for and passed the bar.

I think it would be interesting to work with someone like that, especially in
software, you can mould them to anything. Would I enjoy it for the first
couple of months? Probably not, but clearly not everyone you hire has to be
excellent, sometimes you just need people that learn fast and are able to pick
up new things easily.

------
_stephan
I have a hard time believing that you can't detect that someone has absolutely
no clue about programming just by asking about his past projects, drilling
down on some specific technical challenges he encountered during those
projects, quizzing him about his preferences for programming languages,
libraries and stuff like that.

~~~
watmough
Some people have a very narrow experience, but within that experience, they
can actually be pretty darn good programmers.

I worked with a bunch, none of whom ever ventured outside of Visual C++ and
SQL, and who would never have even heard of Ruby or Python or Clojure. Despite
this, they could still knock out pretty decent real-World code.

In that case, it can be difficult to filter out the bad ones, just based on
general conversations, without asking people to actually code on a blank
board.

------
dspillett
Ah, memories of the tool whose CV stated "Javascript: Advanced" and "jQuery:
Intermediate" but who asked me to explain what the $ was in some code... It
took _far_ too long for us to convince management to get shot of that one.

~~~
Joeboy
In many js libraries $ is an alias for document.getElementById, whereas in
jQuery it's an alias for jQuery. It might have been a reasonable question to
ask.

~~~
dspillett
Not for someone who is "intermediate" in jQuery.

He didn't even recognise $ as a valid function name which rules out exposure
to other libraries mapping it to different behaviours, and the use of an
anonymous function (remember: this is someone who claimed to be "advanced" in
Javascript) _really_ blew his mind.

------
russell
A couple of decades ago, I first ran into the professional incompetent,
someone who can have 8-10 years of good experience without having accomplished
anything. She (sex means nothing, just tweak the adjectives) was attractive,
intelligent. articulate, easy to work with, but thoroughly incompetent. She
was assigned to do a piece of one of my projects. I worked with her for a
month but she couldnt get anywhere, an the VP insisted that I work with her.
Finally I isolated her code and spent a day implementing the task. After a
couple of years she was canned.

The professional incompetent part? She had had the same kind of two year stint
for 10 years. I'm glad she wasnt y hire.

------
16s
Have them write FizzBuzz (or something similar) give them 15 minutes to do it
(more than enough time). Leave the room so they don't feel pressured. Offer
them the OS and compiler of their choice. Ask them to write it in two or three
languages, but only one is OK if they run out of time.

If they write something that compiles, give them a point. If it is well
commented, give them another point. If the results are correct, give them
another point. More than one language would get another point as would
finishing early, etc.

It's pretty easy to weed-out people who cannot program by doing this and it
doesn't take that long.

~~~
tjarratt
What exactly would "well commented" mean for fizz buzz? One of my pet peeves
are devs that comment insane things that should be obvious from reading the
code.

eg:

#save the model and pass along a callback model.save(callback)

If you were writing code that was as simple as fizz buzz, would you really
write any comments at all?

~~~
16s
Just my opinion, but here are my comments to FizzBuzz.

<https://github.com/16s/FizzBuzz/blob/master/FizzBuzz.cpp>

~~~
Confusion
I don't think those comments are very helpful. I think a function-level
comment would be much clearer.

    
    
      # Outputs 'Fizz' when +arg+ is divisible by 3, 'Buzz' when
      # it is divisible by 5 and 'FizzBuzz' when it is divisible
      # by both 3 and 5.

~~~
16s
That's a matter of opinion. I always do this. Now there is no question what
each conditional is intended to do. So if I make a mistake, you can clearly
see from the conditional comment what I meant to do.

------
brendoncrawford
Obligatory obfuscated FizzBuzz python solution:

    
    
        ###################################
        import sys;map( sys.stdout.write,[#
        ''.join(map(chr,([0x46, 0x69,0x7A,#
        0x7A,0x42,0x75,0x7A,0x7a] if not i#
        %0x0F else[0x42,0x75,0x7A,0x7a] if#
        not i%0x05 else[ 0x46, 0x69, 0x7A,#
        0x7A] if not i%0x03   else[int(c)+#
        0x30 for c in str(i)  ])+ [0x0A]))#
        for i in xrange(     0x01, 0x65)])#
        ###################################

------
watmough
Yeah, it's true, but many of them are able to prosper in large systems where
lots of code can be copy-pasted around.

Here's my string reverse. Actually, it might be the first damn time I've ever
reversed a string in code. Thoughts.

    
    
      #include <stdio.h>
      #include <stdlib.h>
      #include <string.h>
      
      int main (int argc, const char * argv[]) {
      	
          /* alloc mem so we can reverse in-situ */
      	const char * s  = "reverse me 123";
      	char * rev = malloc(strlen(s));
      	strcpy( rev,s );
      	
      	/* reverse the string 'in'  */
      	for( int i=0 ; i<strlen(rev)/2 ; ++i )
      	{
      		char tmp  = *(rev+i);
      		*(rev+i) = *(rev+strlen(rev)-i-1);
      		*(rev+strlen(rev)-i-1) = tmp;
      	}
      	
      	printf("string: %s  reversed: %s",s,rev);
      }

~~~
palish
Bug #1:

    
    
      char * rev = malloc(strlen(s));
    

... It should be malloc( strlen(s) + 1 ) to include the NULL terminator.

Nitpick #1:

    
    
      char tmp  = *(rev+i);
    

should be

    
    
      char tmp( rev[i] );
    

Nitpick #2:

    
    
      i<strlen(rev)/2 ;
    

"strlen(rev)" is evaluated every iteration of the loop.

Nitpick #3:

    
    
      *(rev+i) = *(rev+strlen(rev)-i-1);
      *(rev+strlen(rev)-i-1) = tmp;
    

Those two strlen(rev)'s are evaluated every iteration of the loop.

Why not write it like this?

    
    
      for ( int i(0), iLen( (int)strlen(rev) );
            i < (iLen / 2);
            ++i )
      {
          Swap( rev[i], rev[iLen - 1 - i] );
      }
      }

~~~
cpeterso
1\. `char tmp( rev[i] );` is valid C++, but not C.

2\. Your for() loop is still dividing `iLen/2` every iteration. Presumably the
compiler would hoist the division out of the loop, but the code would still
add some cognitive friction to future readers of this function. :)

Here's my attempt:

    
    
      void strrev(char* s)
      {
          char* a = s;
          char* z = s + strlen(s) - 1;
          while (a < z)
          {
              const char c = *a;
              *a = *z;
              *z = c;
              a++;
              z--;
          }
      }

~~~
watmough
This is the one I like. :D

I have interviewed people, but I gave up asking coding questions, since no one
could ever do them. And if you keep thumbs-downing people, you don't really
get invited to interview any more people.

Thanks again!

------
rorrr
I've written about this a few times before. I've done many interviews over the
last 2 years. Before I started at that company, their interview process was
pretty much as the article described.

We started by designing a set of technical interview questions. A few simple
ones, like reverse a string. A more complex ones, like reverse digits in an
integer. And then even more complex and practical ones with algorithms, but
still very trivial. At first another developer and I thought they were too
easy.

When we started interviewing, we made a shocking discovery that around 90% of
the candidates can answer even simple questions. Very few people can write a
correct function to reverse a string. Just think about it. These are the
people that will have to write complex production code.

Out of 50 people I think we had one guy who answered all the questions. A few
times we allowed candidates to use their laptops (it was their choice), one
candidate spent like 30 minutes writing the reverse function, didn't really
help him.

Our success rate was pretty much 100%, we have not hired one bad developer.

TL/DR: always ask interviewees to write some code.

~~~
3pt14159
What language was this in? In ruby this would just be "hello".reverse, and
even if you didn't have that available to you there would always be:

    
    
      acc = "" ; "hello".size.downto(1) {|i| acc += "hello"[i-1]}
    

or the more rubyist way of doing it

    
    
      "hello".each_char.to_a.reverse.join
    

Or probably something more clever I can't think of at the moment. Was the
language so crippled that they were worrying about UTF8 characters? It can't
possibly be that 95% are that bad. How could they possibly do _anything_?

~~~
rorrr
Sorry, didn't answer your question fully the first time, was in a rush.

The languages we interviewed for were Javascript and PHP (for different
positions). There are lots of newbies out there who pick up the basics of
these two languages (due to their popularity), and then try to get high paying
jobs. Most of them are used to copy/pasting the code from the internet.

That's extremely prevalent among Drupal developers. Drupal has a ton of
contributed modules, so you can get pretty far without writing a single line
of code. It's really really hard to find a good Drupal developer.

I'm completely serious about 90% not being employable (by my standards).

