Guy Kawasaki has a new article called How to Get a Job on Craigslist. He recently posted a job listing there and got 37 good candidates. This is a great reminder of the power of Craigslist.

At Slantwise, we’ve hired four full-time employees in the last few years, and we found two of those on Craigslist. We’ve also worked with about 6 key contractors over the last three years four of those came through Craigslist.

Guy lists a few job application tips in his article. Here are my tips.

1. Build trust. Since any job hiring is based on limited information – a few conversations, not months of actual work – we’re going to hire the person we trust the most. This is a matter of skill (do we trust that you know what you’re doing, and that you can excel in your role?) and personality (do we trust that you’ll work hard, take your job seriously, and work well with others?).

2. Be specific. “Good communicator” doesn’t mean a thing to me. Everyone says that. “Spoke at three conferences” or “blogged weekly for two years” is meaningful. The same goes for project/development skills. Let us know what projects you’ve worked on and what your role has been. Go deeper if possible – “Built a SOAP adapter for (foo)” is better than “experience with web services.”

3. Avoid jargon. If your email looks like it was taken from a “how to write a cover letter” book, or some sort of Dilbert job-application-generator, I won’t take you as seriously as someone else. The right job application will sound professional, but professional in a one-developer-to-another way. If you were out for a drink with a peer from another company, how would you explain what you do?

4. Apply for the right job. Don’t copy-and-paste. Explain why you’d be good for this job, not just any designer/developer/manager job. When I’ve posted to Craigslist, I’ve typically gotten about one generic job inquiry for every personal one, and not surprisingly, the generic ones don’t get much of my time.

5. Worry about the email, not the resume. Sure, send me your resume too, but it doesn’t matter that much. A good email (what used to be the cover letter) should tell me everything I want to know. Namely: what relevant skills do you have? Where have you used them? Have you worked on any open-source or hobby projects? What do you do to further your skills, apart from work? And what do you do in your spare time? It will also set the tone for your application.

6. That said, don’t worry about your application too much. We are not going to hire someone based on the quality and composition of their cover letter or resume, or based on how smoothly a phone interview goes. We’re going to hire someone because of their skills and personality. If don’t interview very well, but you’re a kick-ass developer, guess which part is more important to us?

Next time we need to hire someone, I’m going to use two resources: Craigslist and the local developer community (RUM and MinneBar, mostly). Whether you’re looking to hire, or looking for a job, I highly recommend using these two tools.

We may be looking for some help this summer (and beyond), so we put a Ruby Developer Wanted post on Craigslist. We’ve had great success with Craigslist in the past; we found two of our employees and two of our key contractors there. But of course, the signal to noise ratio is lower than we would like. We usually get form-letter offers from offshore developers offering .NET or Java skills (even though we specifically ask for local Ruby developers).

This last time, we got a priceless email from an applicant that I’ll call Ivan (not his real name). Ivan’s email started OK – “saw your Craigslist ad and I’m interested,” etc. Quickly, though, problems came to the surface.

• Ivan doesn’t do Ruby work. He’s mostly offering design, along with PHP and ASP.

• Second, Ivan won’t work onsite, even though he appears to have an area code in the Twin Cities.

• Third, Ivan doesn’t really appear to be looking to do any work himself. He is offering to subcontract the work to others. “I can staff as little as 1 part time, to as much as you need (50+ full time designers).”

This isn’t remarkable so far. I usually get a few of these when posting to Craigslist. But take a look at the next paragraph:

“Let me explain how we work a little bit here. I have system surveillance software installed on the computer which will send you an E-mail every X minutes with a screenshot of my computer (50k in size each). This way you can be sure that I am working on your project at the scheduled shift and you can see the quality of work as it is being produced. You can also use this to confirm that I came in on time to my shift, and left on time, etc…”

This is wrong for so many reasons.

1. I don’t wan’t to sift through X (10? 500?) screenshots every day to make sure that my contractors are doing their job. Nor do I have time. The reason we might need a contractor is that we’re too busy to do the work ourselves.

2. Seeing screenshots taken from someone’s computer just feels slimy, like an intrusion of privacy. Even if Ivan is sending them to me (instead of me stealing them from him), it is not something I want to do.

3. How absurdly easy would it be to fake something like this? Heck, it would probably be easier to fake it than to do it for real.

4. We don’t hire people based on the idea that they will sit at their desk for 8h/day. We hire people to get things done. This is a misdirected approach to productivity.

And of course, the only point that really matters:

5. Ivan has destroyed any sense of trust. He’s asking me to expect deceit, and giving me a means to protect myself against his deceit (and an unreliable one at that). There is no way in hell that I would work with a contractor who I didn’t trust, no matter how many screenshots he offers me.

As I think about it, trust is even more important than competence. I’d rather have a trustworthy employee who made mistakes than a genius who I didn’t trust. Fortunately for Slantwise, we’ve been able to find both. I don’t think I’ll break our streak by hiring Ivan.

We’ve used a daily stand-up meeting at Slantwise Design for almost a year, variously called our “stand-up,” or “scrum,” or “duck” (don’t ask). At about 10am every morning, the six of us at Slantwise get together for a short meeting to answer three questions:

1. What did I do yesterday?
2. What will I do today?
3. Are any obstacles keeping me from getting work done?

In theory, the meeting should be quick – maybe 10-15 minutes. In theory, it should facilitate communication, put everyone on the same page, strengthen our team, and drive our projects forward.

In practice, it hasn’t worked for us. So a few weeks ago we dropped our morning stand-up, for five reasons, which I’ll outline below.

As a freelance RoR developer, I run across all kinds of clients. My favorite kind of client is the type that will actually get his application into production. Beyond the rate that he pays me, a running-in-production application is what I want. We’ve all seen sites where people show off their work; you know the portfolio page that just shows thumbnails and an application description. Well call me crazy, but I want to see more!, and your next potential client will want to see more too. Ideally, you’ll be able to show off your hard work in all its splendor! Therefore, you need to work on projects that will launch.

There are clients, however, that want your services and are willing to pay, but won’t be able to give you another nugget for your portfolio. Most likely, the client is too emotionally attached to accurately weigh his chances of launching, but by running a few filters you’ll get an idea. A little disclaimer, none of these filters are right all the time. This is fuzzy logic. Use them as signals or cautionary flags.

1) The client doesn’t have wire-frames or any user interface mock-ups.

I described this in detail here. Essentially, if your client has mocked up his application, he has passed an important gate. If there are no mock-ups, then at a minimum he has some work to do before you really get rolling on the app-dev side.

2) The client would rather describe the application to you over the phone instead of with a document.

This is even worse than not having design. He is one of the most frustrating clients you can have, because he has probably seduced you with the big idea. You probably like the guy enough to overlook the fact that he has no written plan. But by taking this guy on, you become an enabler—you have set up your client to let you down. Put some gates out there before it’s too late and help him help himself. Don’t promise to work with him until he can show what he wants in writing.

3) Creating this application fulfills a personal mission for the client

Everyone has their white whale. Parents, past failures, messianic complexes, we all have something we want to “overcome”. If your client is on a personal mission, then he is polluting his business mission. I once had a client who basically said to me that he didn’t care if the application failed in the marketplace because he “had to do it.” Serious!? If this thing doesn’t launch, how am I going to show my next client what I’ve been doing for the past couple months? Aren’t therapists cheaper than Rails developers?

4) “Are you interested working for equity?”

Run!! The project you’re working on is so far from production, it’s not even funny. What’s funny is that you are still working on it, and haven’t been looking around for new clients to bail you out! I have a friend who was working for a database startup that was going to kill the relational database market with their new “organic” database. When I pressed him to describe the product in simple terms, he couldn’t. When I asked him who the beta customers were, there were none. That’s when I told him the writing was on the wall. Later that week, they laid everyone off, asked them to work for minimum wage in cash, collect unemployment, and work for equity. Later that month, the primary angel investor was arrested for funding the company with embezzled money.

A bird in hand is worth two in the bush. Always take money before equity. Only take equity if it’s on top of your full rate. If they try to cut your rate and offer more equity, the project won’t make it to production.

5) After a payment or two, the client asks if you can reduce your rate.

Oh man, this one is sad. Bad vibes fill the air here. You can just feel that your client wants you around, but that you’re eating into his financial bone marrow. For God’s sake, shoot ol’ yeller and get a new contract!

6) “I’m going to lean on you heavily to tell me what this application should do.”

I fall for this one all the time. Being involved in business decisions is really fun for me plus it makes me feel important—it’s ego-stroking. But am I the one who should be figuring out what the user of the application wants? Look, it’s great when the client values your opinion, but beware. Your client should bring the business/customer expertise, and you should bring the technical expertise. Start tapping your network for contract leads if you find yourself telling the client what the product should do.

7) The client doesn’t have a customer who wants to use the application before it’s built.

Evaluating this differs depending if it’s b2b or b2c. If it’s b2c, then the client should have a marketing plan that you can read and understand. It should breakdown who the customer is, how many there are, and what they’re willing to pay. Your client should also have a few regular joes ready to sign up. If it’s a b2b app, absolutely do not sign on until your client has businesses ready to go before the app is built.

In conclusion…

There are many signs that your project won’t make it to production, but these are a few that either I or my friends have ignored. Are there any I forgot? Let me know in the comments.