Jobs Requirements: Hire For Attitude, Train For Skill

Friday, December 3rd 2010

Yesterday I posted about people who are trying to hire great talent inverting their list of requirements, and inevitably a friend responded with “Yeah that’s fine, but what would you look for in a new candidate?”

Simple. Apply the philosophy that Southwest Airlines use when hiring their flight attendants. “Hire for attitude, train for skill.”

Just to recap, here’s the list of job requirements pulled directly from a Craigslist ad.

PHP & Object Oriented PHP (MUST have a minimum of 2 years experience)

Python/Zope Framework (MUST have a minimum of 2 years experience)

AJAX (MUST have a minimum of 2 years experience) Subversion experience a plus

CMS Templating – Joomla! and Plone (MUST have a minimum of 2 years experience)

Working knowledge of Relational Database Concepts

Ability to design and extend database schemas to meet new client requirements

Ability to write clean, reusable, and well-documented code

Experience administering LAMP environments

Strong knowledge of XHTML / Web standards

Strong knowledge of XSLT

Ability to re-factor open source code

Experience with e-commerce platform and CMS integration

If you’re attempting to solve one particular problem, fine, focus on the technical, hire a contractor or consultant to do the work for you, then get rid of them. If all you have is a leaky toilet, hire a plumber for an hour. The plumber doesn’t have to get your vision. The plumber doesn’t need good hygiene. The plumber doesn’t need to be overly punctual. You don’t have to worry whether they’d be good to have lunch with once in a while. You just need your leaky toilet fixed.

But if you want great talent and you want that talent to stick around, this is the list of requirements I would post.

Good grasp of the popular design patterns that are used on the web and when each one is appropriate, e.g. MVC vs MVVM.

Lots of experience administering a LAMP environment and all of the pitfalls that come with it.

Lots of experience with working with any version control system, even if you only work on solo projects! (Especially if you work on solo projects!) And if you don’t, start using it now with Mercurial, SVN, Perforce or Kiln which you can all get for free for small projects.

Lots of experience using any task tracking, bug tracking or collaborative project system. And if you don’t have any experience, go sign up for free BaseCamp and FogBugz accounts immediately.

The ability to spelunk through poorly documented and badly written open source frameworks, libraries and SDKs to make sure your project ships out the door.

Good familiarity with at least two imperative programming languages that looks like C++ or Python, so that would be Python, C++, JavaScript, PHP, Objective-C, C#, and so on.

Good familiarity with any declarative programming language such as HTML, XML, CSS, etc

Anybody who has been developing software for any length of time, if they are any good, and know more than two or three programming languages realises that the language, the syntactic sugar that defines the differences between Pascal, Modula-II, Lisp, C++, Objective-C, C#, PHP, Python, have a massive amount of concepts in common and the language syntax itself is mostly irrelevant. Once you understand a few foundational languages, you understand all languages.

These are what I look for, listed in descending order of importance, when considering who to hire for a development project:

The first three in the list I consider vitally important for any new hire, and this is coming from a software engineer who has spent three decades writing reams of code almost every single day. The one thing I have realised after so long developing software is that having skill in a particular programming language is irrelevant to the actual developing of good software.

The problem of hiring for knowledge of a particular programming language or whether you can state the four tenets of object-oriented programming is that it’s easy to measure for.

And if it’s easy to measure, the life of an interviewer is easy. “Yeah, he’s a great hire, he knew how solve the Fibonacci problem using both recursive and iterative solutions.”

The problem with this approach is that it ignores that any potential that the employee might well be utterly toxic to your organization and is thoroughly disinterested in your “vision.” You might try and discern the potential hire’s attitude to your organization and future direction, along with measuring their technical ability during an interview, but guess what? People lie!

“Oh yeah, that’s totally radical, you’re going to make millions off of trademarking dates in the calendar and then selling the rights to interested people. I am so totally on board. When can I take my first vacation?”

When you’re conducting that next interview, stop and ask yourself this, “could the candidate look this up on wikipedia in less than 5 seconds and give a canned answer?” If the answer is a definite “yes,” don’t even bother with the question, find something else to talk about.

The best hires I’ve ever made over my entire career did not revolve around having the candidate write source code on the whiteboard, giving me canned answers to various aspects of object-oriented programming or rattling off particulars about a framework or SDK.

I still get candidates to write code on the whiteboard, in whatever language they feel most comfortable using, even if it isn’t the one they will eventually be using on the job. I use whiteboard code to see if a programmer can actually understand requirements, listen to the client, find and fix bugs – watch your interview candidate get totally flustered when you say “I can see two bugs in that code, can you identify and fix them for me?” even if there are no bugs in the code – and explain what their code does.

Here’s a useful tip, you write some messy code on the whiteboard, pretending to be a junior programmer and you make sure to create a horrible solution. Once you’re done, ask the interview candidate to refactor the code and clean it up, have them explain why the your solution is sub-optimal and theirs is better. Don’t worry about whether they can give you the stock answer to Big-O notation, worry about whether they understand the ramifications of their solution in terms of memory, run-time and latency (the essential essence of Big-O) rather than n log m or n*m. Do they really understand the trade-offs they are making?

One of my favourite “write source to solve the following problems” questions is “write a function that will reverse the words in a string.” Good software developers will stop and find out more information. Bad programmers will charge ahead and solve the problem. Remember, the interview candidate is under pressure to perform in a reasonably stressful situation. Who wouldn’t immediately charge in and solve the problem to show how good they are? The question I posed may seem simple, but there are a number of wrinkles, and it is very easy to solve the wrong problem.

Back to programming languages and frameworks and operating systems and SDKs or as software engineers refer to it, domain specific knowledge. I’m not exactly the sharpest knife in the drawer but even I am capable of completely understanding the syntax and idioms of a new programming language, such as C# or Ruby inside of a few hours, the particulars of a large framework, like .NET or PHP, in a day or two, and being a wizard with the inner source code workings of a new software application in less than a week.

When you’re looking for your next great hire, don’t worry about knowledge of the syntactic sugar of a programming language. If the guy is a wizard at Java and Python then he will be able to grasp how to write PHP or C# in less than a day. Hire for what the guy can do for you long-term, not what he can do for you today.