Hiring for Performance vs. Skills

Introduction

This article explains exactly how to hire a developer or an architect based on performance, and not just skills. This should dramatically improve your development team's performance.

Background

The standard developer / architect interview usually consists of just a few memorization questions, then usually whiteboarding code. This is an alternative that should allow the interviewer to delve deeper into the candidates ability to perform under pressure using their existing skillset.

By Chris Johnson @ intrin.sc

Hiring for Performance vs. Skills

This article is essentially part 2 of my last award winning article on 'Hiring a Great programmer' (see http://www.codeproject.com/Articles/814978/Hiring-a-Great-Programmer). This time, I want to delve into the non-technical side of hiring a developer (or for almost any position that is critical to your organization's success.)

Though most managers understand the importance of hiring wisely, many don't know how to do it. In the end, they often choose prospective employees based on gut reactions. While this strategy sometimes works, more often it leaves managers with ineffectual or unmotivated employees who drag the organization down. Decisions based on emotions, biases, personalities, or stereotypes often reveal themselves as bad decisions in hindsight. The key to dodging this pitfall is to train yourself to base all of your hiring decisions on reason, not emotion.

I have worked as a consultant for many years, and have been through my share of interviews, both good and bad. I recently had an interview at a software company that was looking to hire a senior consultant for an important project. This was a boardroom type interview with 4 senior managers and technical people interviewing me. So, this would normally make the interviewee feel at least a little bit of pressure to perform. One of the questions was "If we have 10 people in a room, what will be the maximum number of handshakes that would potentially occur" (i.e., the number of handshakes between each person that will be unique.) I immediately thought that there would be a formula for this, and I should immediately come up with an answer, but after thinking about it for a few seconds, realized there isn't one that I could think of off the top of my head, and proceeded to calculate this. The number of people is essentially irrelevant, so if you have n people, the number of unique handshakes is (n-1)*(n)/2 = 3. I calculated it for 3 people, then realized there was a formula and applied it to 10 people. So, I did get the correct answer. But, since I was under pressure, it took me longer than normal (which I'm sure applies to everyone.) But, the interviewer didn't seem to like my answer, probably because I took a whole 1 1/2 minutes to answer. He stated there was another person he interviewed that got the answer immediately, only because he memorized that question and answer in his head. I was a bit shocked that he preferred people who memorize things, rather than those who start with no knowledge about a particular problem, and still manage to come up with the right answer. I realized that this manager was looking for people who memorized things rather than solve real world problems. I also realized that this problem would never be something which would ever need to be solved in the real world, and it almost never applies to any I.T. related job. This manager was clearly hiring for skills vs. performance as even though my answer was right, he was expecting memorization. Normally, the education you receive, and skills you acquire through experience, only account for about 20 to 30% of the job or new project you are working on. High performance on the job is much more important that skills and memorization, which may or may not ever be used in any particular job. Critical thinking, and the ability to perform under pressure is much more important than almost any skill anyone could acquire.

But, sadly, most managers never realize this, and constantly hire the wrong people. I've seen new people hired, that struggle with the most basic tasks such as setting up a development environment or troubleshooting a malfunctioning program. I recall a time that a Web Service (Fancy name for a program that serves information over a network or the World Wide Web) was coded by a developer who had left the company a few months back. This other ‘veteran’ developer tasked with getting the existing code up and running, who had been with the company for about 10 years struggled to get the Web Service setup and running on their development machine. After about 2 weeks of trying, they gave up and asked me to help. After about 3 minutes, I saw that in the 'IIS' configuration, there was an ID that belonged to the old developer, and I asked the new developer to simply change it to their ID, and see if this worked. I had almost no experience with Web Services at the time, but I knew that you can't have an ID that no longer existed! They convinced me that I was wrong (without even trying out my suggestion), and so, I went back to the other project I was working on. Another week later, they insisted that I drop what I was doing and install this Web Service on my development machine and get it running as quickly as possible, because it was absolutely critical to get it working. So, I installed it on my machine, and also read through the documentation (which unfortunately was written in broken English, and was extremely technical.) At this time, the other developer had me convinced that the ID wasn't the problem, so I tried in vain changing configuration files, and tracing through the code, but to no avail. I thought however, that I should give my ID theory a try, and after changing the 'IIS' configuration to use my ID, it worked immediately!! So, my point here is that hiring for performance is absolutely critical and will save your company hundreds of thousands of dollars if not millions of dollars in labour costs if you simply hire the RIGHT person. That is the person who thinks correctly, and never assumes anything. In this case, the other 'developer' wasted 3 weeks of the company's time, and no matter what their salary was (I'm assuming it was about average for a developer, as this person had been a developer for over 20 years), hiring me at about 4 times their salary would still save the company a huge amount of money. To put it in a $ perspective (with hypothetical numbers):

Cost breakdown:

Senior 'developer' at $50 / hour (8 hrs. / day) works on problem for 3 weeks. Cost: $6,000

Chris at $200 / hr (Of course I don't make that much, but there is a very strong argument that I should!) takes approximately 10 minutes to install and get the project running.                     Cost:  $33.33

Total Savings:                                                                                                              $5,966.67

Of course, these figures don't include appropriate taxes, and let’s not forget all the benefits paid to an employee these days. But that proves my point beyond a shadow of a doubt! I saved the company thousands of dollars. And, remember, that this actually happened, and I haven't made this up, believe it or not! And, what would happen if I wasn't there at the time? Since there was no one in the department that knew anything about Web Services, that developer would continue working on the problem for who knows how long! But, I was surprised to see in that case that the manager didn't seem to care, because the employee worked for a lot cheaper than I did. They still didn't get the fact that hiring the wrong person can cost the company a huge amount of money. It is almost irrelevant what the ‘right’ person's salary is, as they will still cost the company LESS than the wrong person at a very low salary! I've encountered this situation over and over again, in every single company that I consult with, and have gone over this issue with some of the managers who I've worked with. However, one of the selling points for hiring an employee at a lower salary, is that the manager who supervises the person doing the hiring will be pleased that they 'saved' the company so much money by doing so. So, that manager who does the hiring may get more of a bonus or some other incentive to hire people at as low a salary as possible. I do see this trend happening in North America (and most likely around the world). It is one of the reasons I became a consultant, as I can charge the higher fees. But, of course the downside is that we have to complete our projects on time, while at the same time helping out other 'developers' like this for up to several hours per day. So, you end up working harder, and longer than the rest of the team.

One other thing to avoid when interviewing the person, is to simply give the standard memorization and coding tests. They should be put through a practical test that is not based on skills or memorization alone. One real world challenge that I went through at a past project involved a fairly substantial change to a part of the program and the underlying code and database structure. As you can see below, this was for a large power company that was creating a new system for the entire Province. A brief overview of the problem is as follows:

Existing scenario:

1. Hierarchy map of geographic locations in a province. You can view this as a tree as follows:

   

   Figure 1: Hierarchy Map

2. ElectricalGroups table is a self-referencing table where the ‘ParentElectricalGroupId’ points to the Id of the table itself:

   

   Figure 2: EG (Electrical Group) table

3. Entity table (could be Substations (as shown in figure 1.), Generating units, etc. or any future entity that is related to Electrical Groups). This table had an ‘ElectricalGroupID’ field which of course pointed directly to the Electrical Group record for this particular entity, which is on the 3^rd ‘level’ of the tree (or 4^th level in some cases):

   

   Figure 3: Substations table

4. Output was a 2d Hierarchy map on the entity’s update screen, like so: B.C. -->Lower Mainland + Vancouver Island --> Victoria --> Downtown Substation.

5. Code to traverse tree is fairly simple. You have the child E.G., from the Entity table (substations in this case), so your code would just look at the ‘ParentElectricalGroupId’ field in the Electrical Group table recursively, until the ‘ParentElectricalGroupId’ field is NULL, then reverse the list of Electrical Group records, and display on screen.

New Scenario:

1. Instead of one Hierarchy map, there can be any number of Electrical Group Hierarchy maps.
2. To simplify the process, we need to add a few screens to the system so that the user can select any existing Map and copy it, and edit it visually, so they can remove any nodes they want, and change the text if needed. This would look similar to Figure 1, but with of course the correct icons!
3. On each entity screen, there would now be a potentially unlimited number of maps to be displayed. This was to be accomplished by a JQuery plugin that the developer would specify the map type ID for. You can then place as many JQuery plug-ins on the entity screen, as there are maps.

So, how exactly was this all accomplished, you ask? It wouldn’t be that difficult for someone who thinks clearly, and doesn’t think about coding before understanding the high level design. I thought that surely most developers think like I do, and come up with a high level design BEFORE looking at code. But, unfortunately, I was wrong….

The Solution

1. Add a map table. This would have a Map ID, and a ‘rootElectricalGroupID’ which would just point to the topmost ElectricalGroupID in the ElectricalGroup table as above. (Leave the existing Electrical Group table as is):

   

   Figure 4: Map Table

2. Add an Entity to Electrical group link table with an EG (Electrical Group) ID, and an Entity ID and an Entity type (or you can have one link table per entity type.):

   

   Figure 5: SubstationToEG table.

3. Create a new screen to allow the user to visually assign an entity to an Electrical Group somewhere on the tree. This was already done (although somewhat poorly by a previous developer), but now the Entity link table records have to be updated.

4. Remove the ‘ElectricalGroupID’ field from the entity table, so you would have to use the new Entity to Electrical Group link table instead.
5. Most importantly, (AFTER understanding all of the above database changes), to display the 2d hierarchy map, you can traverse the ‘tree’ using 2 different methods. And, each method would provide a different level of efficiency depending on how many Electrical Group Maps there are in the system.
   1. To display the hierarchy map at the quickest speed in a system with a small number of Maps, you would start from the existing EntitytoElectricalGroup table record, as that ID would be stored in the Entity table itself. You would traverse the ‘tree’ which is just the Electrical Group table, in the same method as before, since you know the ‘ParentElectricalGroupID’, you would recursively move through the ElectricalGroup records until the ‘ParentElectricalGroupID’ is NULL. However, this is where it gets interesting and this is where 99% of developers make mistakes. Most developers would think that you would be done at this point. I am saying this because on the team that I worked on, the ‘architect’ who came up with most of the code for the existing system, insisted that the traversing was done at this point, and proceeded to write some C# code, which is another big mistake. I then proceeded to have another conversation with a 3^rd developer who came up with the same conclusion. I kept trying to explain to both developers that you have to understand everything at a high level, well enough, BEFORE coding. But, my words went in one ear and out the other. So, to continue on with the solution, now you have traversed the ‘tree’ once from the bottom to the top. So you have the parent Electrical Group ID. But obviously, since there are now multiple maps, you cannot be certain that the root ID you have corresponds to the correct Electrical Group map, right? So, then you look at the map table, and if the correct Map record matches the root ElectricalGroupID that you just retrieved you are then done, and you can display the 2d map. If it doesn’t match, then you must start again, as there may be more than one record in the Entity to Electrical group link table that matches your entity ID. So, simply repeat this process with the remaining Entity To Electrical Group link table records, until you have found the correct root EG ID in the Electrical Group table, and then display the 2d map.
   2. To display the hierarchy map at the quickest speed in a system with a large number of Maps (‘Large’ in this case is of course to be determined, based on your performance testing), you would start from the existing Map table, and use the root EG ID for the map that you are interested in. You would have to recursively traverse every single node in the tree however, until you find the ElectricalGroupID that matches the record in the EntitytoElectricalGroup table. And, of course, your code would have to only keep the last full ‘path’ from the Parent to child node.

Summary

As you can see, a minor change to an existing solution results in an incredibly complex code change, that was simply not understandable to most people on the team (who came up with the existing database and code I might add.) The reason I think that I understood it much quicker than most is that I simply look at things visually, and try to write everything out as clearly as possible, and as simply as possible, so it makes it obvious what is happening. During the somewhat entertaining conversation with the other developers on the team, they kept referring to code, in the middle of the conversation, yet we never have to rely on any code at all, until the ‘pseudocode’ and the full design is worked out. But again, this is most likely why I was brought on in the middle of the project. As, the ‘architect’ of the original solution was also in the middle of a 9 month sub-project which consisted of an entire 3 screens that essentially added a time element to the concepts of Electrical Groups and related entities, which was actually called ‘Projects’. The ‘architect’ was probably too caught up in his current disaster to care about adding new functionality. However, since I didn’t want to get involved in the 3 screen disaster, I insisted that he add the code for the new functionality that I just explained above to his part of the code. It wasn’t actually a lot of coding to be done. I knew that it would be done incorrectly, even though I explained the process to the ‘Architect’ and the entire team at least seven times, and documented everything with comprehensive documentation explaining the process in detail. So, I had to take the incorrect code, and fix it to complete the solution.

Of course, there was a lot more to it than this somewhat simple explanation. There were a few other screens to be written that allowed the user to visually drag and drop Electrical Groups and associate them to related entities, and of course all the code to traverse the tree, and of course the Plug-ins that I wrote to actually display the 2d code on the Entity screens. The JQuery Plug-ins allowed a user to simply place them on any screen, then call the plugin with the desired Map Id. The Plug-in took care of the rest. But again, I have to stress that for any developer who was making changes like this, it is absolutely critical to understand the high level design in their head, before even thinking about what coding changes need to be done. Even if you are not a database architect, or have any experience with JQuery, a competent developer should have been able to get this done in a few weeks or so. And, any competent developer should have been able to figure out the high level design in less than 20 minutes! So, this makes for a perfect test for a new developer. Instead of asking them technically oriented questions, which completely bypass the concept of proper high-level / technical design, a question like the above scenario should be a mandatory question in any developer interview. This should tell the interviewer whether or not the person can solve a problem without the problem being tied to any coding style or technology, which is far more important than learning any technology.

Following the hiring for performance concept would allow you to avoid hiring the ‘Architect’ in the above scenario which you want to do at all costs. The architect actually worked on the ‘Projects’ 3 screen disaster for almost a year. Looking at the end result of the ‘Projects’ module, there was absolutely no way that adding a time component to an existing solution would take a year to do. I was also subject to the constant discussions between the Business Analyst and the ‘Architect’ in which they were discussing adding new features, that didn’t really make sense, as the Business Analyst had no experience whatsoever with development. In that case, the Architect should have been smart enough to know that the B.A.’s ideas were wrong, and not to implement them, and to give the reasons why not to implement them. They should have also realized the lack of skill in the B.A., and to clarify as much as possible with the end user. This may not sit well with the B.A., but then the project would take only 3 months and not a year, as the unnecessary coding would have been avoided. Taking the average yearly salary of a Senior Developer / Architect to be approximately $100K, this would have saved the company $75,000!

So, as you can see, hiring for performance is actually much more important than hiring for skills, especially in software development. The above scenarios that I just described actually happened. Another one of the problems I found was that even though particular portions of a project were taking way too long, management never tried to correct it. In my view, this accounts for most of the failures of larger projects. Essentially, a manager hires the wrong person, and doesn’t realize it until it is too late, and at that point, cannot necessarily replace the person, as they would have to report the reason why they dismissed the person. So, they have to continue on until the project is finished (if ever). If I were a manager, I would seriously consider giving interviews that determine whether the person can perform, under a real-life scenario, instead of the typical developer interview that just asks the candidate to ramble off facts, then write some code to see how well they studied or memorized something. This is guaranteed to save the company hundreds of thousands of dollars per year, which can be critical to whether a company or an I.T. department succeeds or not.

History

• V. 1.0: Aug. 11/2015