What if Cars Were Rented Like We Hire Programmers?
Wednesday, January 16, 2013 at 9:30AM 
Imagine if you will that car rental agencies rented cars like programmers are hired at many software companies...
Agency : So sorry you had to wait in the reception area for an hour. Nobody knew you were coming to today. I finally found 8 people to interview before we can rent you a car. If we like you you may have to come in for another round of interviews tomorrow because our manager isn't in today. I didn't have a chance to read your application, so I'll just start with a question. What car do you drive today?
Applicant : I drive a 2008 Subaru.
Agency : That's a shame. We don't have a Subaru to rent you.
Applicant : That's OK. Any car will do.
Agency : No, we can only take on clients who know how to drive the cars we stock. We find it's safer that way. There are so many little differences between cars, we just don't want to take a chance.
Applicant : I have a drivers license. I know how to drive. I've been driving all kinds of cars for 15 years, I am sure I can adapt.
Agency : We appreciate your position, but we can only take exact matches. Otherwise, how could we ever know if you could drive one of our cars?
Applicant : Oookay. I've driven a Taurus before. You probably rent those, don't you?
Agency : Indeed we do. What year did you drive?
Applicant : It was 2009...but I don't see how that ma...
Agency : Oh sorry, we use the 2012 model. We can't possibly let you drive a later model.
Applicant : But, but they aren't that different. Surely if I can drive a 2009 I can drive a 2012?
Agency : Sorry, sir. Our requirements clearly spell out that you must be able to drive a 2012 model.
Applicant : I've driven a 2010 Escort. Do you rent those?
Agency : Ah, excellent, you are in luck. We have one in stock.
Applicant : Great. Can I rent it?
Agency : No, no, no. We have to go through our structured interview process now. I'll go try and find the first person.
Interviewer#1 : Sorry I was late, I was in a meeting I couldn't get out of. I like to ask technical questions to get a feel for your competency as a driver. What color has the middle wire feeding into the distributer cap?
Applicant : What? What does that have to do with driving?
Interviewer#1 : If you have experience as you say driving an Escort then you would certainly know the color of that wire.
Applicant : I know how to drive. Why don't you ask me questions about driving?
Interviewer#1 : I assure you I am. Are you this way with everyone you rent a car from? Nevertheless, I'll ask another question. What is the total weight of an Escort just after it has been washed, but before it has been dried?
Applicant : Hand dried or blow dried?
Interviewer#1 : It doesn't matter.
Applicant : I know.
Interviewer#1 : Well then. Thank you very much. We are done. I'll find the next person.
Interviewer#2 : Sorry I am late. They never told me I had an interview today. I see on your application that you've driven a lot of different cars and you have a lot of experience driving. So, how would you fit a SUV through the eye of a needle?
Applicant : What? What does that have to do with driving? I know how to drive! Please ask me some #$*&! questions about driving!
Interviewer#2 : Sorry, I have a meeting to go to. Let me search for the next interviewer.
Interviewer#3 : Shoot, we're going to have to find another conference room, another meeting is scheduled here. Somebody forgot to reserve a room for the interview. Oh, here we go, nobody uses this room (for obvious reasons). So, do you have an exact itinerary of where you will drive and park?
Applicant : Not really. I just thought I would drive around and explore. I know I plan on going to the tech museum downtown.
Interviewer#3 : I believe that's on first street. That's good. It's on our approved list of streets. Have you ever driven first street before?
Applicant : Hm, let me think, no, don't think so. But I am sure I can find it. One city street is pretty much like any other, so it shouldn't be a problem.
Applicant : Oh I am sorry, our policy is you can only rent you a car if you've driven on an approved street that you've driven on before for more than 10 years. We just can't take a chance that you won't be able to drive on new and different streets.
Applicant : I don't believe this. I know how to drive, I have a long history of successful driving in many different cities in many different situations. I can navigate, diagnose and fix minor problems, ask for help, find out anything I need to find out, and learn anything I need to learn. I know everything I need to know to rent this car because I've done it successfully a hundred times before!
Interviewer#3 : How excellent for you. But it's policy. We need the exact experience to be sure. No exceptions. You may be very skilled, but you don't have the specific skills we require...that will be all.
Agency : Sorry, but interviewers #4 - #8 were called to an emergency off site with upper management to reformulate policies on policy formation.
Applicant : Bows head forward, looks at the water spot on the desk, and sighs.
Agency : We might or might not let you know in a couple of weeks if we'll rent you a car.
Applicant : But I need a car now!
Agency : Very well. It was close, not everyone wanted to rent you a car, but we will rent you a 2010 Escort. How much did you pay for your last rental car?
Applicant : I don't see how that matters. What are you charging?
Agency : We like to know what you paid before so you get a fair rate.
Applicant : I paid market rates.
Agency : Sorry, we must know how much...
Applicant : Gets up and walks out of the interview room in total frustration, wondering how anyone ever rented a car at this agency.
Interview chorus: Just as well, we really only want young rock star drivers that are in the top .000001% of their class...
Related Articles
Reader Comments (45)
James is absolutely right. "There's no good talent to fill all the technical jobs" is a lie that everyone mindlessly repeats to sound smart, when really they have no idea.
You sound like one of those Devs who got into CS for the money. At work we call you guys "15 pieces of flair" because you only learn the bare minimum. Go into management already.
Leave it to a bunch of programmers to nit pick a car analogy.
"Different languages have different syntax that is all."
This couldn't be farther from the truth. You have generic languages, functional languages, procedural languages, OO languages, general purpose languages, multi-paradigm languages, and probably a few more I've never heard of. Also, most languages from the same group have different purposes, and therefore different strengths and weaknesses.
Knowing multiple languages is necessary to be a good programmer, but it doesn't make you one. A good programmer picks the best languages for their problem, and can pick up new languages quickly.
Wow, reading these comments reminds me of why software programmers are so unpleasant to be around.
Hilarious! And very true.
The reason number one why I'm actively looking for an exit from development. I went to programming because I love building things and seeing them running. And I certainly didn't join to be solving brain puzzles and being treated like a complete idiot, more so with every coming year. Now I'm over 30, I'm treated like an old fart who has the audacity no to be willing to work for food and 12 hours/day. I even tried going abroad. Didn't help. This perverse subculture has penetrated everywhere in every country wherever you go.
Btw, numbers of student applications in IT departments have been dropping for some years now (at least throughout Europe). I think newer generations are just wiser to stay clear of this minefield. And those who graduate these days go independent from the day one and never bother ever making appearance on the "job market".
You're in IT and you're an employed worker? You're screwed. Oh boy, you're massively screwed.
"Multilanguage programmers are bad programmers... Thats a fact." - that's BS.
Multilanguage programmers will most likely have a better understanding of what functional programming, OOP, structured programming, manual memory management and garbage collection mean, and how they work. Their knowledge of several platforms and environments gives them access to a much wider array of predefined solutions to various problems, solutions of which any programmer doing the same thing over and over again each day doesn't even know they exist. They have most likely encountered and solved a much wider array of problems than any programmer specialized in just a single technology.
In short, multilanguage programmers rock, because whatever comes their way they are able to place it and to reason about it in a wider context, regardless of the programming language(s) involved. Single language programmers suck. Big time. Because whatever comes their way they are only able to judge it by their narrow and simple-minded understanding of a thin slice of all things IT.
More fool you; exposure is not skill.
What you should focus on is abstract skills like problem solving, team play, ability to learn and cultural fit and then narrow the focus on specific tooling / algorithm experience.
Some fields require specialist domain knowledge too which would allow quick exclusion if it can't easily be learned but excluding based on language / tooling experience just makes you bad at your job.
A good coder is very much like a good author:
1. Spelling/Syntax
Does a good author need to know how to spell? With spell checkers and proof readers, not really. Does a good coder need to know all the details of all of the syntax of their language? With on-line references and Google, not really
2. Grammar/Design
Does a good author need to know grammar? Yes, but they don't need to know all of the technical specifics of a languages grammar. Does a good coder need to know design principles? Yes, but they don't need to have all of the technical details stored in their heads.
3. Writing
Is an author with good spelling and grammar going to write a best selling book? Unfortunately, those skills don't automatically result in good books. A good author knows how to weave a story that is interesting to their readers. Is a software developer with good syntax and design knowledge going to write great code? Software, like novels, is an art form, where good fundamentals don't automatically result in good art.
What this article is trying to point out is that many interviewers for software developers try to gauge the capability of the artist by asking obscure questions about their mechanics. You can only judge the skill of an author by knowing what a good book is and then reading their material. Same with software developers. This is why having a software portfolio on something like GitHub is becoming such a valuable reference tool for candidates.
The sad fact is that most interviewers don't know what good code is and therefore wouldn't know a good developer if they hit them between the eyes.
Rick - The issue in actual software development interviews isn't so much "hiring a PHP programmer to do C development," it's more "ruling out the .Net developer because he's only done up to .Net 4.0 and we're on .Net 4.5", or "you need 5 years experience of Python AND Java AND C# AND PHP, even though we're really just a PHP/Python shop with a couple of items that really only require working knowledge of Java/C#", or, even worse, the "must have 5 years of .Net 4.5 experience" (hint - for those types of requirements, you either need to have been on the team that actually built said version, and/or have a working time machine).
This really starts getting into problems when you start getting into languages that have multiple frameworks for the same language, such the Zend vs CodeIgniter vs Cake for PHP frameworks, or MooTools vs jQuery for JavaScript. In the early stages of the interview process, it's often non-technical (or "I think I'm technical, but I'm really not") people that do the initial screening processes, and rule out qualified people, because they lack the keywords and exact pair-value matches, even if their experience is completely transferrable.
The car analogy actually isn't far off, especially when you're talking about nitpicking at the framework level of a language (Beetle vs Prius or 2008 model vs 2010), or ruling people out because they don't have extensive knowledge of a language that's only somewhat actually used in your company.
Hate to tell you pal, but I'm not a programmer and every interview I've been to in the last 20 years has been like this.
To the"hiring manager"
"The interview process is designed to keep people out, not to bring people in. You want to bring in one person, but you have 200 applicants. The entire point of the process is to kick out at least 199 people. If I'm hiring for a C developer and you've only ever professionally and recently written PHP, but the guy next to you has been writing C it's very easy to work out how to cull another applicant and work towards my target of 199. Even if you've both been writing C for exactly the same amount of time but he's used the same libraries or frameworks that we use, you're going to be culled."
If you can't write a proper job description, you deserve all of the excess job applicants. Learn how to be specific in what you require, and if you are, then the point is moot.
For large companies that have no interest in innovation, other than lip service, and only have an interest in incremental increases in productivity, then staunch rigidity in corporate architecture is the mantra that makes management happy.
For small, innovative, paradigm shifting companies, new ideas, new ways of thinking are the only ways to survive and flourish.
I have worked in both Fortune 250 corporations, which had the same view as "hiring manager", and they are now in the Fortune 1,000, and I have chosen to work in innovative technology companies where we are out-inventing our major corporate competitors. By the way, we are very profitable with no investment money and we specifically look for employees that have experience in many technologies/capabilities because each problem requires different skills and solutions.
And I am intimately involved in the hiring process of our technologists, even though my primary job functions are in other areas.
Otherwise, the article itself is amusing, not only for computer programmers, but for anyone in technology. I've had the pleasure of going through a similar process, and as much as I hate to admit it, a couple of interviews I was involved with turned out this way. Sorry to say, understaffed, things just happen this way sometimes.
Multi language programmers are not bad
the programming doesn't depends on the language its depends on the solution we had and we can implement it any language
first we need to know the algorithm and we can write it in any language
This post is brilliant. Having been through the interview process for over a year recently before finding my current position, I can deeply relate.
Just the last point I wouldn't agree with - companies normally don't see high academics as related to being a "rock star programmer". I've pretty much gotten straight A's in all my university studies but it's made no difference when applying for jobs. I think most managers would rather hire an unintelligent guy with 5 years experience in driving a 2005 Silver Prius than an intelligent guy that could easily figure out how to drive any car quickly (not that intelligence and academic performance are always related obviously, but the simple fact is that you can't get straight A's in engineering or computer science if you're stupid).
IMHO the most valuable programmers in an organisation are the ones that are able to solve difficult problems, rather than the ones who know specific technologies. If you have a good base in object oriented languages and frameworks, you can easily learn new ones (the underlying principles are very similar). Try teach someone how to get a badly designed system to perform at 50 times its current rate when thats the minimum customer requirement, or isolate a non-reproducable bug. That takes an ability that is partly genetic and partly learned through years of hard-earned experience.
Learning to program is in many ways like learning to dance. I started doing Salsa dancing a few years back (mainly to meet girls - its how I met my wife :-) Another guy started at almost the same time as me, but he had many years of competitive Latin dancing experience (completely different styles to Salsa though). Within 2 years he was good enough to start his own Salsa school, while I was still tripping over my feet. I did find that I could learn completely new moves a lot easier after a couple of years than when I started out though. So with experience comes the ability to build on what you've learned and learn related concepts a lot more quickly. I think this applies to most types of learning.
Lastly, in response to the comment about "... you were a plastic surgeon and we need a brain surgeon, I am sure they are pretty much the same. You can certainly adapt!" I'd say the spirit of the article was more like this "Sorry, but you've done all your brain surgery using stainless steel scalpel blades, while in our hospital we only use titanium blades. You couldn't possibly adapt!". That said, I do acknowledge that some programming paradigms take time to master (OOP vs. structured programming for example).
The point isn't the hiring criteria. It's about whether the recruiters really know what these criteria mean. If they do, everything is fine; otherwise it would have been better for the employer to write a simple script to filter the resumes rather than spending money hiring someone to do so.
I heard Bill Clinton speak about job creation a few years back, and he said that you need a new industry every ten or so years because that's how long it takes job qualifications to become set in stone. Once that happens, it's almost impossible for creative people to switch careers.
And why should it be hard for creative people to switch careers? Whom does it benefit? Well, a company looking for a "rock star" has got to be in trouble, and that means that the technical management isn't doing their job. So one reason these narrow requirements are written is to protect the middle tier of management - if they really hired for creativity, they'd be bringing in competition for project leadership.
This strategy is reinforced by the HR legalism, which means that you have to have "objective" criteria for hiring.
The whole festering loop is closed by the tendency of CS professionals to invest their careers in technologies, rather than in the creation of corporate assets. Working with the latest and greatest technologies is what we consider to be our meal ticket. If it takes longer to create a solution than it takes technologies to shift, we're apt to start looking for another position before the job is done.
That's the question that I think is missing: "Last time you got into an accident, how serious was it? How did you handle the situation?"
This analogy works better for me: http://www.jasonbock.net/jb/Default.aspx?blog=entry.7c334037d1a9437d9fa6506e2f35eaac
I agree it's a good analogy Brad, I hadn't read it before writing my article awhile back. I think of mine as more of an allegory rather than an analogy as I'm actively trying to guide the reader to an inevitable conclusion :-)
My article is based on many years of experience as a consultant and employee in silicon valley, It would be a sorry interview indeed that embodied all these problems, but they have all happened, and worse. As a consultant I've been in a lot of interviews. And I've also given hundreds and hundreds of interviews too. So I've inflicted these problems on others and I've also been the victim. Part of it is just what happens in a busy company, but it kind of sucks for everyone. Maybe with a little reflection the system can improve a little.
(confessions first: I interview for a large software company, and program).
The multilanguage thing is irrelevant. I know some coders who are amazingly good at one or two languages (like C#+javascript), which would be useful to an MVC ASP.NET app, for example. I also know some coders who know TONS of languages (stretching back to assembly 6502, COBOL on up to F#). They could create a new language and write compilers without looking up anything online.
When I interview (and others I know), ask to solve a challenge in any language of the applicant's choice. They can also inquire on some basics that would take one a few seconds to look up online (as if they had a job and were at a computer). That's where it starts to show ability: elegance and simplicity (+futureproofing and testability) vs. code (if's ands and whiles) +code+code+code+more code. Number of languages rarely applies to simply solving.
Having said that, there have been a few interviews in the past which were far too specific to be credible (not where I work).
Thanks.
I think the comparison is great, but the story is different IMHO.
In the real world, the worse driver in the world can rent every cars he wants, including the best of them. The car renter wont see any problem if the customer pays the price it costs. The most important for him is that he rents the car a maximum time at the higher cost.
The more the driver is bad, the more the car has to drive itself. Not all cars could drive themselves.
Then, when the driver brings the car back, it could be a better car than before, or it could be scratched or wrecked, depending how good or bad the driver was.
In the last case, many rental companies does not care about it and instead of trying to repair it, it trash the car saying "it was a bad car, finally" regardless how good it worked.
Too many drivers believe their as good, so too many cars.