http://artisansystem.com/blog/entry/28

Lesson 2: Coding Tests are a Mixed Bag.

During my job hunt I was exposed to many variations of the coding test. Some good. Some bad. While Joel Spolsky would have had me write code during my interview, I was never actually required to do this at any interview.

First, the bad tests. The worst coding tests aren't really coding tests at all. They're trivia questions. Trivia questions that if you ever needed the answer to in real life (the majority of which you would never need) would be a 15 second documentation lookup. These questions should be a major red flag to anyone being interviewed. It means the interviewer cares more about your memorization of arcane facts than about your thought process which might be construed as a disconnect with the real world of day-to-day software development. What's worse is I've actually had interviews where the company standardized a multiple choice test that they give to all their applicants!

"How many SQL queries have you written?"
"Are you serious? It's innumerable."
"So... more than 50?"

This was an actual conversation I had during a phone interview and it's probably the most ridiculous question I've ever been asked. I didn't realize I was supposed to be counting the number of SQL queries I've written in my lifetime. I'd imagine there have been single mornings when I've written more than 50 SQL queries and I'd also imagine that anyone who's ever built anything on top of an RDBMS has written more than 50 queries.

Onto the good tests! And by "tests", I mean "test". Singular. I only had one good one out of the whole lot and I actually really enjoyed taking it. It was simple, open-ended and didn't require tremendous effort (less than an hour) on my part to complete. It consisted of three sections: PHP / MySQL / JavaScript. The three technologies they needed someone to be competent in to work there.

The PHP section was a block of code with a handful of questions about the code. Are there any bugs in this code? What does this code do? Do you see anything wrong with this code? Refactor this code. The instructions stressed that they were more interested in getting your thought process when working through these problems than the answers themselves. The MySQL section was a simple, "we have data for X / design a table structure to accomodate it". And the JavaScript section was almost identical to the PHP section.

This test succeeded on succeeded on a few levels. They got to see my thought process at work and I got to demonstrate my skillset which brings me to the next lesson...

Lesson 3: You want a web portfolio? For a programmer?

I get it. PHP is largely used in the construction of websites so any PHP developer must have a portfolio ready to go, right? Wrong. If I pointed you to any of the websites I've worked on the likelyhood that you'd be judging me on a graphic designer's skillset rather than my own is fairly high.

Hell, most of the work I did at my last job is only exposed in an administrative panel and isn't public facing. Yes, I worked on website X, but unless you're the accounting system the code I wrote interfaces with I doubt you'll get a feel for my work.

Ask for a coding sample instead. I'll be happy to point you to an open source project I've been working on.

Lesson 1: Tech Recruiters are Scumbags.

During my search I dealt with many such tech recruiters. I even followed up with a few which only lead to disappointment and frustration.

The main problem with tech recruiters is that they honestly do not care about your situation, just their bottom line. And their bottom line is the direct result of placing someone (anyone really) in a given position. No matter what flowery language a tech recruiter throws at you (and they will), they're still just looking to fill a slot for the highest amount they can.

Technical recruiters are also widely non-technical people with horrendous judgment of technical ability. So they use metrics like the “number of buzzwords in your resume”. Number of “years working experience” is another metric recruiters seem to love equating with ability. I've been hacking on the LAMP stack for roughly four or five years now, have worked on a wide variety of projects, and consider myself to be a skilled programmer, but because I haven't attached a company name to the majority of those years it's all for naught in a recruiter's eyes. Yet, so often, these are the gatekeepers to our industry.

Another common theme I've found in dealing with tech recruiters is that when you don't get hired, they tend to just dismiss you entirely no matter how many “other opportunities they have for you if this one doesn't work out.” The truth is you'll likely start being forwarded straight to their voice mail and your emails will be with silence or the occasional out-of-office message. A friend and former co-worker of mine has related similar cold shoulder stories even going so far as to call using a different name to prove a recruiter was just dodging his calls.

In short, tech recruiters are non-technical dolts who use bad metrics to squeeze the highest dollar out of the companies they're contracted to while alienating otherwise prospective talent. I'm not sure what the value is that they're adding to the hiring process. Is it really worth $10,000 to not sift through resumes?

If you're looking to hire, I'd beg you not to use a recruiting firm to do it. The message it sends to potential employees is that you don't care about the hiring process.

Jason Kotkke recently wrote a post about applying the theory to the online world.

“The appearance of one troll encourages others. Undeleted hateful or ad hominem comments are an indication that that sort of thing is allowable behavior and encourages more of the same. Those commenters who are normally respectable participants are emboldened by the uptick in bad behavior and misbehave themselves.”

And from my experience this generally holds to be true. But what if we apply the theory to software development?

At my last gig, we built and maintained custom osCommerce (OSC) applications for our clients and for those of you that don't know, osCommerce is widely used open source shopping cart software and a complete mess. If you've ever worked on an osCommerce project then you know the abject terror that resides in its source code.

In my early naivety working with osCommerce I would try to fix the broken windows and refactor some code while making my modifications. This quickly lead to frustration and hours wasted working on an insurmountable task.

At the end of the day, the legacy OSC code beats you down. It's simply unmaintainable code. You try your best to squeeze your new features into it without disturbing its ancient voodoo. In doing so you end up writing code you're not proud of.

You break more windows. You can't repair the broken ones. At least, not without demolishing the entire building first.

If anything the “Broken Windows” theory holds especially true when applied to software development. Does your code read like it was written by someone who genuinely cared? Or is it an invitation to neglect?