The Codist

Dealing with recruiters from both sides of the aisle, you hear a lot of requirements for people with experience. But what is experience? How do you evaluate it?

When I talk with recruiters or sourcers about jobs on the phone or by email they either ask about experience or provide a laundry list of things the customer "needs". Often they appear as a set of technologies and a required number of years "experience". Sometimes they offer a set of these and expect you to fill the a number of years of experience with each. The hope (from the customer perspective) is that this magical collection of experience points will divide "the people we want to talk to further from the worthless scum of humanity".

The expectation is that the number of years of experience in some technology somehow translates into ability, intelligence, and instant productivity. Furthermore a lack of years of experience in some technology is a sure sign of a slacker, a moron, and someone not to be hired. Thus the more technologies that can be demanded from the candidates, along with a requisite large dose of experience in each, will guarantee that a brilliant engineer will leap to the front of the herd, rescue the company's lame IT group, lead everyone into the promised land of IPO richness.

The reality is that listing experience requirements is generally useless as everyone has to lie.

If you ask me how many years experience I have in Java, it's a continuous thing; I can readily say 9 years. If you ask me how many years experience I have in EJB's I can say, eh, not sure. For any technology you use only occasionally (maybe on certain projects) the how many years experience is at best an approximation.

For example, say you ask me "how many years experience do you have eating lobsters?" how do I answer? If I ate one 10 years ago and ate one yesterday, is it two days, two years, ten years? What if I ate them once a month or once a week? How do you measure this? The natural intention is to round up to the nearest year if you are asked in years. What if they want to know in years and months, then what?

Of course the nature of the experience is what really matters, but you can't measure quality with a quantity. If I spent three months writing an app 5 years ago and wrote a whole mess of EJBs, tuned the appserver performance for them, and generally made architecture level decisions, and you spent 5 years writing an app but only called preexisting EJBs (for example Websphere Commerce Server). Who has the better experience? Clearly I do but with only 3 months (1 year) experience I won't even get an interview.

Thus I would have to lie and say "5 years" and thus the customer hasn't really learned anything from the quest for experience. So why ask?

I also find it amusing when people put out the long laundry list of technologies, many of which are marked "required". Often these are written by some HR person or recruiter to whom the names and acronyms may as well be in Chinese, and the number of years required are essentially random. You also get overlaps, as in asking for J2EE and JSPs, which is like asking do you eat shellfish and lobsters? I get the feeling that people look around their company, collect all the technologies they have ever used, stick them into a job ad and expect someone out there would actually know all of them.

I once volunteered to be a Documentum architect and developer at a company I already worked at. I took a few classes and then built a number of applications; it wasn't terribly difficult. After I left the company, every recruiter in the area kept sending me the job ad for my replacement (as they couldn't find anyone); the ad listed all sorts of complex requirements and experiences that were required, none of which I had when I started. The reality of a job is never what's in the ad.

The most important experience is actually in learning new things easily. This industry changes all the time, and hiring people based on some exact laundry list of experience (which is usually lied about) is rather pointless. If you ask for 15 technologies and I know 14 of them, why would I not be a candidate (assuming I'm telling the truth). If I have X years experience overall as a programmer, and have a long list of technologies used (assuming of course I'm not making it up) why wouldn't I be able to learn the few you have that I don't know already? How about asking how I learn something new, or even describe my experience with actually using something?

Thus the quest for experience in job ads is basically pointless, since most will lie, and only the honest tell the truth. Everyone is likely to have experience on paper (Widget Congruence Framework, sure, 5 years) and you have to interview everyone anyway.

So the next time someone asks if you how many years experience you have with EJBs, ask them about lobsters. Who knows, maybe they will buy you one!