Inflection Research

Over the last three years I have been responsible for hiring technical people for part or all of our company. Due to turnover and new positions we are almost always hiring. I’m consistently amazed at the poor quality of candidates in the marketplace. We use technical recruiters and don’t interview most of the candidates the recruiters submit. Yet we still only make an offer to less than 10% of the candidates we interview; fortunately the vast majority of candidates accept the offer.

We build web applications to manage the operations of transportation and logistics companies. While there are challenges the solutions we build are far from rocket science. Most of these applications are simple CRUD (create, read, update, delete) apps where the general premise of the application is a search box (or initial report to drill down from) a resultant grid to view and/or update; and potentially the ability to drill down to more granular levels where the CRUD pattern is repeated.

Most of the people we hire are ASP.Net and SQL Server programmers. Most of the candidates cannot explain how to read the value from a simple text box after the page has been posted back without using view state. Many say it cannot be done; to which I usually respond “How did web apps work before .Net was created?”…at that point I typically get a lengthy silence. Stated another way I use various questions to ensure the candidate understand the request/response, stateless nature of web applications and most candidates don’t understand this paradigm.

The basics seem to be lost on most programmers (or the ones looking for jobs). Many programmers just know how to drag and drop controls onto an ASPX page in Visual Studio and how to set the properties of those controls. The problem is when issues arise, optimization is required, or unique features are requested these programmers are of little usefulness. The problem doesn’t seem isolated to web programmers as many database programmers, with years of experience, cannot explain the difference between a clustered and non-clustered index.

Most candidates show little intellectual curiosity which is especially demonstrated when we ask basic problem solving or case study questions. Now I realize my company is no Google and doesn’t get many Google quality candidates, but the knowledge and expertise candidates’ exhibit has not improved in five years. If anything it appears to have generally declined. This is surprising considering web development innovation has stabilized after rapid progress until roughly 2002 – 2003. While browsers and networks have improved the major web application technologies and architectures (such as AJAX, JSON, CSS, REST, SOA, etc) have existed for over five years. Since 2002 -2003 much of the progress appears to be on the infrastructure side, but that is another discussion.

Interviewing and finding good people is always difficult, but it in the IT world it is as difficult as it has ever been. Below I’ve outlined the criteria we use to evaluate candidates. It is evenly split between straightforward technical abilities and behavior/aptitude skills. While interviewing will always be subjective it is good to quantify the process as much as possible.

We rate a candidate’s ability on a scale of 0 to 5; with 5 being the best. For junior level candidates we are looking for someone with good problem solving, attitude and communication skills and minimal technical skills. Mid-Level and senior candidates must also possess a certain level of technical skills. Our conclusion of a candidate’s experience level is based on the ratings we assign to each category.  Only a senior programmer is required to have a specified level of understanding of the three technology domains we identify. 

Our opinion is that a certain level of the softer skills (problem solving, attitude, and communication) is required at every level.  The main difference between junior-level and mid-level is technical experience.  The main difference between mid-level and senior-level is technical experience and problem solving ability.

Ultimately we look for a person with the required aptitude who has a good attitude. If someone has built a strong expertise in one area (such as ASP.Net or T-SQL) than they will be able to build expertise in the other technologies we use. I’ve discussed the problem of finding good technical people with friends in other companies and they appear to be having the same problem. I wonder how widespread an issue this is and how much it will affect IT organizations structure in the near future.