I've been thinking about getting some more coders to help out with my MUD, but I've been hesitant for fear of either finding someone who isn't serious about helping, or some crackpot who doesn't know what he's doing.

So how do you screen for coders? How do you know who's trustworthy and who really knows what they're doing?

The only effective way to screen coders is to watch them in action. Have a trial period of 1 month+, during which they have to prove that they know what they're doing. Most people who aren't genuinely interested will balk at the idea of actually having to work, and will generally just leave.

LoL some great suggestions that I definitely plan to take into account. Especially the singing one.

Actually we've been trying to install CVS but ran across a few problems. I don't suppose either of you would be willing to talk with me a bit about it?

I'm head builder and HIMP and I'm relegated the task of hiring coders since I don't own the world or code. I found one upon urging of another Imp and since I don't code, I was somewhat clueless as to how evaluate since I couldn't authorize shell access.

Now that's a real dilemma for me and probably a position I shouldn't have been placed in, but it fell to my lot. My instinct said to learn the individual on a personal basis, see how they behaved as an immortal and perhaps a player. Do they have the patience to build a zone which I doubted since they would learn the shortcomings and good points of OLC and builder interactions with flags etc. My goal was watch and see temperment, patience, frustration with existing code, interaction with other Immortals/mortals etc. Finally after a few months and little to no building but decent behavior, I vouched for the coder.

First thing the head coder asked me is "is he a good person?" I responded "I'm pretty sure he is, he listens and tolerant, though he doesn't have the patience to build." With CVS enabled and the newb coder input being reviewed by the head coder and me, all has progressed reasonably well but the point is, my instinct said a good person from watching.

Resume, coding examples, etc are good values to judge by, but when push comes to shove the twit who will steal your code can't handle power. The abuser or thief will be impatient and do wierd stuff. MAKE them actually play and/or build for you before you hire, you will learn tons if you watch them as well as learn the "flavor" you strive for in your world. In the same breath I also advocate CVS as a failsafe medium for controlling as well as establishing Head Coder permissions in the shell that can't be overridden.

In the LPMUD world, it's a bit easier, since a creating wizard doesn't have to have write access to the mud's lib. That would be a privilegie of the admins.

But when it comes to having write access to the lib, I will never allow that unless I have met, in real life, the person in question, and I have their name and number.

I think it's very difficult to discover if someone is trustworthy or not from a simple interview or two.

However, to discover if they can code, in my experience, asking a basic coding question filters out 95% of the riff-raff... For example, on the last mud I worked with, literally only 2 out of 15 applicants knew the correct answer to the following VERY basic debugging question:

Why does this cause a crash?

char string[4];
strcpy(string, "1234");


Another good one is asking the applicants how to get a crash dump from GDB, given a core file.  Only -one- of the 15 applicants got this, and knowing how to use your system's debugger is such a critical skill for a mud developer.  
The same one was also the only one who knew the command line syntax to compile a c file.  I kid you not.

I should mention that all of the applicants could talk a good game, and just chatting with them about design issues, etc wouldn't have turned up their serious deficiencies in programming skill.

Of course, being a programmer myself, it is perhaps easier for me to spot these sorts of deficiencies, but having -any- programming knowledge whatsoever is often enough to seperate the wheat from the chaff.

Saren

i guess i started way wrong but i am lucky. the mud i started i found a great programmer, and im thankful that he did know his stuff and hes honest, we now have a small staff and now moved from modifing a codebase to making our own. I myself have *basic* skills in C, yes im a n00b when it comes to programming but im learning, slowly. but anyway they way i do it now is that i have my Head programmer interview them frist and if they can convince him that they are good he gives them a test, its about 10 questions i think not sure realy but so far only 1 out of 8 passed the test.