The Codypo Test, aka 8 Questions To Identify A Lame Programming Job

| 22 Comments | No TrackBacks
We all know and love the Joel Test, Joel Spolsky's quick quiz to determine the quality of a software team.  If you're searching for a job, it's a great idea to run potential employers through the Joel Test.

There's a problem with it, though.  Well, there are multiple problems.  First, who the hell cares about hallway usability testing?  Second, you're only checking for the good qualities of a team.  What about the horrendously bad qualities that will eventually drive you towards both insanity and a crippling dependency on cough syrup?  
We need something like the Joel Test to measure the potential crappiness of a job, or else each of us might stumble into becoming Milton Waddams.

Ladies and gentlemen, I present to you the Codypo Test, aka 8 Questions To Identify A Lame Programming Job.  If you are in an interview, you give the company the Codypo test, and the job scores more than a 1 or 2, you need to pull the fire alarm and get the hell out of there.

1.  Would I be paid below market rates?

If they're looking for 10 years of hardcore, multithreaded C++ experience and they're offering 48k, these people have lost their minds.  Expect this sort of delusional thinking to appear in everything they do.

2.  Would I always be on call?

No one likes being on call, because as soon as you're on call, someone is going to page you at 3 AM on a Sunday because the Reset button on the support portal is a different shade of blue than they're expecting.  Occasional on call stints are both understandable and tolerable, but 24/7 is for doctors and exorcists.

3.  Am I the IT staff?

You are a programmer.  You make software.  You are happy to support your software.  
This does not, however, mean you are a computational master of the universe, and just the guy to ask why the receptionist's laptop got all weird after she installed that Garfield screensaver.

4.  Would I work with a single monitor?

It's no longer 1998.  We don't have to stare at a single 17" boat anchor all day while rocking out to Smashmouth. You can buy huge, thin LCDs for $100 each.  If doubling your productivity isn't worth $200 to this company, then this company may just be a really elaborate practical joke played by an eccentric billionaire.

5.  Will I be maintaining any ancient system, and what's it written in?

If you dig deep, you may hear, "Yeah, we're going to get into Ruby on Rails, but first, we'll need you to bust out some VB 4."  It is never, ever that easy.  
That VB 4 system will refuse to die, just like Rasputin.

6.  Would my internet usage filtered or monitored?

Programmers solve problems, and to solve problems effectively, you need resources.  The internet is the single greatest usage available.  Any company that refuses to accept that and blocks you from Usenet/ Google/Stack Overflow/whatever is treating like you a child/deranged porn fiend.

7.  Would I be the only programmer?

More than anything else, I have grown as a programmer thanks to my peers.  We answer each others' questions, we review each others' code, we whiteboard together, and we come up with creative insults when somebody breaks the build.  If it's just you, you're not going to get any technical feedback and you're not going to get any better.  Also, you'll only be able to insult yourself when you break the build, which might get you reported to HR.

8.  Am I expected to travel every week?

A bit of travel is necessary from time to time, particularly for face to face meetings with customers or offsite colleagues.  However, expecting you to leave your home every farging week is absurd.  We have the internet now; it allows us to communicate virtually.  Let's use that instead of me becoming BFF with the night receptionist at the Best Western.

I think those 8 questions constitute a good sanity test for a potential job.  Sure, there are valid reasons for a job to score a 1 (eg, you might be the IT Staff or on call all the time at a startup).  However, once you get past one Yes to these questions, it's time to leave the interview through any means necessary, including faking a heart attack.

No matter how great the potential projects and teammates might be, I don't think you can do truly meaningful work in an environment where you, the developer, aren't empowered to succeed.  If a company doesn't get that, then they don't get software.

No TrackBacks

TrackBack URL:


Interesting stuff - I'll have to keep that in mind from the recruiter's perspective! :)

Interesting list, these are very prudent questions that need answering before you accept a job offer.

My job scored a 1.5 so I guess I better get back to work :P

Here are a few more

-What Source Control do you use ? (Perforce/ClearCase == Step away from the phone)

-What machines do the programmers use ? (Mac get high points)

-How often do you release ?

-Do you have an internal wiki ?

-How do you track bugs ?

What is the hell wrong with perforce? Google/EA use perforce

My first question would be: is my would be superior a) computer savvy and b) a decent programmer.

If A or B is false, stay the f*ck away.

Ask about a training/conference budget. If they won't spend on training or even let you buy a single book with company money that's a big red flare.

Perforce or SVN might make sense for large legacy code bases that would be difficult to move, but these days I think Git, Mercurial or Bazaar are so far ahead that there are very few reasons not to choose one of those three.

A corporate GitHub account would be enough to convince me that the company is a great place to work.

I scored a 6!

Well, my job pretty much sucks !! Mainly because my boss has no appreciation for new thought ! Wait, i guess he is reading this as i type !!

Perforce is a warm summer breeze compared to the deranged monstrosity that must not be named (Clearcase).

6 out of 8 myself ... time to go out looking for a new job. Thanks for the info, Cody.

- How do you build code?

(I know a big company with a big product that cannot do a fucking local build. Also, look for pitfalls in the build procedure - if there is a lot of code-generation you are going to be screwed.)

My suggested addition to the list would be:

The fewer previous jobs that your peers have had, the worse the workplace

> -What machines do the programmers use ? (Mac get high points)

I think the correct answer here is: "Just let us know what you need to do your job.".

I'm stuck on a Mac right now and would be more productive on a GNU/Linux system.

Another one: Will you have Admin rights on your machine?
This is my major complaint at my job :(

More Q's:

- Does any member of management currently suffer from Aspergers Syndrome ( I kid you not, CEO of last two companies did. It's like working for Captain Bligh (zero emotions).
- How many modules in the repository have circular dependancies? I kid you not, I'm working on one project that is dependent in 6 other modules, none of which can be compiled on their own!! Must have developed organically.
- Can I meet with the engineering staff? I should have pushed for this more in the most recent job. Would have been able to ask each of them the above questions and get more honest and truthful answers.


This is an great site, I will be sure to add your blog to my blogroll :)

- Do they have deadlines every other week?

- Do they ask you to work through weekends and Holidays 'because the customer really needs this" (i.e. some sales jerk wanted to look cool, and he'll probably get the bonus and the hurrays).

- Do they have decent UI people that make designs and deliver the artifacts you need to be able to work efficiently (or is it all up the programmer again)?

- Are new technologies tested with proof of concepts (of the throw-away kind) before they are adopted?

- Will you have an operations team (of at least one admin kinda guy)?

- How long on average do people spend their time in meetings?

This reminds me of something my old geography teacher - Mr Marshall - used to say on those Thursday afternoons

About the Author

The Art of Delightful Software is written by Cody Powell. I'm currently Director of Engineering at TUNE here in Seattle. Before that, I worked on Amazon Video. Before that, I was CTO at Famigo, a venture-funded startup that helped families find and manage mobile content.

Twitter: @codypo
Github: codypo
LinkedIn: codypo's profile
Email: firstname + firstname lastname dot com