How To Find Bad Programmers

AmberShah writes "The job post is your potential programmer's first impression of your company, so make it count with these offputting features. There are plenty of articles about recruiting great developers, but what if you are only interested in the crappy ones?" I think much of the industry is already following these guidelines.

Comments

Re:I see lousy coders.... everywhere

[oldspewey]

You want a good coder? ... Have them write you something small for free.

Most of the good coders I know would walk right on out the door if the first thing you asked them to do was write something for free.

Got a point, but he is to heavy handed

[SmallFurryCreature]

I know how to find one bad programmer at least. Hire the guy who wrote that article.

Yes he does have a point, but he goes overboard and on several point shows a complete lack of being able to work within the system. No job environment is perfect.

1. List a String of Acronyms for Technologies

This is indeed bad, but you also need to be clear about what you want and the clearest way to list what technologies are needed for the job is to make a list. The list ain't bad, a long unfocused list is bad. If a job doesn't have a short list of what is required then I know they don't have a fucking clue what they are looking for. Only apply if you wish to hold their hand on every decision making process, which will turn out to have a lot of similarity with a random number generator.

2. Put an Arbitrary Number Next to Each Skill

Yup can be pretty bad but how else do you attempt to make it clear you need someone with experience with HTML, not just someone who has seen the acronym once? Personally I would use the experience level you must have for the job rather then years. Because years don't mean anything. I have used databases for 20 years now, but am not a DBA'er (I once talked to a girl after all).

3. Say Nothing Positive About the Position

Yeah, I do notice that. The old "what we offer" seems to have gone missing in action. But on the other hand, am I the only one who hates the boiler-plate "fresh and young company with an informal attitude"? Only put things here if they are relevant and true.

4. Use Euphemisms for the Negative Aspects of the Job

Oh boy. Don't forget the "flexible" one. Means: We are going to screw you every which way but whine like a girl if you ask for a single thing back. Basically, jobs are like girls. Nobody who doesn't have a multiple personality could ever hope to succeed.

5. Require Resume to be in Word doc Format

I like this one, good way to avoid MS shops. ALWAYS look for the desktops being used. All MS? Then run. Fast.

I am actually working on a little site myself that will advise people on how to buy a website. How do you handle the process? How do you determine your true requirements so you don't get hussled? What can you do to avoid becoming the dreaded "scope creep" client and the huge costs that come with it?

What the article/site will mostly focus on is trying to educate customers about the product they are buying and a LOT of companies hiring programmers don't have a clue about programmers or the job they are supposed to do. And this is odd, because if you are going to buy a car, you bring that friend who knows everything about cars. But anything to do with IT and those Luddites from HR can surely handle it. Would you let the guy who doesn't drive handle purchasing the company cars?

So, here is my own list of how to find a GOOD programmer.

1. Determine what it is you need. This is NOT a case of just listing every tech that ever been used in the company. If you need a web-developer it MIGHT sound reasonable to list everything from the server to image manipulation but really, what human can truly be an expert on all of them? Jack-of-all-trades, master of none. Yes, it can be handy for your frontend guru to handle his own images, but should he also know how to handle obscure database crashes? If the job requirement becomes to wide, then you either need to split up the job, use external expert services or maybe accept that what you need is a couple of juniors who are still looking what area to go for rather then a specialist in a certain area.
2. Determine what kind of company you really are. Not every company is young and dynamic. Sure, you are advertising your company but that doesn't mean you have to sell it like Axe. Be realistic unless you want to attract the kind of person who falls for commercials. If you are a MS shop were everything is MS, don't try to sell yourself as an anything goes company, because your new hiree will run when he has to file a request in triplicate to h

Re:Agism rears its ugly head again

[rainmayun]

Wish I had mod points today to mod this one up. Proficiency with a coding language or even frameworks or libraries only matters to a limited extent. Proficiency in triage and identification of issues, skills in enterprise scale design, preemptive anticipation of issues both technical and bureaucratic, understanding how costs affect your project... this is stuff that the vast majority of employees can only gain via experience. Coding at home with a stack of books or bookmarked Internet tutorials simply won't get you there.

Re:Step 1

[Curl E]

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

-- Brian W. Kernighan