Fog Creek Software
Discussion Board

Questions for a Remote Contractor

I have submitted a project for bidding on  I have had good experiences in the past with RAC, but that developer is not available at this time.  I was lucky in finding this guy; everything turned out OK without a prescreening process.

But I want this time to be different.  Are there any differences in this situation vs. interviewing a contractor in person?  What topics should I cover that are different than the standard employee?


Friday, June 11, 2004

Ask them if they smoke crack while coding. can test a local employee for that, but it's kinda tough to test someone in India for it.  And hey, if they're delivering you what you want for really cheap, why should you care?

Friday, June 11, 2004

You should care. My experience with, well... let's call them "people who don't speak english good" - no offense - is that they don't ask questions if they don't understand something, or if they discover that something's wrong with your spec. They just darn code the thing, and you'll have to debug it yourself.

Really, this has happened with my projects, which were outsourced to the East. It's a culture thing. But it seems to work to tell them in advance that you like them to insult you if they feel like it. Seriously. It's a tip. Oh, and don't use fancy words ;-)

Friday, June 11, 2004

"people who don't speak english good"

That's "people who don't speak english *well*"


Friday, June 11, 2004

Um, that was kind of a joke, Philo. But as I noticed you can be funny at times, I suspect you're making one of your own here.

Don't think you've seen "Zoolander" though, in which a model (Ben Stiller) sets up his own "center for children who can't read good, and want to learn other things good too". I thought that was kinda funny, so I used the joke here. But if I've gotta _explain_ it... sheesh... :-D

Friday, June 11, 2004

I'm in a situation similar to the OP.

One thing that I look for (and I suspect is hard to find with ESL (English as a Second Langauge) programmers is that they may not spot potential problems and recommend solutions.

To me, this is where a programmer can add alot of value. I certainly did when *I* was the programmer.

Mr. Analogy
Friday, June 11, 2004

Dear Mr Yes

If you think you can achieve good results using cheap rent-a-coder services, please don't expect professional developers here to sort out your mess.

Friday, June 11, 2004

When posting on a board generally populated by posters whose jobs are being outsourced, I'm thinking that when you ask "how do I ensure I get a quality performer" the only answer you should really anticipate is "hire locally" ;-)

(Sorry about the correction - didn't realize it was irony; we don't get much irony around here)


Friday, June 11, 2004

I would suggest you get someone local verify the code. I would not be suprised if they put in viruses or backdoors. If you hire someone local you can hold them responsible for such actions but not if they live you don't know where.  I could no resist.

Friday, June 11, 2004

Remote developers usually want to find as much work as possible. Exactly like local developers.

This is their motivation for doing a good job (along with the payment, of course).

Tell them that if they do a good job, you will have more work for them. Also tell them that if they do a good job, you will recommend them to other people who may have projects, and that you will provide positive references.

Be very clear about what you expect from them.

You want them to find problems in your spec? Tell them! Tell them this a few times, as clearly as possible.

Write a text about what you expect from a remote developer, including things such as respecting deadlines, finding problems in your spec, notifying you ASAP if there is any unexpected problem with the program or the spec, etc. Send this text to each remote programmer or firm you work with. Improve the text over time.

I have worked as a team leader and found that the results of the team improve if:

1. I tell them in advance exactly what is expected, with sufficient details.

2. I tell them everything 2-3 times, in different forms.

3. Include images and diagrams in your spec. I use SmartDraw for this.

You may laugh at tip #2, but I have picked it up from a serious psychology study which proved this.

Remote Developer
Sunday, June 13, 2004

I have worked as a remote developer for clients in USA and in Western Europe. I found that there is a cultural difference between the two:

Europeans take the time to explain what they want clearly. Americans seem to always be in a hurry, and they don't take enough time to explain.


Remote Developer
Sunday, June 13, 2004

>Americans seem to always be in a hurry,
>and they don't take enough time to explain.

I'm not remote, and have experience only with American companies, but I can tell you that the failure to spend time on requirements and analysis is endemic, and causes most of the "never get the project really completed" failures.

I mean, when the Engineering director says "Use the previous product as the specification" when going from Windows/C++ to Browser/Java, and four people work for two years without ANYTHING written down, lots of bugs and problems are to be expected.

Let me add: I am serious, there is not a single document other than code comments in the entire project. No overview, no list of pages, in particular no test plan. There is nothing.

I was hired to work on the legacy product. There are no documents there either, but people who have been around a long time to explain. If there weren't available, I don't think I would have learned a thing and would have been utterly ineffective for the first year.

Sunday, June 13, 2004

*  Recent Topics

*  Fog Creek Home