Fog Creek Software
g
Discussion Board




How to spot an excellent developer?

The best programmers are 10x or more product than the worst. 


Any suggestions on how to spot best?

What traits are important?
How do you TEST for the traits?

My thoughts so far:


a.  Understands that there are always tradeoffs.
Ask him to solve a simple problem. See if he mentions that if we do more of A, we get less of B, etc.

b. Understands the importance of tests. Can create good tests.
See if he tests his solution to a, above. Did he ask what the success criteria was?  (i.e., is he thinking of testing for a solution that pleases the customer, vs. just testing to see if it "works")


c. Honest approach to problem solving.

Suggest an alternative, competing solution to A, above.
See if he gets defensive, just adopts your solution, or (ideally) compares tradeoffs between them.

d. Outcome focused
Did he ask what the "success criteria" was in A ?

(Remember Kwame asking, in his last Apprentice task, how the casino would measure success? Of course, then he basically ignored that goal <g>)



Naturally, there will always be tradefoffs. But I'd like to at least pick the best candidate from the field of choices.

Mr. Analogy
Thursday, May 6, 2004

actually 38 times better than the worst

a.) can be her too

:-)

Prakash S
Thursday, May 6, 2004

Mr. A,
I like that formula.

I would also suggest throwing some kind of ethical test, too.  i.e.:

Suggest alternate solution to problem A that involves getting away with something dishonest, although not necessarily illegal.  The alt solution should save the company a lot in money and possibly time, and possibly in the old CYA tradition for your department/team.  - see if he/she chaffs on the idea (ideally without getting all pious) or if idea is accepted unflinchingly.

ethical guy
Thursday, May 6, 2004

Too many people play games with hiring to make this work.  While you may approach it honestly, the person being interviewed is attempting to figure out if you are:
1 - anal and want to explain to them how to do it
2 - controlling and want to lead the effort in solutions
3 - incompetent and want someone who makes you feel good
4 - capable and in such a limted number unlikely.

The best approach is to bring the person on as a contractor for six months at 2x the pay. In that time you can see how they work and how they perform.  If at the end they don't like it or you don't, no loss.  They can even spend six months finding the next gig on what you paid them.

MSHack
Thursday, May 6, 2004

They read Joel's website and this message board religiously and chime in on such various discussion: the difference between code monkey and a developer & how many LOCs you produce. As you spot them reading this site, you will be able to leverage that as: "OK, you are so good at talk, how bout backing it up with some action."
At interviews, you can also quiz people if they know of this site, as a matter of fact, I would put it as a requirement for any resume filter.

AnonymousAmious
Thursday, May 6, 2004

"The best approach is to bring the person on as a contractor for six months at 2x the pay"

Which one of the 20 applicants would you do that with?


I agree that a temporary position is a great idea. But you still have to narrow the field of applicants down to the one you're going to try out.

I'm just trying to figure a way to do that intelligently.

Mr. Analogy
Thursday, May 6, 2004


Actually, one of the things that I read recently and have actually started applying...

I ask them what development forums they read, the 3 most recent books they've read, what technology (NOT software) is exciting them, and what one of their common usernames that they post on those forums with.


Then, go check out what they've written and whether they're tearing people down or making actual contributions.

KC
Friday, May 7, 2004

"what one of their common usernames that they post on those forums with.
"


Hi, my user name is PHILO  <g>.

Actually, that's GREAT advice.

Mr. Analogy
Friday, May 7, 2004

Ummmm, not wishig to deflate those that think this is the place to be, but as a proportion of the population of the world that might be interested in such things quite a small number know about it.

Membership of an ad hoc community where the majority of the correspondents are anonymous used as a way of filtering employment candidates seems, on the curve of stupidity, to be pretty far along.

Simon Lucy
Friday, May 7, 2004

When did we become more interested in what people write in forums and blogs than what they have actually accomplished in their prior jobs?

How do you even verify that the identity they are telling you they use on the forums are actually their own? Is it even worth your time? You have to read through a ton of messages to get the gist of what they may or may not know...

Then again, most HR people do have that kind of time in their hands between creating stupid job titles and shuffling health insurance providers every few months.

grunt
Friday, May 7, 2004

Here is my fantasy way of doing a job interview.  Screen the applicants by resume, obviously then set the day and time of the interview.  One or two days before tell the candidate that the first round of interviews will be held at his place of residence.

Go to his place of residence and ask to be taken to his computer.  Tell him to show off his stuff.  He should be working on an outside project and I want to assess it.  I want to see what it does, why exists, how it is designed.  I also want to see what tools he uses and ask him to discuss technologies starting with the ones he uses and leading to ones he thinks sound promising and finally talking abotu ones he has rejected.

If he passes this round bring him in to meet the team and give some technical interviews.

name withheld out of cowardice
Friday, May 7, 2004

name withheld out of cowardice,
Just ask yourself if you'd like to be interviewed like that...


That's true for any scheme anyone comes up with.

grunt
Friday, May 7, 2004

Holy cow. I get to say it again. If you want to know if a programmer is any good (like not just someone starting out) then read his code and judge that. If you can't judge that then you shouldn't think you can determine if they are any good. If they are just starting out, then they must have already written some code. Look at it. If they have not written any code, DO NOT HIRE THEM for any position. I've met people like that.

Imagine, " I want to hire a writer ..." should I give them an IQ test.  Duh ... read what they've written.

About posting to blogs hogs or whatever. Jeeeezzzz ...  why not see their responses to helping people in mailing lists and usenet newsgroups related to the things they say they know.  If they are a programmer have they not dabbled with some interesting apps on the web? I should certainly hope so.  I would certainly not ask them if they waste their time here or elsewhere.

The question about books is good though.  Then ask them if they've APPLIED anything they read in a book, and if by chance it's a yes, ask them to describe it.  More than likely what they've learned in any books will be reason not to work for you as it seems no one does it by the book. However, I usually find something from a book to apply regardless of the official (or just none) practices of where I'm working.

must remain anonymous
Friday, May 7, 2004

btw, I would care MUCH less how fast than if their code is efficient and is evolvable by someone other than them.

must remain anonymous
Friday, May 7, 2004

I would love to be interviewed like that.  It's an effect of the rule that people tend to judge other people's value by how similar they are to the ideal we project onto ourselves.  Thus it's obvious that I would like the sort of interview I come up with.  The real question is would most excellent candidates like it and would it really help me identify them.

name withheld out of cowardice
Friday, May 7, 2004

"If you want to know if a programmer is any good (like not just someone starting out) then read his code and "

Are you suggesting having him write code on the spot?
Or, bring a sample?

If the latter, how do you know HE wrote it?

Mr. Analogy
Friday, May 7, 2004

"Go to his place of residence and ask to be taken to his computer.  Tell him to show off his stuff." 

An excellent candidate would tell you to go to hell if you said you wanted to enter his home to look at what is on his computer.  Only a desperate programmer would put up with that intrusion.

NoName
Friday, May 7, 2004

Read their code. Okay, I admit, I don't know that many programmers ... personally I know about 6.  I am aware of many others because I've read their code and I've received their help on mailing lists and newsgroups. I'm a Perl/PHP programmer and I make extensive use of CPAN/PEAR. I think I know of one perl/php programmer who probably never put any code in the public ... now that I recall, he was, and I'm not bashing, really a MS type programmer who a client had writing Perl scripts and I had to vet/debug them (not idiomatic Perl).

I recall one time when I did not ask to see someone's code. I was finding my replacement at a company. This guy was just finishing up a book for O'Reilly and had a great resume. I didn't ask to see his code.  He was the man and he got the job and now everyone think's I'm a dummy :)

If someone gives you code he did not write and you cannot perceive that nor figure out how to test for that ... well, then I think you've got more problems.

But seriously, would I hire a baseball player and ask him puzzles about velocity and distance ... I'd get an academic. No, me, I'd watch him play baseball or I would have seen him play or ask someone I trust who saw him play.

Just to give someone something to ask who can't read code, I'd ask him what he does before he starts.  I'd ask him about globals (cus I got a pet peeve).  What is his attitude about coments, if using Perl does he use strict but then gosh all this is in his code.

I've worked as much if not more on code written by others. You can see the style. I've worked on projects where you can see where one programmer wrote one section and another wrote another etc .... code where variables are in foriegn languages (happened to be Portuguese which I read so that helped ... another thing ... do they choose variable names that indicate purpose/meaning or just because they are slow typers) ....

etc. etc. etc.

must remain anonymous
Friday, May 7, 2004

I second that. Read their code, and lots of it. Non-redundant code is clear code. Clear code is good code. To actually test someone would require *you* to be 10x better to understand their design choices fully.

Jonas B.
Friday, May 7, 2004

Ask the candidate to bring "a large piece" of code with him/her, then have the person go over it line by line, explaining it to you.  Also have them give you the "meta explanation" or overview of what all the classes/modules do.  If s/he didn't write the code, but can explain it really really well, then s/he can probably reproduce something close to it.  Either way it's a good test.

You can certainly identify someone who stole a chunk of code from someplace and doesn't really understand it.  That will be obvious.

Biotech coder
Friday, May 7, 2004

Reading their code is fine if you're hiring code monkeys. Really, guys, can you not assess someone from their background and what they've done? I can.


Sunday, May 9, 2004

*  Recent Topics

*  Fog Creek Home