I <3 Steve McConnell*
Coding Horror
programming and human factors
by Jeff Atwood

February 07, 2008

The Years of Experience Myth

I recently received an email from Andrew Stuart of the Australian firm Flat Rate Recruitment. Andrew related their technical phone screen process, which is apparently quite similar to the one outlined in Getting the Interview Phone Screen Right. I'm glad to hear it works. A proper phone screen is critical. I completely agree with Andrew: you should be 95% certain that a candidate would be a great hire before they ever set foot in an interview room. Anything less is a colossal waste of everyone's time.

But there's one aspect of the recruiting process that often goes awry, even with a great phone screen in place. Andrew presented an excellent anecdote in his email that explains it better than I can:

I had a client building an advanced security application. I sent them person after person and they kept knocking them back. The reason was almost always because the person "didn't have enough low level coding experience." The people I sent had done things like design and develop operating systems, advanced memory managers and other highly sophisticated applications. But my client wasn't interested. They required previous hands on low level coding experience in a particular discipline. Eventually I got an application from a very bright software engineer who almost single-handedly wrote a classic computer emulator, but had little or no low level coding experience in the particular discipline they required.

I told the client, "I have a great guy here who has no experience doing low level coding and I think you should hire him." They were extremely skeptical. I pushed hard to get an interview. "Look, this guy is a superb software engineer who doesn't have low level coding experience in the particular discipline you require now, but if you employ him, within 3-6 months you will have a superb software engineer who does have the low level coding experience you're looking for."

They interviewed him and gave him the job. Within a matter of weeks it was clear he was the smartest programmer in the company. He quickly mastered their low level coding and his learning went well beyond that of the other coders in the company. Every time I talk to that client he raves on about this employee, who is now the technical backbone of the company. That company no longer focuses its recruitment on candidates that exactly match previous experience with the required technologies. Instead they focus on finding and employing the smartest and most passionate engineers.

This toxic, counterproductive years of experience myth has permeated the software industry for as long as I can remember. Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match-- exactly and to the letter-- some highly specific laundry list of skills.

Somehow, they've forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with.

It's been shown time and time again that there is no correlation between years of experience and skill in programming. After about six to twelve months working in any particular technology stack, you either get it or you don't. No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing. This is why working programmers quickly learn to view their peers with a degree of world-weary skepticism. Perhaps it's the only rational response when the disconnect between experience and skill is so pervasive in the field of software engineering.

With that in mind, do you really want to work for a company that still doggedly pursues the years of experience myth in their hiring practices? Unlikely.

Which leads me to my point: Requiring X years of experience on platform Y in your job posting is, well, ignorant. As long as applicants have 6 months to a year of experience, consider it a moot point for comparison. Focus on other things instead that'll make much more of a difference. Platform experience is merely a baseline, not a differentiator of real importance.

In turn that means you as an applicant can use requirements like "3-5 years doing this technology" as a gauge of how clued-in the company hiring is. The higher their requirements for years of service in a given technology, the more likely that they're looking for all the wrong things in their applicants, and thus likely that the rest of the team will be stooges picked for the wrong reasons.

I'm not saying experience doesn't matter in software development. It does. But consider the entire range of a developer's experience, and realize that time invested does not automatically equal skill. Otherwise, you may be rejecting superb software engineers simply because they lack "(n) years of experience" in your narrow little technological niche-- and that's a damn shame.

[advertisement] Data Dynamics Reports: An easy-to-use reporting platform for .NET developers. Master Reports, Data Visualizers, Dashboard controls and more!

Posted by Jeff Atwood    View blog reactions

 

« Extending Your Wireless Network With Better Antennas Where the Heck is My Focus? »

 

Comments

I agree entirely, I recently found out, I got my last job because I managed to get into a recruitment site by faking the GoogleBot UserAgent, because I was not part of the site, my employer found this to be a nice trait and employed me. He only told me this, a year after working for him, I thought it was for my good looks!

Sarkie on February 8, 2008 03:17 AM

excellent article! And it gives me some hope. I'm just about to begin my final year of my degree and I was (a little) worried that it'd be hard to find a half decent job.

I'm not expecting to jump into the deep end or anything, but it's inspiring to hear that not EVERYONE looks for experience. I like to think I'm a little ahead of the pack (and by no way am I at the lead) because of the way I tackle a problem - and the way I learn the required technologies.

One year to go - and there's some light at the end of the tunnel.

`Josh on February 8, 2008 03:18 AM

I cannot agree more. The rule "you either get it or don't" should be one of the Ten Commandments of programming.

Björn on February 8, 2008 03:23 AM

The most extreme example of this is when companies ask for more years experience than a technology has existed for - for example 10 years .NET and C# experience.

JosephCooney on February 8, 2008 03:32 AM

This reminds me of an advert for a Java position I saw back in 1999. They asked for 5 years experience - even though Java was only released 4 years earlier.

I guess they were hoping James Gosling would apply.

Steve McLeod on February 8, 2008 03:45 AM

Its like when you got a new client and a new big project. What if all our clients would require that we had 3 years experience of their internal structure, programs and tools? We would be out of work in no time.

Our customers expect us to quick pick up what they want to be done, understand the whole concept, implement our own knowledge over their needs and come out with a great plan to make it happen.

We do it every time, thats our job. Quick learning and understanding the customers need.

So that is what is important to look for when hiring.

Stefan on February 8, 2008 03:45 AM

And, from a developer perspective, how fast is your cluefulness rising?
http://www.ericsink.com/Career_Calculus.html

Jivlain on February 8, 2008 03:49 AM

Aptitude, desire to learn, and ego in check are what you should be looking for. Sometimes it's those who have the most experience in one stack who are the least flexible, as they tend to view things through their "year of experience" filter.

ActiveEngineSensei on February 8, 2008 03:58 AM

In my previous job I turned down more developers who had experience in the technology stack we were using than I hired. My aim was simple, hire highly competent developers who showed that spark and aptitude for development.

The result was a very competent and highly motivated technical team.

Only once did I let my standards drop due to pressures from higher management that "we need more resources right now", in that instance he lasted 2 weeks before handing his notice in.

Dave Spurr on February 8, 2008 04:04 AM

I agree, what software programmers do best is learn. I've fixed code in languages I didn't even understand. Not that I recommend it.

Once you know 2 or 3 languages, you can blow through a new language in no time. It's the programming techniques that matter. Unfamiliarity with a language might slow you down, but not as much as bad technique. And it's easier for a good programmer to learn a new language than someone who is familiar with a language to learn how to be a good programmer. Way WAY easier.

And I love the job listings like:
Required - 10+ years experience in administrating Windows 2k/2k3 networks

adamdrayer on February 8, 2008 04:18 AM

Good post Jeff. Couldn't agree with you more.

Here in Sweden it's been like that for quite a while; companies seeking years of experience with this and that. Seems like 2007 was the turning point though. All of a sudden, the software industry realized that they actually needed to hire again.

Linus on February 8, 2008 04:28 AM

I might be wrong but in the UK you can no longer ask for x amount of years any more as it is seen as discriminating.

Anon on February 8, 2008 04:41 AM

Whilst I mostly agree, worth noting that there are some areas where experience is relevant.

I'm recruiting heavily for my team, to do web based application development. This boils down to data in and out of a database with occasional re-shaping and a load of business rules validation. So it's not /hard/ stuff.

I've rejected great candidates with years writing Sound Card Device Drivers because they have /never/ worked on end-user software. This is for candidates coming in at a senior level in the team. They need to know about HCI to work on the product, they need to know about web development.

But I don't care if it's in Java, Microsoft things or PHP. But they need to understand how to specify, design and develop software based on people. Something they /can/ learn, but, not as quickly as just switching from ANSI C with Assembler to C#.NET. ANd to take a senior role in the team, they have to have those other skills already.

THEMike on February 8, 2008 04:45 AM

>I might be wrong but in the UK you can no longer ask for x amount of years any more as it is seen as discriminating.

I've been told this is true by recruitment agencies. We can't ask for x years of experience as it discriminates against people starting out. We can't even ask for graduates as that discriminates against the under 21s.

So what do you do if you need someone with proven experience doing something you can't say a simple academic qualification covers? And, we can't even require a degree in the stuff either! So technically, a 16 year old with no GCSEs can't be screened out by our advertising...

It's very hard to be able to legally advertise for required attributes of employees! We require a certain amount of history as a permanent UK resident for MOD Security Clearance. But we can't advertise a need for that residency, can't hire them because they can't be cleared, can't do the job without clearance.

THEMike on February 8, 2008 04:49 AM

Well done Jeff ! Passion drives everything.

This article is for you Mr. T !!! :)

Too often, big companies are blinded by years of experience of a candidate without looking at their real potential.
But fortunately, between you and me Jeff, it's easy to recognize someone who is passionate about his work, right ? I doubt that this passionate behavior can be "faked" by candidate : you can tell if someone is passionate by the way they talk and even their body language. This is my 2 cents.

Keep up the excellent work Jeff !

Phil

Phil on February 8, 2008 04:58 AM

>I might be wrong but in the UK you can no longer ask for x amount of years any more as it is seen as discriminating.

That is true - in fact I blogged about it recently. And whilst Jeff's argument may hold for coders, it's a bit murkier when you are trying to hire team leads and other senior roles, many of which in my opinion DO need some experience in the field before being really effective. I wouldn't want someone fresh out of college with no commercial projects under his belt running a multi-million dollar project.

http://basildoncoder.com/blog/2008/02/02/descent-into-incompetence/

Russ on February 8, 2008 05:06 AM

A very wise boss of mine told me 15 year ago to hire on "bandwidth" not skills. We did alot of controls work - a high bandwidth controller could handle a variety of inputs: you get the analogy by now. I've used that philosophy ever since and it's NEVER failed me. Of course it's not the only criteria: personality is big. Does the individual's personality fit the organizations? Can they get along, work as part of the team?

I've hired 20-30 people on the last 15 years, on these criteria alone (and gotten hired by others using them twice). NOT ONCE has it gone wrong. I've watched skills hires go wrong constantly.

Every hire is an investment - Make sure you're investing for the long haul, not just this quarter.

Marc on February 8, 2008 05:06 AM

Hey Now Jeff,
I like these posts recently regarding screening resumes such as the phone interview & N years of experience. As always I've learned quite a bit. The entire range of a devs experience is important like you stated.
Coding Horror Fan,
Catto

Catto on February 8, 2008 05:19 AM

Folks:

I have to agree on the years of experience thing. However, it brings up a tangential thought: what do you folks think about job posting copy? Do you not mention technologies and years of experience?

Danimal on February 8, 2008 05:40 AM

Of course, it depends entirely on your requirements. Imran had a post about this recently:

http://tickletux.wordpress.com/2007/12/06/recruitment-and-the-mythical-year-of-experience/

I think the point is that when you ask for years experience it should be seen to indicate a certain ability level amongst the general developer population. i.e. if you want a junior programmer who perhaps doesn't know many languages/to a great depth then maybe 1 year is appropriate. If you want a language specialist then 10 years might be appropriate. The real key thing is to not filter out applicants only because they don't have the exact number of years. A good developer with 2 years experience might be as good/knowledgeable as an average developer with 10 years. If you don't apply any baseline ability filter then surely you spend your days going through thousands of CVs.

jon on February 8, 2008 06:00 AM

This comes from trying to treat people like computers.

If (Resume A matches Job Requirements B) Accept(); Else Reject();

Stephen on February 8, 2008 06:04 AM

...I'd go a bit further with this: any position which HAS a "laundry list" of qualifications is probably being handled by an H/R manager, not a tech guy - the tech guy wrote the laundry list probably as a guide to the H/R weasel, but the H/R weasel takes it too literally (not knowing any better).
This is a sure sign of a company which has a serious disconnect between internal needs and external people - avoid this and you'll be better off!

SiGiD on February 8, 2008 06:10 AM

I remember a few years back i was looking for a new job, and saw many job postings for .Net that wanted 5+ years experience. At that time .Net had been around for 3 tops. I had between 6 months and a year experience w/.Net, and ~3 years experience total. I still sent them my resume, but typically never heard back. cest le vie.

I think the issue is that some HR types don't really get it when it comes to the software industry, and try to force us into their mold. I know I've had a problem where we were getting crap applications, so I looked at our postings, taken it back to my bosses for a wtf discussion. They looked at the posting and said that's not what they were wanting, no wonder the applicants didn't match what we were looking for. It gets even worse when HR filters the resumes for you :(

mjmcinto on February 8, 2008 06:13 AM

Regarding Job Adverts in the UK, yes you can't advertise for age,sex ,race, nationality or religion, and this includes unobvious filters like x+ years of experience, Degree in... Etc. that require a certain age because a school leaver could not have done it yet.

But you can put in the advert MOD Security Clearance is required since that is a requirement and anyone can theoretically get clearance?

Jaster on February 8, 2008 06:19 AM

I have to include a comment for those of us who have been stay-at-home moms.

While staying at home for 5-years, I kept my resume filled with "part-time" computer training at the local school, and learning web site design (take a peek) I still "get it".

These weren't in my field of software engineering but showed I knew how to adapt. Now I'm two years back into the field a job I love again in...software engineering thanks to a guy who "took a chance on me", after all I didn't have direct experience in the field lately.

This week, I just got our second USB port (via a USB to SPI port into the uC) to communicate this week with our product! I never had any direct experience in that! (I guess breast feeding didn't drain the brain after all).

Coding Horror Fan

SheRa on February 8, 2008 06:33 AM

I find the exact opposite to be true when it comes to IT system/network administration. Too many companies are stuck in the, 'How many certs does this candidate have?' game. Experience doesn't seem to count. So you wind up playing the game to get your foot in the door, but then you get to work with a bunch of mindless morons that 'learn quickly' and take tests well. Because the rest of your company doesn't understand IT, they all assume your team knows what it's doing. You end running herd on everyone else to keep the entire team from getting fired. Of course, you don't get extra credit for this, as everyone else on your team takes credit for all your work and knowlege.

yo'momma on February 8, 2008 06:39 AM

Joel Spolsky's been saying this for a while: smart and gets things done.

John Ferguson on February 8, 2008 06:42 AM

This is a refreshing post, when I look at posting on Monster I see all of this nonsense. They ask for every acronym on the planet. Even when I look at the postings for my own job I honestly don't recognize most of the "technologies". My favorites though are when companies list their propriety technology/system/whatever as a requirement.

So, I do agree with your point. However, I do imagine that its difficult to find people based on this ambiguous qualities.

Matt on February 8, 2008 06:44 AM

This is particularly frustrating for those of us who would like a new job or would like to work on a different project. Unfortunately, people want to pigeonhole you into a particular technology/language/skillset. It drives me bonkers that I might have to continue to rehash most of the same skills in every project. It gets to the point at times where I volunteer or do some part-time paid work just to be exposed to radically different technologies than those at work.

Doug on February 8, 2008 06:49 AM

I've interviewed a lot of tech people over the years and haven't gone wrong with this maxim very often:

10 Years of Experience in [technology]

is more often than not:

The same 1 Year of Experience in [technology] 10 times over.

Holds true whether you're a software developer, systems administrator, or a sanitation engineer. Experience means very, very little here.

Me? I've got 20 years in this industry. Maybe only a few of them I'd consider "repeats". Otherwise, every year I've learned something new, mastered a new technology, or did something completely different. When I say I've got 20 years, I mean it. I have a *lot* on my resume, and everything on there I'm prepared to give a 30 minute in-depth lecture on.

I wish my candidates could.

* If you put down TCP/IP on a resume, you'd sure the hell had better know how to describe a 3-way handshake and discuss -- in depth -- some techniques to avoid a SYN flood.
* Saying you understand SQL is the best way of getting me to ask you to design a table to describe a hierarchical structure or give a talk on concurrency.
* Woe if you put down something as generic as "Unix". Really? Unix? Tell me about the structure of an i-node, how fork() works, or how making system calls affect scheduling on the architecture of your choice.
* Oh? You really meant "NFS, but it's been a while." Fine. Then let's discuss file-locking strategies under NFS version 2 or 3, your choice.
* Both Java and C#? I love exception handling. Which method do you prefer, when and why? Your response had better indicate that you /really/ understand them, and that you've wrestled with both of them. Hate one or the other, love them both, you'd better have an opinion.

I don't care about language syntax (you can always look that up) or the classes you've taken (for $300 I can buy a bachelor's degree, meh). Demonstrate some understanding.

Clinton Pierce on February 8, 2008 06:50 AM

US recruiters are bad about this. If they don't know what checkbox to check to send you off to their client who has a project in technology X, they don't know how to evaluate you, because, of course, they don't actually know anything about IT at all, other than acronymns.

What makes it worse is the huge percentage of job postings by recruitment agencies. I know there are many jobs interviews I would do well in and jobs where I would learn the required technologies once I work with them, but without the recruiters being able to check the checkbox, I'll never get to the interview in the first place.

Dennis on February 8, 2008 06:58 AM

I suck at interview...

TheTodd on February 8, 2008 07:02 AM

The right way is commonly referred to as the "best athlete" recruiting approach.

John Pirie on February 8, 2008 07:05 AM

Ask a basketball coach, and he'll tell you, "You can't teach tall."

Joe Chung on February 8, 2008 07:11 AM

"Sometimes, it's the person's capacity/willingness to learn that's more important than the things they already know."

That was my original response to your phone interview post. It's good to see that you've added to your original point of view. Looking solely at an applicant's experience is a very narrow, one-dimensional position. As you point out, if that's the case I don't want to work in that organization anyway. Programming is very multi-dimensional. The programming interview process should reflect that.

Kenneth on February 8, 2008 07:15 AM

these have been some great posts. good insight into HR, etc.

can we get some programming posts? :-) it's been a while.

paul on February 8, 2008 07:15 AM

Why ask for 10 years experience? In short, you ask for 8 years of old knowledge, only the 2 latest are fresh knowledge on new techniques.

But on the other hand, experience is important in many cases, with much experience you have already done your share of errors and hopefully learned a lot by doing them and you have a large bag of useful tricks that can be a big benefit and time saver in a project.

So combine seniors and juniors in the project to have a perfect mix of experience and drive can be a good practice.

Stefan on February 8, 2008 07:25 AM

>But you can put in the advert MOD Security Clearance is required since that is a requirement and anyone can theoretically get clearance?

You wouldn't want to /require/ MOD Security Clearance as hardly anyone has it, and people can't get it themselves (has to be appropriately sponsored). But, you can't put no criminal record, nor can you put must have 5 years uk residency, to screen out people who aren't going to pass the vetting.

THEMike on February 8, 2008 07:35 AM

Loved this post. Hated your phone interview post!!!!

Roberto on February 8, 2008 07:37 AM

I couldn't agree more. I often laugh at job postings that say things like "8-10 years of .NET experience required."
I remember seeing one job posting "requiring" 5 years .NET experience in 2004.

How can they expect you to have experience in a technology from several years before its release?

Dave on February 8, 2008 07:47 AM

I totally agree. Maybe software engineering is an art and us developers are artists (http://www.code-muse.com/blog/?p=20)... However, whatever metaphor you want to use for developing software (be it engineering, art, or rock climbing), the most simple way to put it is that it requires hard work. In the sense, that most of the time programming is a tough job requiring a fair amount of using your brain, and with a lot of passion, your mind is at its best.

Gertjan on February 8, 2008 07:56 AM

You know, I have to say, part of this is up to the interviewee as well. Simply saying "I don't know" when asked a question about a technology you aren't familiar with is a great way to sink yourself. If a developer is looking for a particular tech that you don't know, my strategy has always been to be up front, and say "I don't know it off hand, but I can buy a book and learn it fairly quick."

This happened to me during an interview for Relic. They wanted STL experience, but I told them straight up, I'm not directly familiar with the STL, but I can buy a book and learn it without significantly hindering my ability.

Not only did the interviews continue, but they eventually made me an offer (which, ironically, I refused).

But if you can reach a point where you are talking with a live person, if you know you can do the job, then there's no reason you shouldn't be able to talk yourself in to it.

Charles on February 8, 2008 07:57 AM

Some people work for 5 years and gain 5 years of experience. Some people work for the same 5 years and gain 1 year of experience 5 times.

DysgraphicProgrammer on February 8, 2008 08:17 AM

Re: MOD clearance
You can't even ask someone if they have it since having it is classified! You have to say "Work of a confidentail nature in the national interest". But you would only know that if you had been told when you got it .....
You also used to have to be a British citizen AND your parents had to be British citizens. The job ads would say this and then underneath have the usual, 'The MOD is an equal opportunity employe'

You CAN ask for years of experience - the discrimination thing is just moronic HR ass-covering and Daily Mail 'Political corectness gone mad' stories. Asking for 10years experience for a senior post is NOT the same as saying 'under 50s only' on a job ad.

m on February 8, 2008 08:18 AM

MSFT hiring mantra is "Hire for the company, not the job."

mike on February 8, 2008 08:18 AM

Jeff,

We all seem to be in agreement here (I also hire based on smarts and personality rather than specific experience), but I don't think it's that simple, for three reasons:

1. Different areas frequently require different modes of thinking, and that mental shift may take longer than six months. For example, most of the rules of thumb that people use for GUI programming are close to worthless for embedded programming.

2. I've met people for whom I think they have forgotten more about a certain area of expertise than I will learn in a lifetime. I'm fairly sure I'll never be as good a server programmer as Chris Brumme, or as good database guy as the late Jim Gray.

3. The areas where guys like us can hit the ground running are those areas which are not very deep. If I show you an application I expect you should be able to deconstruct it in your mind and understand how it works. But what about domains like crypto or image, video and sound recognition? We'd be bloody clueless.

Dejan

Dejan Jelovic on February 8, 2008 08:28 AM

And i'd think, that is a singular german problem, Unfortunately it is a global Problem

VolkerD on February 8, 2008 08:42 AM

Agreed - especially for programming. Managers and business analysts, though, I would agree need experience dealing with clients, employees, and company politics.

Because it is the managers doing the hiring they think that the rule applies for everyone.

Desire always is better than experience.

Burke on February 8, 2008 08:42 AM

There are some kinds of experience that is helpful, regardless of how great the developer.

I've learned far more from failures than I do from successes. Success may or may not be repeatable, but learning from failure means you won't make those mistakes again.

For example, most typical junior level developers don't understand the risks involved with rewriting code. Sometimes those risks are worth the reward, but often they are not... leading to extended testing and validation cycles that wouldn't be necessary if you had left some older, and perhaps less elegant code intact.

Years of experience with a given technology is far less useful than years of experience overall.

Nobody Real on February 8, 2008 08:47 AM

As long as nontechnical managers have any say in running tech companies, this problem is going to continue (Think "HP-Compaq with Fiona"). As long as hiring is in the realm of those HR geniuses, this problem is going to continue. Neither group has a clue as to how to hire, fire or manage competent technical people.

ThatGuyInTheBack on February 8, 2008 08:51 AM

So, it sounds like, the entire gist here is simply "hire really smart and passionate" people.

Sounds like good advice for any intellectual job whatsoever.

What if they never coded at all (and are super smart)? I mean being able to code even a little is already "experience". Plenty of smart kids go from zero to making good programs in just a few months.

Vet on February 8, 2008 08:51 AM

Jeff, thanks for these awesome posts!

JF on February 8, 2008 08:57 AM

I agree. I hate the “grocery list” of skills people list for job postings. Sometimes the list will have so many “required” skills listed, that no one will meet the requirements.

chaosgone on February 8, 2008 09:06 AM

As a developer who's also trying to hire, I've found that there is a sweet spot number of years that tells you he's serious about the profession as well as not too inured in a particular methodology so that he can adapt to a new challenge/environment/project.

And if you're reading this post because you're looking for a new challenge as a developer, please feel free to contact me andy (at) whereandy (dot) com.

Andy on February 8, 2008 09:08 AM

The one caveat I would make is that if someone has, say C/C++ experience and you're hiring them for a .NET/Java job, I want someone who will be humble enough to know that they are in a new environment, and they have things to learn. Else they'll waste days re-implementing DateTime or something.

Smart is good, "know-it-all" is bad.

Rich on February 8, 2008 09:10 AM

This almost seems like a worthwhile blog, but I'm afraid I only read bloggers with five or more years of experience so that I can be sure I'm getting the best advice.

Jacob on February 8, 2008 09:34 AM

Yes Jeff, you are right there is specific experience and there is generic experience. I believe that having 2 - 3 yrs under me after leaving school and working full time I can tackle just about any issue thrown at me. However that being said my experience in design and the best practices is still growing. Sure I am reading and studying books from all the greats and reading great blogs. However I am still no where near the level of some of my colleagues who have been doing this for 10 + years. So I do believe that while specific experience isn't all that important general experience is, because I am not ready to lead a huge software project yet or tackle some hugely complex issue. However in another 7 years I'll be 30 or so and probably will have had the experience and the learning opportunities to provide me with that experience. So I am experienced I've got a long way to go I believe.

Cheers

Chris Howell on February 8, 2008 09:35 AM


Please, Please, Please, all readers there, forward a link to this excellent entry to your HR and hiring departments!

As an independent consultant for the past 10+ years, I find it amazing how many companies still run the years experience check-list.

You have it right, Jeff -- I don't waste my time with these companies. I would much rather work for a company willing to listen to how I have applied my programming skill to develop real-world applications or solve complex problems. Not only that, it is much more rewarding to work for the companies who DO get it that software development is a constant learning process.

The ability to pick up a new technology is obvious if you read any good developer's resume.

Lonewolf on February 8, 2008 09:36 AM

I agree, but I have to live in the real world. I used to focus on learning more of the kinds of things that apply to programming in general rather than the specifics of my stack. Now I realize that it would've been much more valuable for my career to just focus on the stack.
I'm not now (don't even have a CS degree) nor will I ever be (I don't have any time to work on side projects) good enough to just float in on my credentials. The stack is the only choice for me.

Brad on February 8, 2008 09:50 AM

There is also another type of experience that people look for. "Recent Experience". And that was one of the reasons my application was not even considered for the position. I quit my previous software development job to pursue M.S (Computer Science). Since my experience was about 1.5 years old, the company said I did not have 'recent experience'. What can I say to that?

shyamala on February 8, 2008 09:52 AM

You nailed it. I keep coming here through DZone but I'm subscribing to your blog right now.

Peter Thomas on February 8, 2008 10:02 AM

Great post -- I was just thinking about this very subject this morning, planning on writing about it, and then you beat me to the punch! Quit being so damn prolific and timely, dude. I'm starting to feel like Scott Hanselman over here! ;)

Couldn't agree more, though. Obviously, coders need to be able to code -- a few folks here apparently missed that one. But at a certain point, it's true -- you either get it or you don't. For me, the aha moment (having come up in the world of managed code) was understanding how memory and processors worked. Once I got tha stuff, and how my languages were shielding it from me, the world got a whole lot clearer, and learning new stuff a good deal easier.

Chris Nunciato on February 8, 2008 10:04 AM

I agree to a point. Clearly a good developer should be able to learn new skills fairly quickly, so qualities like talent and aptitude are usually more important than experience, especially when you are dealing with experience in some specific technology (like low level TCP/IP coding).
However, with a more general skill like Java programming (or programming in general) there is a big difference between 6 months of experience and 6 years of experience. I have been a professional Java developer for 3 years now and I can tell you I know a lot more today than I did two and a half years ago. And I expect to know even more three years from now. Problems that used to take me a week to debug I can now fix in a few hours. I attribute most of that to my experience.
Yes, a good developer should be able to learn a lot in 6 months, but they should be able to learn much more if they are given more time. The idea that after working with something for a few months they will know everything about it is just plain false. And several links to blog entries dwelling on anecdotal evidence and misused statistics certainly does not make it any less false.

Nick on February 8, 2008 10:23 AM

I agree. In march of last year I landed my first job as a software engineer for a small company. Before that I was self-employed for about 1 year, and prior to that I pretty much taught myself how to program and did it for the sport of it for about 5 years. I stretched the truth a little bit on my resume to get my foot in the door, but the bottom-line was I could back up this projection of myself because I was confident I had the skills required to hold down the job, and be successful in this career move.

It did take me about 5-6 interviews before I got a job but my current boss seemed to grasp the idea, and he was wise enough to recognize that although my experience seemed to lack on paper that I was still the man for the position. And I'm grateful for that.

So now I'm involved in helping this small company grow which is quite challenging and good experience. The company has been around for a long time and it seems like they have kind of hit a brick wall for awhile and I can see why. I don't agree with many of there practices. My boss tends to go off on tangents and doesn't have the knowledge for efficient decision making at times, which does lead to some bad software design. Upper management overwhelms the under-sized under-trained staff with ridiculous deadlines because they don't understand the means to reach the end. And it really does take time for me to make my mark. Make them feel confident in my judgment and understand better ways of doing things. But it's almost been a year now and I'm beginning to make some important changes in the development cycle, software design and deployment which are crucial if this company is every going to 'grow up'.

joe on February 8, 2008 10:47 AM

Another binary post by Jeff where two different concepts are placed in two very distinct piles: oranges here, apples there.

That you "get it" is not sufficient for employment, nor to value what you are worth. I want to hire people who "get it" but don't have to look at the refs and specs every time they need to do something; I'd rather have someone who "gets it", but has enough experience for what he gets to reach the keyboard effortlessly. You won't get a new hire who "gets it" after 6 months in the AS/400 world; nor in assembler; nor in security, nor in a myriad of places where just being at ease with the structure of a language is not sufficient, experience must be gained.

Oversimplification challenges truth, and binary thinking does it to an caricatural degree.

Louis on February 8, 2008 11:00 AM

I worked for years with Mom and Pop outfits doing basic graphic design and a little web programming before I got my first real programming job. Most places I went into an interview with looked at what I was currently doing and turned their nose up at me because I didn't do "REAL WORLD" programming. Never mind that I could pass their phone screens and employment tests. The years of experience killed me every time. But being a glutton for punishment after my 60th interview I found someone to take a chance on me and I've never looked back.

Yep Yep

Mark Cavins on February 8, 2008 11:34 AM

i couldn't agree more with this post.You nailed it on point

gogole on February 8, 2008 11:53 AM

I agree with Louis. There is no magic formula to hiring someone. It's a risk every time. I've had a few work out very well, and others limp along for years. Experience is only one small part of many things to consider. One guys resume' listing for the jobs held in the last five years ran two pages. This might work if you are looking for someone to jump from one task to another, but the job I was hiring for took six months to a year to get up to speed. One guy I did hire stayed quit at lunch on the third day. He was qualified, seemed to be a quick study, but didn't stay (never did find out exactly why). Or the guy who worried incessantly about the cost of a method call, and therefore wrote methods that stretched 10 pages at the minimum. Or the person who thought I was sabotaging him because I only needed a few minutes to find the error in his code.

Like I said, some have worked out well. The last person I hired before leaving my last job found a brilliant solution to a problem I had been struggling with for months. And he kept them coming.

I have wondered if the same criteria of X number of years goes into jobs ads for CEOs, company presidents, and the like.

Tim on February 8, 2008 12:05 PM

In the software world, many (not all, but many) of the jobs are still roughly ‘state-of-the-art’ kind of positions. Like the companies asking for “x years of experience” in a technology that is only “x-1 years old”, to ask for specific skills sets when building a new, bleeding edge product is small-minded thinking that is doomed to yield sub par results. Yet it happens all the time.
I have worked in high tech for + 20 years. As soon as I “figure out” a product, I am bored and want a new challenge. And I know lots of people like me – we work for the intellectual challenge. (And the cash, of course, but also for the intellectual challenge…:-). Calls from recruiters asking me about my experience with “x” or “y” product (because they saw it on my resume from years ago) don’t get returned.
Proven ability to learn and interest in working on new product are critical skills for working on “new” software.

Bill Holtsnider on February 8, 2008 12:31 PM

Formal education teaches you how to do things.

Practical experience teaches you how NOT to do things.

Both have alot of value.

Davide on February 8, 2008 12:49 PM

I've had the dubious experience of having to explain to a recruiter that the stated skill requirements indicate the composition of the TEAM that would be required to build the desired system, and I helped him break the 'laundry list' up into pools of expertise that go together - not that I got any of the jobs that we created descriptions for!

Mark Pippins on February 8, 2008 12:59 PM

I have been told "not enough experience" (in terms of years) so many times... It's pretty frustrating. OR I hae been skipped over for people with no experience, that's equally frustrating.

RB on February 8, 2008 01:05 PM

I should clarify by "no" I mean, someone who had never programmed in css/xhtml had gotten a job instead of me because they were 'cheaper'.

RB on February 8, 2008 01:06 PM

Scott Mitchell seems to think otherwise...

http://scottonwriting.net/sowblog/posts/13098.aspx

Babaloo on February 8, 2008 01:11 PM

I interviewed for a Business Analyst position once where the interviewer (a QA guy) thought I was more of a "systems analyst". I thought he was more of an, well, anyways.

Been doing this long enough to get employed as a BA, SA, developer, project manager, etc.

People _love_ to pigeon-hole.

I'll take the type of personality and aptitude over total years almost anytime.

Steve on February 8, 2008 01:26 PM

Ha! My thoughts exactly!

Many developers claim to have 8, 15, or whatever years of experience, but what experience? The quality and intensity of experience or huge factors too!

I often compete in interviews with people who have maybe a couple more years than I do. I ask them: "How many years have you been driving?"... "Oh, then if you take a rally, or a formula 1 drive who has driven 2 years less than you, you must be a better driver, yes?"... that pretty much closes the case

CptBongue on February 8, 2008 01:33 PM

I remember reading The Mythical Man-Month, in which Fred Brooks talked about the "first project" rule, whereby every developer/programmer who works in industry messes up on the first big project they are part of. This is due, normally, to lack of experience in cross-team communication, etc. Such communication skills can only come from time working as part of a software team. Thereby he suggests only hiring for reasonably senior project positions someone who has prior "experience", at least as part of a working team, if not part of a software team. But you are right that actual programming skill is more important than experience with an actual technology/language.

Kazar on February 8, 2008 01:36 PM

It may be generally true that you hire for the ability to learn, but it isn't perfect. It is better to think in terms of "types of skills". I'd hire a Java guy into a .Net role in an instant. The C++ people can go into those roles too, though I'd prefer someone with experience dealing with garbage collection issues within a VM. On the other hand, the most brilliant C++/Java/.Net guy may completely suck at database because SQL just requires a different way of thinking. Likewise, those Lisp hackers might do javascript really easily, but a Java guy may not.

I always look for people experienced with a way of thinking, not for a specific skill.

Mike on February 8, 2008 02:02 PM

These recruitment related posts are very interesting. I totally have to agree with the point that the years don't matter much, but only when talking about people with "natural" talent.

If you have a person who isn't talented, he will need a longer time to learn a tech, and I think sometimes such years are posted in job offers exactly to make such people not submit their resumes etc., while a brilliant programmer will know he will do well. Of course, the company might refuse to interview them without the experience, but like said, then the company is probably not that worthwhile.


There is one thing I think years help in, though. That is the speed you can pick up new things. The longer you've been programming, the easier new stuff will come to you in my opinion.

Oh and Jeff, please please PLEASE... FIX THE FONT.

It's horribly ugly in every other browser than Internet Explorer here with Win XP. I know you like IE, but not everyone uses it.

It's actually quite weird that the font is bad, I would expect someone like you to actually spend a bit of time... you know, testing that it actually looks good in other browsers too.

Jani on February 8, 2008 02:18 PM

re: Font -- it looks fine with FF on W2K, but yes, bad with FF on XP.

Steve on February 8, 2008 02:34 PM

> Oh and Jeff, please please PLEASE... FIX THE FONT. It's horribly ugly in every other browser than Internet Explorer here with Win XP. I know you like IE, but not everyone uses it.

Short answer: Turn on ClearType. http://support.microsoft.com/kb/306527

Long answer: If you can't or won't turn on ClearType, remove the "C" fonts from your system (Calibri, Consolas, etc) that were installed with Office 2007. They are designed for CT and will look horrible forever on your system until you enable CT. Once you remove these fonts, the CSS stylesheet falls back to Tahoma.

Jeff Atwood on February 8, 2008 02:52 PM

You really, very seriously, need to get a "format for print" or "print" button. A blog without one is half-assed at best.

Kelly on February 8, 2008 03:13 PM

>I might be wrong but in the UK you can no longer ask for x amount of years any more as it is seen as discriminating.

That is so lame. Discrimination is the point. Next you won't be able to discriminate between a lazy person and a non lazy.. oh wait...

brian on February 8, 2008 03:30 PM

I believe the cases of "X years experience for technology Y", when Y has only been around for X-1 year, translates to "We have a H-1B visa applicant we want to hire, and his resume says X year experience"

I had boss once we did something similar, but his big thing was "Years of experience IN THE INDUSTRY". In his mind, I would have been better off getting a computer operator job right out of high school and worked my way up to programmer, instead of wasting time going to college getting a Comp Sci degree. That way I would have had 4 more years "in the industry".

James Curran on February 8, 2008 03:57 PM

You didn't mention the hilarious cases where they want more years of experience then the Technology has existed. (e.g. postings in 2003 for developers with 5 years of C# experience.) I'd guess there are probably now postings for 5 years of experience using LINQ.

Steve Steiner on February 8, 2008 04:13 PM

- "Years of Experience" is one of those "buzzwords" headhunters look for, but doesn't know how to work for it.
- "Years of experience" (quantity), DOES MATTER, BUT QUALITY, ALSO.

mramirez on February 8, 2008 04:51 PM

Many developers posted comments about Programming Languages. We are not in the 80's anymore. We work with Development Tools (Programming Languages + Libraries + Development Environments + else) !!!

That's why it's not so easy to learn a new Development Tool (Programming Language), anymore.

mramirez on February 8, 2008 04:54 PM

I've seen this phenomenon happen in front of my eyes. I was hired as a contractor about the same time a fresh out of college guy was. I took him under my wing - he lacked confidence in his abilities. I could see he was smart and motivated so I knew I wasn't wasting my time.

12 months later when I left he was the best programmer at the company and there were plenty of very "experienced" programmers there.

I hire by talent first, makeup (passion, character, etc) second, and experience third. Unless it's a short term contractor and then all I care about is whether they can do the specific job I'm looking for.

Matt Lentzner on February 8, 2008 05:15 PM

The disaster known as "Microsoft Vista" explained. "Yea, I can learn. I can make Windows more secure" ... "yea, I can learn. I can make Vista pretty" ... "yea, I can do Windows applications. I can learn" ... "Hey, guys!!! Check this out!!!!" (shoots his USB rocket launcher ...)

PaulG. on February 8, 2008 06:29 PM

> You really, very seriously, need to get a "format for print"
> or "print" button. A blog without one is half-assed at best.

Dude, this blog does have a format for print option. It's available from the "Print" option under the File menu.

Oh wait, haven't you heard of CSS?

Simon Wright on February 8, 2008 07:04 PM

If you are really interested in learning how to hire people, I would suggest learning about the field of Industrial Psychology, a large chunk of which is focused on how to recruit, select, hire and retain people. Hiring based on abilities (raw talent, so to speak) has been well-known in this field for decades. It's when people try to hire based on their own personal pet theories about "what makes a good candidate" (especially when individual hiring managers do this) that you increase risk unnecessarily.

hiring hint on February 8, 2008 07:35 PM

NOT EVEN WRONG

I have to disturb this self congratulatory orgy of back patting, because you couldn't possibly be more wrong. I'd say you're dangerously wrong, because your contributing to the perpetual youth culture that is software developments biggest millstone.

The fundamental problem with your analysis is you're comparing apples and oranges. A smart person is going to outperform an idiot with ten years drooling experience, but that's not the real issue. Is a smart person with 3 months experience going to outperform a smart person with ten years experience?

As much as the kiddies here might like to believe they're special, analysis of congitive development shows it takes ten years to truly master a discipline. When I hit the workforce, I was a lot more productive than most other developers. It would be easy to believe that I was a guru, but the reality is it had a lot more to do with an extensive background in solving logic problems and programming since my early teens than innate aptitude.

The fact is the programmer I am today is several orders of magnitude better than the programmer I was ten years ago, even though I was already pretty good. The reality is the more problems you face over time, the more you build your development skills and intuition.

Breadth of experience DOES matter and that takes time.

Gerry on February 8, 2008 09:16 PM

Whether or not this is true is somewhat irrelevant. What matters is convincing the employer this is true.

It sucks but it's true. Lets see some more articles on persuading.. maybe?

Farley Knight on February 8, 2008 09:47 PM

I have a theory that where this happens, there is also a political structure within the company too. If a person is so adamant on getting so specific in thier requirements like stated in your post, then they really don't have a clue what it means to be a programmer.

I simply avoid those contracts all together.

Great post!

Wayne on February 8, 2008 11:07 PM

Thank God at least a couple of wise people took the time to point out the awful flaws in this post.

Bill on February 9, 2008 01:46 AM

Peter Norvig disagrees with you, Jeff. http://norvig.com/21-days.html

Bill on February 9, 2008 01:50 AM

Peter Norvig disagrees with you, Jeff. See <a href="http://norvig.com/21-days.html">Teach Yourself Programming In Ten Years</a>. Smart, fast learning people are no substitute for real experience.

Also, attempting to comment on your weblog regularly results in errors revealing the crappy implementation beneath:

An error occurred:

Rebuild failed: Renaming tempfile 'C:\codinghorror\blog\archives\001054.html.new' failed: Renaming 'C:\codinghorror\blog\archives\001054.html.new' to 'C:\codinghorror\blog\archives\001054.html' failed: Permission denied

Bill on February 9, 2008 01:52 AM

I have a linkedin endorsement from the author of an OReilly book about a prominent web framework. I contracted for him in 2006 in our metro area where he is also a CTO for a small/medium sized company, and he recommends me for *any* project.

Last year however some company turned me down because I didn't have enough *recent* experience (it had been a year) with the web framework in question. Their loss.

George Jempty on February 9, 2008 02:40 AM

I'd go further - having many years' experience in a single technology often means that the developer has reached that point where they nolonger want to learn anything new.

"10 years MFC" really means "can't or won't learn .NET"

I've noticed that many developers, after a few years reach a certain technology, and then stop learning - they become expert in it, and any new languages/frameworks/environments are "too slow", "unsupported", "no benefits".

Do you know anyone who still uses Visual Studio 6 because they say VS2005-2008 are too slow? They've got stuck at that stage. Know someone who learnt .NET/WinForms but not .NET 3.5? Stuck again. Those people may be smart, they may have many years' development experience, but if you need them to re-train, you have a struggle on your hands.

Sometimes of course, it's not the developer's fault: many companies hire someone new for any new projects, and the developers on their old MFC application are "too valuable" to move on to another project.

- Stu

Stu Smith on February 9, 2008 03:58 AM

Jeff, you may have a point since after 10+ years of coding my code still looks like crap...however, it doesn't account for how my 10 year old code looks even worse. /Mats

Mats Helander on February 9, 2008 05:27 AM

Great article... couldn't agree any more.

Aaron on February 9, 2008 07:02 AM

Well....

It's certainly true that 10 more years won't make a good programmer out of a bad talent.

But, the reverse is true. 10 more years of experience WILL make a better programmer out of a great talent. Sometimes a MUCH better programmer.

Generally I've heard it said that it takes 15 years to master any kind of fundamental craft, be it programming, carpentry, motor mechanics, or something else. I think that's pretty much true.

(Also, it's been claimed that most people can only learn one such craft properly throughout the span of a lifetime. I also believe that to be true... even though it's an entirely different issue altogether.)

Erlend on February 9, 2008 07:11 AM

@Gerry

You're so right that a smart programmer with 10 years experience will outshine a smart programmer with only 1 year. But, I'd prefer to hire a smart programmer with a single year of experience than a lousy programmer with 10 years.

I've been interviewing programmers for the last couple of weeks (I'd like to thank Jeff for running this story and the one about telephone interviews — talk about excellent timing). The HR department slapped 5 years experienced required on the ad. We rejected over 90% of the applicants based on their CVs alone. Telephone interviews got rid of another 5%. So far I haven't come across one I'd like to hire. I'm beginning to wonder whether all the smart programmers with over 5 years experience aren't all happy where they are (either that or there are very few smart programmers). I persuaded the HR department to re-advertise the role without the 5 year requirement. I know we'll get a load of CVs, most of which will be rubbish, but I'm hoping we'll find some young smart programmer who hasn't found his dream job yet.

Naked Programmer on February 9, 2008 08:11 AM

I really agree with you....and the same thing happened in our company a guy with 6 month experience is much better than the oldest employee of our company

Roshan Bhattarai on February 9, 2008 09:44 AM

It is kind of seniority over talent, a whole philosophy on it's own.

Or the paradox of the good plumber: he works faster, thus get less paid. Translate to programmer learning faster, thus having less experience.

I have seen very extreme cases of this, where it was required to have a combined 20 years of experience (in radically different areas), but be no more old than 25.

Musaran on February 9, 2008 10:18 AM

sometimes the year of experience matrix is skeewed to hire a specifc person they want. They have to do that as they are required to let people bid on teh positiona nnd realy they already have a person working in that area and want to renew that project. They than come a a trix that would like reward their preferred candiate the highest point!


Definitely appitude to learn and wilingness to work hard and with due cre is most important as programmer. willinges to stick to spec is critical as programmer. END user interface Design is vastly diffferenet from system or embedded programming.

G on February 9, 2008 02:32 PM

I think companies should state, "must NOT have 3-5 years experience with X". Anybody who's worked with some technology for 3-5 years is probably bored of it and will not be motivated to do their best. They won't be learning anything new, they'll just be doing what they were already doing for that 3-5 years that's listed on their resume.

Rick Brewster on February 9, 2008 04:28 PM

I agree, in a job posting I was interested in last year, I pointed out to a hiring manager that the job they had open required someone with four years experience in WPF. I also pointed out that they were limiting themselves to only people that worked for Microsoft and had access to WPF long before it was publicly released. Needless to say they corrected this error. The hiring person probably didn't know the technology but only knew the acronym and that it was for developing "cool windows UIs like on the Mac".

SarkieGit on February 9, 2008 05:03 PM

For one job with a somewhat pointless years of specific experience requirement, I was able to get the hiring manager to like me, give me a phone interview and everything. Then I talked to the lead developer who just asked specifically how many years experience with that particular tech. I told him (this information was available on the resume) and then he responded, "I'm sorry to waste your time, we need someone with more experience with this particular technology." It was for a Junior position, too. In this case the HR person was actually much more reasonable than the lead developer.

I was upset at first, but then realized that I probably didn't want to work for a guy that short-sighted anyways.

steve on February 9, 2008 11:26 PM

I agree with the post wholeheartedly. I first experienced the disconnect when I became an MFC developer back in 2000. Previously I had only worked on C and Unix. I took some time to learn C++ and then MFC before applying for new work. I had about 4 years of industry experience under my belt at that point, doing projects. I had 0 years of project experience with C++ and MFC. After looking for several months I found a place that was willing to hire me as a junior MFC developer. I had some things to learn still, but after a few months I was basically as good as most of the other developers there. After several months my project manager became very impressed with me. She noticed that I was able to handle client meetings well, that I had good communication skills, and that I anticipated problems before they happened. But of course, I thought to myself. I had experience with these things from the 4 years I spent at my previous job. People also noticed my work ethic, that I put in my hours, and got substantive things accomplished. No one really said it, but I got the sense that I should've been hired on at a higher rank than I was. In fact rumor had it that I was up for a promotion, but then the bottom fell out of the IT market in 2001, and I and most of the people I knew were out of a job. Oh well.

Since then I haven't thought well of the "X years of Y" mentality that most employers have. I wish they'd get a clue that they're not even using the right criteria.

My own sense of why this mentality persists is that business schools, and society in general, still think in terms of the Industrial Age. Companies act like they're hiring electricians, or plumbers. Each time a new language comes out they think it's a whole new system, and therefor they have to find people who know it. What they're missing is that a new language is just a new set of rules, often with the same basic architectural assumptions as several other languages. Today it's more important to learn about APIs--a kind of "architecture inside of architecture"--than languages. The APIs are what take the longest to learn.

Mark Miller on February 10, 2008 12:24 AM

Experience matters, up to a point.

Different kinds of experience matter differently. People seem to improve when they've used platforms, for about a year or so. Beyond that, they might improve in other ways.

It takes more than a year or so to learn coding and data structures and algorithms and algorithm-analysis and business problem analysis.

Learning to get along productively with different types of people takes a bit longer. Marketers, difficult bosses, engineers in other disciplines, business customers, and so on.

Learning how to present software to non-software people takes a while too. People seem to improve over a period of decades. But the non-software people are also becoming more sophisticated over that time scale.

The experience of going to a good school matters too. Nothing replaces the basic math and the study of the basic algorithms. People don't seem to learn much in the way of new programming paradigms outside of school. Look at the adoption of object-oriented and now functional programming. Courses, at least, are the way to go.

Learning about the application space can be done in school but you can be trained in finance and end up working on embedded systems or web apps. And the other way around. So application space learning has to be on the job and is often per-company. HP does things differently than IBM, which is different from Microsoft, Google, etc.

There is, however, no cure for stupidity.

Fred on February 10, 2008 05:46 AM

Completely agree. Whenever I have been asked the experience question regarding a technology I don't know in an interview I have always answered roughly the same.

For example, "Although I don't have knowledge of that particular language/technology at the moment, I have experience in many languages/technologies and the ability to learn. If that skill is essential on day one of the new job, I will use my notice period ensure that I have at least a rudimentary level of knowledge by the time my new position begins."

If the company doesn't like this answer and would refuse the position because I don't have three years of the particular skill then I probably wouldn't like working there anyway.

BlackWasp on February 10, 2008 06:18 AM

I believe Jeff is pretty much right on the money. I'd like to add a little bit more though. Nobody is saying years of experience isn't helpful. Every programmer needs to go through the pain of learning multi-threading correctly. That 1 college course that touched the topic briefly clearly isn't enough. Only years of experience will get you that. However, years of experience is secondary to "smart" and "gets things done" (http://www.amazon.com/Smart-Gets-Things-Done-Technical/dp/1590598385). An experienced dodo that's a waste of space is a costly mistake.

Moreover, that programmer out there that's smart, gets things done, and is experienced isn't available for you to hire. He or she already is working at a great company (or owns their own) and doesn't want to leave. You're only hope is a hefty signing bonus or a disgusting amount of stock options to lure them over.

Nicholaus Shupe on February 10, 2008 08:49 AM

Saying "experience don't matter when hiring" sounds to me a lot like "experience is next to worthless" or "coders don't learn anything on the job".

I am the first to remind people that the actual number of years of experience doesn't really matter (we've all met many useless programmers with several years of experience).
However, it is also true that even the most brilliant people learn and gain much from professional experience, and usually not much use for serious work unless (until) they have it.

Note that experience does not always equate specific skills. Simply working as a professional programmer for a year or two teaches MANY lessons beyond a specific skill like TCP/IP: how to estimate work, how to do engineering tradeoffs, how to work in a team, designing and implementing code so that you can maintain it two years after the fact, writing robust and error aware code. Even serious hobbyist programmers are usually missing those skills, simply because they never had to learn them.

Also, some skills are not so easily acquired. For others, we simply don't have the time for the new employee to pick up. For example, if we are working on embedded systems under a tight schedule, I don't have the time to wait for the new Java guy to grok pointers. Our new employee needs to know C well enough, and we also expect him/her to be able to deal with new platforms almost by themselves. We don't have time to babysit them.
These are not the kind of skills that people "pick up" in 3 to 6 months (and even if they did, it's still too much), they take a year or two to develop.

And of course, there are the various fields of knowledge: signal or image processing, scientific computing, speech compression, etc.

So yeah, when we look for candidates, we look over previous work experience. We will (and have done so) accept candidates without prior professional work experience, but even then they normally have some years of experience as hobbyist programmers.

M on February 10, 2008 09:29 AM

I think that the simplest thing to say about this is that 'years' isn't the right unit of measurement for 'experience.' If somebody told you that they got hit by a car, you wouldn't ask "How long?" You would ask questions that aimed to discover the person's memories of the components of that experience, that person's synthesis of the components of that experience within a wider context of just the experience itself, and finally the changes that the experience brought about within the person that would affect the way that they would approach other situations in future.

Comparing a 'smart programmer with 1 year of experience' to a 'smart programmer with 10 years of experience' is just silly. I've been playing guitar for 10 years longer than I've been programming, but I'm a lot better programmer than I am a guitar player.

also:

"analysis of congitive development shows it takes ten years to truly master a discipline"
"it takes 15 years to master any kind of fundamental craft"

is completely unsourced nonsense that substitutes research-y sounding words for research.

and:

Smart, fast learning people are no substitute for real experience.

adds the adjective 'real' to destroy any meaning in the sentence. Reality isn't measured in years. If the reality you're talking about is extent of retained facts, depth of synthesis of known facts, and effective modification of strategies based on those facts, this is something done better by "smart, fast-learning people" by definition.

Jamaal on February 10, 2008 09:54 AM

Agreed, however: Good programmers get better at programming every year. Average programmers get better at their niche every year.

kyb on February 10, 2008 10:02 AM

" ... there's about even odds that they have no idea what they're doing."

Among the things interesting (to me, anyway) about this quote is its implicit self-loathing: half of all developers are clueless? Seems an extreme charge. What other professions judge themselves so harshly?

But the answer to that is fairly obvious: the social sciences. Talk to any economist, psychologist, sociologist, educational theorist, political scientist, etc., and they'll quite willingly let you know that most of their colleagues are idiots and charletans.

And so it is with programmers--methodological wars, competing theories and schools, and endless oscillations between true-believer enthusiasm and the dark night of disillusion and self-hatred. Perhaps programming is a social science, rather than a type of engineering. It does feel that way.

But more to the immediate point: hiring requirements specify <x> years of experience because (1) they don't want to pay for that 6-12 month learning period, and (2) hanging on to a position longer than that gives some hope that you did indeed 'get it'. HR is not swinging for the fences in creating job requirements, they're just trying to avoid striking out. It's about risk aversion, not excellence.

And in a field that rates itself as 50% incompetent, doesn't that seem a sensible approach?

bobD

bobD on February 10, 2008 10:15 AM

Oddly enough Martin Fowler has a similar post today. http://martinfowler.com/bliki/CheaperTalentHypothesis.html

Adrian. on February 10, 2008 06:03 PM

Years of experience are not a myth. They matter a lot.

This blog is a joke and i really do not thank you for giving such advices to conduct an interview.
IT interviews are some of the most boring in the market due to geek questions like these.

It is a real torture for the candidate.
Do you really need to ask a candidate to write 15 methods to do these and that, and ask him to learn by heart what is this collection or these one ...
Jesus Christ ...
We, programmers, are paid to code and to learn.
When we have a problem, we do some research and some learning, then we code.

Mike on February 11, 2008 05:46 AM

i agree in terms of technical skill... however, inter-personal skill may take longer to build up. both sets of skills should be considered when hiring a candidate imo.

jin on February 11, 2008 06:53 AM

You definately hit the nail on the head and it is kinda funny, because I use to hear the you don't have the Real life experience when I was orginally looking for a job after college until I was hired to a consultanting company. What I think is so extremely funny and why I feel the years of experience should not be a factor in hiring/recruiting is, because recently we hired a developer who had 10+ years of experience with the language that I do virtually all of my code work in. The developer in question was let go within 2 months, because he was not able to do even the simplest tasks correctly. Unfortunately this developer would work great as a code monkey, but is unable to work as a developer.

Brandon on February 11, 2008 08:30 AM

I structure my interviews to find people who are capable, not necessarily qualified. BlackWasp is the guy I'm looking for, he's capable of picking up the necessary technology although not qualified today to use it.

David Truxall on February 11, 2008 10:13 AM

Agree when applied to programming languages, or technologies.
But not necessarily about full fields.
It will be more difficult for a Java programmer to do low level TCP/IP coding.
And there are fields where experience cannot be replaced. Years of experience in security, or internationalization, or working close to the machine, are impossible to replace. That experience transfers easily to other platforms, or programming languages.
Kind of orthogonal things, and one should not confuse them.

Mihai on February 11, 2008 10:38 AM

Great article!
Now I don't feel alone anymore, Oh my Gosh! I had been going to interviews the last couple of month, with people that really I can call morons , I have 10 years experience at PowerBuilder, Sybase, Informix, etc, but because I emigrated from my country, I have to start over here in America, and the place where I live (Orlando) doesn't have to much market for PB.. so my husband that is a senior .net developer push me to jump to this side of the pond, and now here I am doing .net with c#, and all these people interviewing me, telling me... oh no.... you are so light, oh no.. we are looking for X more years of experience...etc,
it looks like I wouldn't move easily from where I am right now..., I feel SO FRUSTATED, because without to want raise my ego, damn I'm good in what I do...
:( Just waiting for some smart manager to hire me...right?

Carole on February 11, 2008 11:05 AM

In most programming positions you're going to need some time to learn their particular requirements and the software that you'll be working with. For most competant programmers, it's not a big leap to pick up the language while doing this.

On the other hand, as someone has mentioned previously, you still need experience in certain realms before you're really qualified to do some jobs. You might not do very well with user interfaces if you've never worked on them before (say you wrote low level TCP/IP code through most of your programming career...). You might need some database experience before working on an application that is heavily data-driven.

Of course, you don't need the guy with 10 years experience with IIS and MS SQL Server using C# if you can get the person with 15 years experience using Apache, Oracle, and Java. You might have to hope they can spin their head 180 degrees to get it all into their head, but if they're competant they should be able to do it.

Then there's the one-trick ponies and the people that will complain the whole time that while C# is "like" Java, it's "not" Java, and that feature XYZ should work like it does in software ZYX.

Vizeroth on February 11, 2008 11:41 AM

Sadly, this is is so true.

This is pretty much why, I have had lots of problems getting a job. They don't look at your qualifications. Or your capability to learn to do a job.

They don't realize we had to learn how to program, if they give us a chance...

Craig M. Rosenblum on February 11, 2008 12:22 PM

This is very very true...most of my experience is very basic, using design templates and drag and drop developer tools for websites and simple programs, but my near perfect GRE score has allowed me to pretty much solve any problem I've encounteered thus far, and I taught MIT and Stanford prospects for 2 years and did not find them particularly gifted, but they will be the ones hired, and, it is wonderful, since I am happily off to solving puzzles and enjoying gadgets and tech. :O)

Paul Roe on February 11, 2008 06:10 PM

The following would be jokes, except that they are true stories from the '70s.

ca. 1971:

MIT student comes back from winter vacation. Roommate asks, "Did you get the summer programming job you were going to interview for?"

No. They asked me if I knew COBOL. I said no, so they said they couldn't give me the job. Do you think maybe they don't have any Language Reference manuals?

(Source: the roommate.)

ca. 1976

A guy interviews as a systems programmer at a small mainframe shop. They ask him how he learned IBM's DOS/VS and CICS at his previous job. He said, "From the IBM manuals."

They didn't hire him. Because the manuals were so hard to understand, they figured he was lying, so they didn't want him. Alternatively, if was telling the truth and had successfully learned from the manuals and been successful, he couldn't be normal, so they didn't hire him.

(source: one of the interviewers)

Dakra

DAKra on February 11, 2008 07:33 PM

Spot on! My best ever hire (and I was hiring based on Joel Spolsky's philosophy of smart people who get things done) was a fresh out of school graduate.

She blew me away with her passion and understanding although she had no commercial experience. Within 3 months I had decided to promote her to senior developer alongside a guy with 10 years experience. It made no difference, she got it, and she loved web development. Could easily have been a software engineer technically speaking but had the passion for front end stuff.

The only reason I am where I am today is because someone took a chance on me way back. I passionately believe that is where the best people come from, so when its right, I'll take my chances with no experience.

Laura Francis on February 12, 2008 02:12 AM

Excellent!
This is a perfect example
http://thedailywtf.com/Articles/Not-Too-Particular-and-More.aspx

Hugo on February 12, 2008 02:36 AM

I agree Jeff, I have years of experience and guess what, it means practically nothing when going on a new gig.

I've done consulting, tech support, sales support, architecture, DBA, software engineering, you name it , I've probably done it but each and every experience is different.

The only thing that the 'years of experience' has done for me is allowed me to understand how to get through the problem in a sort of similar way. And I'm not talking about coding, that’s the easy part.
No, the hard part is understanding your customers business, needs and how you can contribute most effectively.

And don't let me get into office politics, that's the hardest part of all and unfortunately, the one that makes or breaks both you and your project most of the time.

I could go on and on but what experience has taught me is that I can more readily assert which projects I want to take on and which ones I don't and most of time it has nothing to do with the technical challenge and everything to do with the 'politics'…

Regards...

Mac on February 12, 2008 05:27 AM

Let's get real here. It is completely true that we can not stare at the years of experience in Java, C or any single discipline and then make any definite conclusions how good the guys is.

The rule of the thumb is that it takes about 10 years for people to be the best they can be in their job. Some people are better than others, and some people are masters. They are separated by their natural talent, hard work, discipline and enthusiasm, but it still takes 10 years for them to be the best they can be.

So do not overlook experience, but you still want that fire and enthusiasm a notch more.

Tero on February 12, 2008 08:02 AM

experience ...hmm, do you want to know where's the difference between experienced developer and rookie?

rookie will give you faster code, rookie will give you code prepared for majority of future demands right now, may be rookie is even faster then experienced guy

...but experinced guy will give you simple code, more LOC, slower execution BUT code which is easy to understand and easy to maintain.

In other words, from rookie you've got super dooper code but and only guy whis is effectively able to maintain this code is your one and only rookie ... but he won't do that because it's not challenging, it's boring and first major new feature reqeust will ruin all the magic. From expereinced guy you have a code which is simple, everyone can maintain that code easily, anyone can add new features easily ... and the code is based on "what was wrong last time I did it" experience (that's all the magic of the experienced guy ... and that's what I call The Experience) ... and as a bonus usually you have 100 times more accurate time estimations from experienced guy.

That's basically the whole story.

I want an experienced guy working with 2-3 rookies ... it's like family, children need parents.

So again I have to almost completely disagree with your article (as I did with your interview process ideas), sorry jeff
simon

simon on February 12, 2008 09:37 AM

Jeff,

While I can agree with "you either get it or you don't" premise, your argument that experience does not matter simply does not hold and it is measured in cold hard cash. Since the dawn of a clueless, semi-literate (and often outsourced) automaton, I have been making my consulting dollars primarily based on productivity. Productivity itself is directly correlated to experience. I can work faster, better and with fewer bugs than your average coder who learned his craft at some IT roadhouse.

Maybe you should rename your blog as "blogging horror" because coding IS all about productivity and there is no productivity without learning and experience.

Who would want a job that hinges on low-level IP skills anyway? Did they slash the rate for that guy because low level IP wasn't on his resume? If I am dealing with an irate client, I will find another client and move on. If you cannot do that (or do not feel comfortable doing it), IT consulting isn't for you.

Or are we talking about die-trying IT full time job with low-level IP kung fu here? I don't know about you, but I'd rather be doing some cooler stuff than bother with HR fantasies.

Multikor

SamMultikor on February 12, 2008 10:58 AM

"Experience doesn't matter, it's your willingness/ability to learn that counts"
Phooey! What ultra liberal feel-good planet are some of you?

Experience counts for a lot. If, after almost 10 years at this gig, you're trying to tell me I'm likely no better as when I graduated? I think I'll go kill myself now.

Notably, if you're an idiot then you're just an experienced idiot. Having x years may not positively correlate to being an y times better programmer, but "toxic, counterproductive years of experience myth"? Drama queen.

"It's been shown time and time again"

Really? I wouldn't call your data conclusive. Your assertion of experience not predicting skill doesn't appear to be very scientific. You quote your own previous posts which refer to programming contests and students reporting how long they took to write software. I don't think either of these data sets relate well to the general corporate programming world that we live in. Students accurately reporting time spent? Read the freakonomics blog some more and how people lie on surveys.

"10 years of experience is 10 x 1 years of experience"
You could say the same of surgeons. Pilots. Policemen. Yeah experience is crap. The corollary is 20 different jobs in 10 years. That person sounds like they're always moving on to the next big thing and they never actually learn enough to be useful. I'd prescribe ritalin for their ADD since they can't focus for longer than ... ooh look at the shiny thing.

There are lots of problems with hiring and skill metrics, candidate assessment, skill perception, and the forms discrimination can take, but in a comment to a lame blog post I'm not going to bother.

This blog has become the Enquirer. Big headlines. Wild assertions. Bait-and-switch. Red herrings. No proof. I remember when there was serious content, but now it's making TDWTF look positively academic. At least they don't take themselves so seriously.

PS some good replies in there. At least some of you get it.

Maybe you should change your assertion to: What *good* software developers do best is learn, and if you want to be good and stay good, you must keep learning.

-Naysayer
"Opinions are like a**holes .. everyone's got 'em"

NaySayer on February 12, 2008 01:09 PM

One situation where experience in specific skill matters is when hiring contractors. When you are being charged by the hour, you don't want a contractor to be learning on your dime.

Melvin on February 12, 2008 04:51 PM

totally agree with Melvin. Consulting is the only way to show your skill. Full time should be spelled "fool time" judging by the number of automatons who "can learn quickly" and still remain "overall great guys."

I cannot think of a single human endevour worth pursuing where the ability to learn and adapt separates masters from automatons. IT is no different.

Companies that insist on some skillset they cannot find anywhere deserve the people who can fake their way through interviews.

SamMultikor on February 12, 2008 05:36 PM

as engineers you have to figure out what will keep your passion for tech alive. true engineers will figure it out whether it's open-source contribution if your in a large company without many exciting new tech coming your way. whatever it takes!! I don't care if your 23 or 63, if the fire to learn and keep learning is intact, that's the value-added commodity that your either born with or not. i've been in software engineering for 9 years, this will be my 10th, and electronics professionally prior to that for 15 years. i have a family; wife and two little kids, etc, plenty of reasons to say i don't have time for tech after 5 pm, but who i've always been keeps that fire for tech alive into the wee hours of the night every day. I keep learning; I'm having more fun with Silverlight after this post at now 10 PM to get up and do it again tomorrow at 6 AM.

point: regardless of experience, your value as an engineer will only be a result of time and passion your put into it. will you remember every nuance of everything you touch? NO! well, better stated, you shouldn't because then you set yourself up for something becoming a religion; I'm a JAVA programmer, I'm a C/C++/C#/PHP/RUBY/Iron Ruby,,, programmer. isn't part of the best software solution in using the right tool for the job? an employer or perspective employer should reach past the noise of experience or non experience and discover how much fire this person has for just tech and we engineers need to be able to demonstrate or convey it by whatever means even if it's knowing you just applied an elegant design pattern to a very troublesome piece of procedural legacy code, use it, convey it, build upon it and be proud of it..

RickCorbin on February 12, 2008 07:18 PM

> I might be wrong but in the UK you can no longer ask for x amount of years any more as it is seen as discriminating.

I think that you are wrong. In the UK you can't discriminate based on their age. You can justify hiring somebody based on what experience and qualifications they have - hence is perfectly valid to choose candidate x over candidate y based on how many years of experience they have in a particular field.

Nick on February 13, 2008 05:37 AM

Great discussion! A couple of points:

a) It's illegal to discriminate against candidates based on age. However, it's perfectly legal to "require" a certain number of years of "experience" for a given position. read into that what you may, but often companies are looking for a more stable candidate, believing that older == more dependable. this too, is a myth, but ... getting onto b)

b) managers, aka pointy hairs, have a penchant for seeking out candidates that are pleasant to be around, emotionally and fiscally stable, and have enough skill to at least fake it well enough to make them look good. call me a liar but you know it's true. the last thing most hiring managers want is to be embarrassed about a new hire. this is important to zone in on as an applicant. If you are a person of skill and integrity, it's easy to get your boss' job with no need to slander or to otherwise make them look bad. They will do it for you, eventually. Welcome to corporate america.

As a young person, remember that getting thru the door is the key. Your worth will play out eventually and become obvious to the ones that matter within a company. What you need as a young applicant is to create an environment of opportunity to attain that phase. Here are some simple tips:

* Appear mature: neither HR or hiring managers want high-maintenance employees. Your conduct and method of self-expression should support an impression that you will be reliable, dependable, and ... pleasant to interact with.

* Don't let your personality outshine your skill: i am a self-professed weirdo myself. but there are limits: you're interviewing to work in a professional capacity first. aspects of your own social integration within the environment are a key item for long-term success, but that comes with time. if i catered to every eccentricity in my personality i would be homeless. i keep a lid on it to survive, and to maintain an air of professionalism. drink the cool-aid, it's not that bad.

* Engage the hiring manager as much as possible about the problems they're wrestling with right now, and work towards convincing them that you are able to provide solutions to those problems. This will trump YOE -slash- acronym hell on any resume or job ad. If the hiring manager thinks that you can immediately apply yourself to a problem they're trying to solve, you'll be a leg up on the competition.

* Don't take the "years of experience" phrase too literally. In fact, if you think it's bogus - ignore it. I have for nearly 15 years now, and I'm batting over .500 for being hired while technically under-qualified by the YOE metric. Focus on your strengths in your resume and hope for the best.

To sum up: in my professional opinion, YOE is used primarily as a social filter and a way to discourage younger applicants who might need a bit of investment to become productive. This is horribly short-term thinking, and the companies that employ that attitude will die off as they deserve hiring only the pleasant ones. Let them. Move on and keep your eye on the prize of finding a company that's worth your time.

of course, I am a pointy hair amongst gods in this thread. caveats of circular logic, misguided assumptions, outright lies and grammatical mistakes all apply. if you're in seattle looking for a gig feel free to drop me a note :)

cheers

techorb -at- gmail.com on February 13, 2008 10:43 AM

Speaking to the idea that saying "I don't know but I could buy a book and get up to speed" is a good approach: Be careful with this. I have had people say that in such an offhand way that they come off as insulting.

While I'm sure they were trying to show that they are fast learners, I have had someone say that they could be up to speed over a weekend.

It came off to all the people in the room as if they were oversimplifying the work that we do and many were insulted.

JNH on February 13, 2008 11:17 AM

Learning is an important skill but experience in programming is important too. An experienced programmer can solve, say 100 common problems in no time but an unexperienced programmer, since he hasn't seen the problem before he needs time to fix it. I agree that a skilled programmer will solve the problem, but it will take time. But years of experience should not be seen as years of work experience. Specially off the work experience is more important as it is mostly for learning.

Cem Kalyoncu on February 14, 2008 01:00 AM

Two points directed toward two different replies. They're back in the comment history a bit, so forgive the need to scroll back.

@Louis - Developers are looking at specs and reference manuals all the time. You are confusing analysis/synthesis with knowledge. A programmer who never reaches for an reference manual or specification is a programmer who is in a knowledge steady-state. And I sincerely doubt they truly have the entirety of a platform memorized at the same time (I know of no one who does this). Admittedly, I forget useful modules and even obscure syntax of the languages I work with, requiring a trip back to the specs from time to time. But common syntax doesn't take long to pick up unless you approach learning each language as a vacuum. In that case, it might well take more than 6 months, as they will probably treat even the different parts of each language as a complete vacuum as well. So likely that the people you claim to want will only work with a subset of the language and never continuously seek out new and better ways to do things. It shows they wouldn't *thinking* about what they are doing; they'll just be regurgitating code the same way an English student might regurgitate Shakespeare without understanding any of the metaphorical meaning.

@Bill - Peter Norvig does not disagree with him. What Jeff is arguing about here is about forcing years of experience with particular technologies, languages, etc. You'll note in Norvig's article he recommends learning at least a half a dozen programming languages. You can't do that by focussing 95% of your time on one of them. But that's exactly what the YOE requirement lays down. It doesn't take long for someone to develop enough knowledge in most languages/frameworks/etc; if it did, what the hell use are they? What takes a long time is taking the knowledge from a particular framework or language, and analyzing it in the context of what other things you know. This is why both Norvig and ESR push for you to learn new languages. Each language will teach you new things about all the languages you use. They expand your theoretical understanding, which you can apply to any framework or language you might work on. At the end of proverbial 10 year journey, you'll probably know a dozen languages, and several frameworks for each; but the theory you've gained, the higher level understanding is what truly brings improvement.

Best,

Ed

Ed on February 14, 2008 04:17 PM

I remember looking for jobs right after Java came out (circa 1995).

One opening was for people with 3-5 years of Java programming.

Bill on February 15, 2008 02:31 AM

It is only partially true. No doubt good programming knowlege is required. Experience plays a vital role right from programming to delivery of the systems. let me redefine the role of software engineers. Software engineers not only do coding but interacts with team and customer, identify functional issues, think broadly about the functionally or visualize (not logical thinking). You can be a good programmer but experience teaches you to be an effective and cautious programmer.A Web or client server developer will not be effective in doing Embedding programming or algorithmic programming and vice versa. I know many guys who are good at raw programming but sucks at UI design and other things. You need to figure what customer needs and understand the customer are all essential parts of a software engineer. Experience teaches you such things. If you do not learn the customer needs inspite of having sound programming base we are as good as mud. Programming knowledge is important. This is the scenario.
Say i want to hire a programmer there are two candidates
1.who has less experience but has good programming skills say 7 out of 10.
2. who has more experience but he has 5 out of 10. i will take the second guy but if his scale is less than 5 then i will go for first one.

I know some people who are good at a specific language they will do wonders with that language but you cannot expect the same thing from other languages. People are different we cannot really conclude that a good programmer is better than experienced programmer and vice versa. On the contrary both are equally important. To me nothing goes waste if we really learn either from programming or other skills. But one thing is agreed we need to have a decent logic to become a better programmer.

kannan on February 15, 2008 12:22 PM

nice article,
check out more here..

http://UpdateStore.com

Candy

candy on February 17, 2008 05:25 PM

Now, try to explain all this to recruiters-who-use-grep, there are plenty of them all over the world.

Recruiters-who-use-grep are ridiculed for good reason by Joel on Software, see his post about "JavaSchools".

Bobik on February 28, 2008 11:28 AM

I completely agree with this article. I'm glad to say I'm a large exception to this. I'm a programmer (mostly web stuff) for a large corporation, currently have less than a year of experience, only a high school degree (working on Associate's), and was congratulated by my boss just today for the work I did on my last project. The only reason he wants me working towards a degree is because the customer won't like seeing somebody on a project without a degree, and he even seemed to disagree with the idea that the customer would discriminate on something such as degrees or years of experience.

Jeff on February 29, 2008 02:15 PM

Reminds when I was looking for web work in 1997 -- frequently encountering ads for positions requiring "5 years experience" with CGI or HTML. I guess they all wanted Tim Berners-Lee. (The punchline was the usual requirement of "BS in Computer Science" ... because marking up HTML is so programmatically demanding?)

More likely: these were non-software shops (like power utilities or magazine publishers) who had HR guidelines for all hires ... said guidelines (vintage 1988) probably had listings like "Information Systems Developer III" which was the best job description the HR drones could find for the job ... and the guidelines specified "Bachelor's degree (Computer Science) and 5 years experience with relevant technologies" ... thus the ads

Paul Souders on March 10, 2008 10:41 AM

No hire 'cause they don't want you in "The Club!" It's exclusive, and where everybody's supposed to be a demi-god, or a cup-bearer! Can you play by those rules, and master the secret handshake at time of interview? HR has its marching orders. Gotta' look at your small hiring problem in context. Big Picture is whole economy that's "trickle-down!" And so-called "job market" reflects exactly that circumstance. "Gatekeepers" - and by their peculiar psychology - are the key players. Can't change small hiring problem without repainting Big Picture, and with different subject matter, also. This isn't even "thinking outside the box". To solve entrenched "hiring problem", and in any industry necessary to decouple hugely co-dependent demi-gods from their always enabling cup-bearers. Certainly it can be done. Possibly at level of "physician heal thy self" and, however, which is idealistic. There must be "new rules", therefore, and where there is agreed on "overhaul" of entire economy, as regards the way everything "doesn't work". So your small IT hiring problems are non-unique, and you must see a greater need before you can fix those. All respondants who offer their anecdotes, and constructive criticisms, on this blog are half-way there, in my opinion. Draw your own conclusions about all the others.
Tom

Tom on March 13, 2008 03:38 PM

So, what's a new programmer supposed to do? According to:

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9066659

"In the 2006-'07 academic year, only 8,021 students graduated with computer science degrees from these schools -- the lowest number of graduates this decade."

The same site also has articles talking about how hot the market is for new programmers. Yet, my son, a recent computer science graduate, is having a devil of a time finding entry-level jobs to e