Fog Creek Software
Discussion Board




Hiring programmers: pragmatic advice?


Hi,
I'm considering hiring a programmer for our small software company to move some of my programming tasks to them.

We'll probably have someone offsite, as our town is relatively small.

Any good books, articles, or horror stories anyone would like to share?

"My biggest hiring mistake" perhaps ? <g>

Certainly, one thing I'll do is "try before I buy", e.g., give them a small task and see how that goes.

But I'd also like info on how to filter through all the applicants to narrow down to WHO I'll try out first.

Mr. Analogy
Wednesday, June 09, 2004


Stop your search and just hire me.  I probably have many, if not all, of the skills that you're looking for.

I'm looking for some side work and don't want to move.  I have the goal of eventually finding enough stable work to go completely independent.

There, you're problem is solved.


Seriously.

KC
Wednesday, June 09, 2004

I'll work cheaper than KC.

Starving Romanian
Wednesday, June 09, 2004

I'll fix it after they've both broken it.

Simon Lucy
Wednesday, June 09, 2004

I'm also looking for work, but the last time I checked this wasn't monster.com.

Hiring is a personal thing.  Contrary to everything people will tell you about hiring for smart/get things done you will hire them based on their looks, tone of voice, disposition, whether or not you feel threatened by them and various other attributes, the least of which is smart/gets things done.

Anon
Wednesday, June 09, 2004

Don't listen to the guys trying to get you to hire them on this board...  They don't know what they are talking about...


Now, on to other business.  I can do everything that you need, twice as fast with half the cost!

H 1 B
Wednesday, June 09, 2004

One of the distrubing trends that I've seen is lying on the resume.

I was looking at monster.com, and came across a couple of consultants that I worked with.

Both COMPLETELY LIED on their resume.

The one was an indian resource that didn't even speak english.  The guy was so green that his company gave him for FREE.  He did not do 1 thing on the project, other than slow people down.

His resume, however, read like a superstar.  It talked about technologies that we didn't even use on the project, but he did it all.

If I were to read the resume not knowing this guy, I would have thought, "Here is a damn solid guy."

So, be leary...

Consultant
Wednesday, June 09, 2004

Depends what is important to you.  If you want a technical rock star, look in the discussion groups for the technology you need or find guys with respected blogs on the subject a proposition them.  If functional savvy is critical, make sure you emphasize that in your requirements.  If you are going to fixed bid it out, ensure they will follow through.  Many developers will bid it way too low and then give up when they realize their estimate was terrible; this could kill you at the wrong time.  If you are doing hourly, don't just choose on rate. 

Ted Graham
Wednesday, June 09, 2004


I would agree:  Give him a bunch of little things, let him make his own estimates, then pay him that much.

IE: Feature X.  He estimates 10 hours and wants $25/hour.

Offer him $300 for the feature and give him two calendar weeks.  (The extra $50 is for support after ship.)

Once you've got a few things this way, then talk about something more regular - EG 10 hours a week or whatever.

Paying by the feature is pretty cool, and it provides him incentive to do work quickly, but not too quickly.

Matt
Wednesday, June 09, 2004

I hate when people say "only hire smart people who get things done." Well, sometimes "smart people who get things done" don't apply, and you keep looking, and looking, and looking for years. Meanwhile, your company having to turn down work, and profit.

Sometimes it's better to hire the best you can find in the time you allocated, and just move on and make sure YOUR COMPANY gets things done.

As far as people who lie on their resumes, here's my advice to them: if you're going to claim you did all the sophisticated hard stuff on a project, don't then list you only worked on that project (or at that company) for two months.  I see that a lot!

Ron
Wednesday, June 09, 2004

You are starting correctly imho. Have people do some work. But will you just judge the results by the results? What language will you want it written in? Show me code in PHP or Perl and I can tell you how good the programmer is.  So I'd suggest finding someone who knows your target language and ask them for suggestions on things like "they must always use warnings/strict in Perl, no use of global in PHP or no including files in PHP .. instead they modularize it and variables are scoped and not weaking havoc" ... I was once vetted this way but the programmer who vetted me did none of what I just said yet he did a lot of work that worked but wasn't so easy to evolve for the company who employed me ... but now that programmer does follow that advice (at least for Perl). I think experience will show that using warnings/strict in Perl saves a lot of time. I wonder if there are similar examples for other languages.  For making evolvable apps I've found nothing better than an OO approach yet programmers can knock out solutions that look like they work quicker by just cut and pasting code and if you just judge the results by the results then I think you will be mislead ... because there are 2 rules: change and evolution and the fast approach doesn't lend itself to either.

Try some of those freelancer boards ... I've hired 4 people between rentacoder and scriptlance and they've done good jobs. Mind you I gave guidance and they were no better programmers than me and in one case I suggested other ways to do something and the programmer picked it up and finished the job and provided some value added. I had a guy do some use cases for an idea I have and I had another guy create a data model for the same idea. This cost me US$300.00 http://www.errorcode.com/findnew/latest/ and this cost me US$100.00 http://www.errorcode.com/findnew/index.php?page=DatabaseSchema just to give you an idea.

onlyhirethebest
Wednesday, June 09, 2004

"One of the distrubing trends that I've seen is lying on the resume."

Yeah, it tends to wrinkle them.

sgf
Wednesday, June 09, 2004

> Offer him $300 for the feature and give him two calendar weeks.  (The extra $50 is for support after ship.) ...Paying by the feature is pretty cool, and it provides him incentive to do work quickly, but not too quickly.

Matt, you obviously run a highly successful ISV or IT department.

Mr Sarcasm
Wednesday, June 09, 2004

Dont go solely on personal recommendations either. In singapore last year we hired an Indian subcontinent lady, her vb skills were ok. And the thought was she was competent at working from home. OH OH, big mistake. This woman was always behind schedule, her kids were getting in the way, she lied about deaths in the family to explain her delay (somehow, someone always conveniently dies around the time a project is due), no documentation, no comments, and worse of all, she kept bumping up the price when it was clear the project was depended on her. It came to a stage where we just had to cancel the whole project. I tell you,we suffered a serious setback. So I'm telling you Matt, leave no stone unturned, a solid foundation will be the direct output of a successful outcome. Please learn the lesson from idiots like me. :)

Mark
Wednesday, June 09, 2004

There are a lot of competent Romanians and Romanian companies. Hire one of them.

Their culture and mentality is a lot closer to yours than the Indian culture.

Competent Romanian
Wednesday, June 09, 2004

Sorry, the above comment was directed at Mr Analogy, not Matt. Its almost 4am over here :(

Mark
Wednesday, June 09, 2004

"There are a lot of competent Romanians and Romanian companies. Hire one of them.

Their culture and mentality is a lot closer to yours than the Indian culture. "


Can you elaborate?

Mr. Analogy
Wednesday, June 09, 2004



Seriously, I'll reiterate some of comments from above...


-  *ALWAYS* start with smaller projects that are *NOT* mission critical.  (You shouldn't outsource mission critical stuff anyway..)

-  Demand interim milestones that meet pre-established requirements concerning quality, documentation, comments, etc.

-  Be willing to pay for quality.

-  Be careful of the liars...  Last year, my team leader and I were interviewing an "XML Expert" who didn't know what Xpath was..

That's all I got.

KC
Wednesday, June 09, 2004

>>"There are a lot of competent Romanians and Romanian companies. Hire one of them.
>>Their culture and mentality is a lot closer to yours than the Indian culture. "

>Can you elaborate?

They put out all the best viruses.

Kyralessa
Wednesday, June 09, 2004

Andrei Alexandrescu is Romanian :)
(www.moderncppdesign.com)

non-romanian
Wednesday, June 09, 2004

Hey, that's one smart Indian lady. (and by the way, cut her some slack if her kids get in the way. I was a kid myself once.)

> ... she kept bumping up the price when it was clear the project was depended on her

We would all do this if we had any brains, since we're artificially underpaid as it is, compared with other roles that require less intelligence and learning.

The talent of the Indians has been screwing the dopes who run Western corporations. Maybe we can learn from them after all.


Wednesday, June 09, 2004

Just to add my two cents worth... 

We are a small (< 3 programmers) ISV that is slowly growing. When asking for applications get the candidates to send in some of their source code. You can eliminate a lot of candidates pretty quick if you start seeing questionable variable names, poor layout, zero commenting etc.

In the interview ask a couple of technical questions, but don't get too involved. They are usually nervous and not in familiar surroundings. Test them enough to ensure their mind can come up with a solution to a simple problem in a reasonable amount of time.

As others have said.. .give them a few "trial" type tasks over the next few weeks. The best things I like to give are standalone tools and utilities: fixing some problem with database records, creating an exporting/importing program etc. Pretend they are a contractor. Be prepared to spend maybe 25-50% of their time sitting by them letting them know where everything is, and what your standards are. By simply spending time with them any personality clashes become apparant and you can confirm their ability to absorb information.
(the best rookies keep a notebook of things they have learned or discovered, and never ever have to ask the same question twice).

Then gradually introduce them to your own components/libraries, and main source tree. By that time if they are still with you then you should be able to trust them to work on real stuff. And as long as you have a half decent version control system in place, you can always undo their changes if they screw up royally.

All the time keep probing them about what they want to do with their lives, and how they are liking it at your place. The point of all this is that as a small company you can't really afford to have somebody start work, and quit a few months later. All the knowledge you have parted is lost and you have to start again.

Good luck and be prepared to sift through A LOT of people before finding one you want.

PDF
Wednesday, June 09, 2004

Hire the smartest people/person you can find.  You can train them to understand the business, you can train them to code to your corporate standards, but you can't train them to think.

Brad
Wednesday, June 09, 2004

Hire someone whom you think you won't have to clean up after.  Say to yourself: "Would this person hold up my work because I have to hold their hand all the time?"


Wednesday, June 09, 2004

> When asking for applications get the candidates to send > in some of their source code

Wow ... what a novel idea that seems to always escape these ubiquitous quests for Kobes at  what ... the best place to work at for the best salary.

People need to get real. I once told a sales person to take the garbage out of her sales material. She was describing us in such bullshit terms ... I asked her one question "do you think I'd be working here if that were true" ... she blushed. Just be real with people. I told her I'd stick by a customer and work night and day if ever a problem arose that had to be fixed and if need be I'd bring in a Kobe to fix it.

So now that you realize that you just need someone to be there M-F and do the job ... that your company is not the LA Lakers paying NBA rates so you know  you wont' be hiring Kobe ... look at their source code. How obvious but if you don't know what to look for find someone who does.  Get to know their personality. Do they realize that without customers there is no business? I'm always amazed at how people have a condescending attitude towards customers. I personally am too often condescending towards my cohorts.  No customer, no business. Work ethic. Look for examples of a work ethic. You are hiring a programmer. How in the world would a programmer with a work ethic who likes their work NOT DO SOMETHING related to what they do, i.e. write apps or participate in usenet or online sites etc ....

Is all of this just not plain obvious?    

spent18monthswithnojob
Thursday, June 10, 2004

What is this Kobe bullshit? Trying to use him tirelessly just in hopes of it sticking to become a commonplace noun -- that'll not work, sorry, dear fans :)

GG
Thursday, June 10, 2004

<Quote>I told her I'd stick by a customer and work night and day if ever a problem arose that had to be fixed and if need be I'd bring in a Kobe to fix it.</Quote>

Why would she want you to bring someone in to bend her over and rape her when she just wants her system fixed???

That's what us consultants are for!

Consultant
Thursday, June 10, 2004

Always have them fill out a job application even if they have a resume with the same information.

An application is a dated document with specific claims (e.g. working history, academic degrees). If you find out later that their resume is false, it is harder to defend against an enployment claim.

The job application can also explictly allow you to actually call their references, check their credentials, etc.
-------------------------------------------
If you find later that you have made a mistake in hiring, take responsibility for it and either put them on probation (and YOU be the one to monitor them) or discharge them (carefully); do not make your other staff bear the burden of your error.

Richard C Haven
Thursday, June 10, 2004

*  Recent Topics

*  Fog Creek Home