The Codist - Programmerthink

So What Is A Good Programmer Employee Anyway?

Posted: 01/03/2007, Perm Link Readers: 3942


The article about Google using an algorithm in its search for better employees got me to thinking about what makes a good programmer-type employee?

If you read the job ads (I am looking for some short term contract work at the moment so it's relevant to me) you would think the perfect employee knows nothing but technologies X, Y and Z, has good verbal and written communication skills, and is willing to be work for peanuts. Yet some of the brightest programmers I have known or worked with were often times irritable, had poor communication skills, were capable of learning 12 new technologies a day and wanted to be paid well. Yet other programmers I have known and respected were completely the opposite.

Most of the average programmers I have worked with have been pretty poor at not only learning and applying new technologies but even going slightly beyond their comfort zone in the areas they are supposed to know.

It is odd how the job ads (and talking with recruiters as well) seem to indicate that all the client will accept is precisely what is written in the job request. If you do manage to get hired, you find the actual job and the people you work with bear little or no resemblance to the initial demand.

Of course there are jobs where you need to know X, Y and Z and nothing else, and the environment never changes, but I think the reality of the software industry is that everything changes.

Thus one measure of a good programmer is how well they can adapt and learn new languages, technologies, and methodologies while still being productive. If all you know is a single technology suite and have no experience in adapting to change, how does that make you a desirable employee? Unfortunately you never see that in a job ad. It might be that it's too hard to tell someone who knows nothing from something who can learn anything.

So if Google thinks it can find better employees with some unusual survey questions by tying features of their best employees with a set of non-work skills, then why not try.

The last two places I worked have gone through 30+ interviews and even more resumes trying to find even a single decent java programmer. Some of the people I interviewed I thought would have made a good employee despite not having the letter of the job requirement, but it's difficult to convince managers of that. Then again you often see people who in their resume seem perfect for the job but in the interview you discover they've never really done anything other than cookie cutter projects.

If I were hiring I would rather have someone with a history of delivering projects using a wide variety of technologies and languages (assuming they weren't just making that up) than someone who has done one thing 50 times.

My resume is full of projects with totally different technologies I did for my various employers (and my own) so I guess I would hire me. But it does make it more difficult to verify a resume since you can't easily prove ability to work with anything, as opposed to just repeating the few things you do every day for the past 5 years.

So maybe Google's approach has some merit and it may find special people they a more traditional (as traditional as Google every was) employee search would miss.

Tags: programmer, it
Alex 01/04/2007 03:15

Nowadays there seems to be a majority that thinks, a developer should know 10 different programming languages to be taken seriously. A developer that is proficient with only one, two or three languages is characterized as a incompetent wanna-be. IMHO it is the other way round. Choose a slot in a domain and practise hard to become the best. So if someone has done a thing 50 times i call him an expert. Hire him, because he is much more experienced and productive in his domain than the other dudes. Often people claim that they know many programming languages. But if you seriously test them you find a lot of boasters. It takes many years to become really proficient with a language like Java.

Anon. 01/04/2007 07:59

>Nowadays there seems to be a majority that thinks, a developer should know 10 different programming languages to be taken seriously.

A programmer familiar with a large number of languages is a passionate programmer.

>Choose a slot in a domain and practise hard to become the best.

A programming language is not a domain - computational biology, image processing, and physics modelling are.

>It takes many years to become really proficient with a language like Java.

Yeah, the darn gag reflex really makes learning Java a drawn-out process. ;)

Seriously though, a programmer that knows (brief experimentation in college does not count) a wide variety of programming languages has experience with different modes of expression - and that will make him a better programmer in any language. Even languages he has not yet learned.

Tony Perrie 01/04/2007 09:09

There is no generalized system for judging people that can work. Any attempt to systematize innovation will fail because getting indoctrinated into a large organization destroys your soul.

James 01/04/2007 12:56

> There is no generalized system for judging people that can work. Any attempt to systematize innovation will fail because getting indoctrinated into a large organization destroys your soul.

Their not trying to mechanize innovation. They're looking for qualities that are likely to be found in innovative people. It's probability, not certainty.

JMS 01/04/2007 15:51

There's also the fine balance of technical interview vs. 'experience' interview. A few months ago I changed jobs; one of the places I interviewed had a tight little technical questionaire and a good f2f interview, while another had one of those 'I KNOW MORE THAN YOU' technical interviews.

There's no silver bullet ;) But...I do think that gut feeling has never steered me wrong; I've interviewed at least 50-100 people in my career, maybe more. The gut-feeling never steered me wrong.

Whaty about writing code? 01/11/2007 23:18

I ask them to reverse a string using iteration and then reverse it using recursivity.

Then I ask them if they can find a bug in their code. That shows if they have an emotional attachment to their own code (always a bad sign) and if they can politely think and defend themselves. That is really what you want: People who can actually code, solve bugs, work with others and think.