Hiring and Firing

Abstract

Hiring a developer is a complex task. To hire the best person for the job you must understand what job there is to be done, which level of computer scientist is needed for the job, and what level of compensation is fair for doing the job.

Understanding the Job to be Done

A clear understanding of the job is essential. This means that the requirements are known and specified as far as possible. This has little to do with the development methodology. I am not talking about big upfront design versus iterative or agile approaches. This has to do with a level of understanding of what is to be built.

Level 1 Understanding

This is an idea by a non-computer savvy person. This is when someone says, "I have this idea about a computer program that I want developed." If you ask them, "What platform does this program need to run on?" and they say something like "Windows", did they really mean Windows or did the mean in a Web Browser. This person has no idea of how long it takes to write software and what the expense can be.

Level 1 understanding requires an Architect level computer scientist. One that understands desktop versus web based solutions. One that can gather requirements, use cases, user scenarios, and design the software and select the development environment and the deployment environment. The correct computer scientist for this job will also understand cost estimation, effort estimation, strategic planning, testing, and all of the other aspects of delivering quality software.

Level 2 Understanding

This is a person that is computer literate and has an idea for a software product. They are aware of which computer platform on which they want the software developed. They do not understand the cost of software development. They do not know about development platforms, computer languages, open-source solutions versus major vendor solutions. They have no idea that runtime licenses can be hundreds of thousands of dollars.

Level 2 understanding also requires a Senior Developer or an Architect. This computer scientist is a specialist on the platform that is required. The computer scientist understands the current solutions, tools, and resources available on the specified platform.

Level 3 Understanding

This is a person that is familiar with software development and has experience in the area. A Product Manager is typically at this level. They are aware of customer needs so the requirements will be specified. They have experience with developers and are aware that estimated dates are rarely accurate and that costs often overrun. They know of these difficulties in software development but they do not fully understand why they occur. They know of the levels of computer scientists and are capable of deciding on which level is appropriate for the task at hand. They are familiar with the capabilities of junior developers, senior developers, architects, and the other roles of software development.

Level 4 Understanding

This is a person that understands the product to be developed and the details of software development. A Project Manager is typically at this level. This person maybe a former software engineer that has taken a management path in their career. This person could be very current in issues even at the level of writing code themselves, or they maybe a few years removed from the cutting edge development practices but still are in touch enough to walk the walk and talk the talk.

They know what the job is and what type of person they need to perform the task.

Level 5 Understanding

This is a person that could do the job. They are typically team leads and senior developers. They are hiring because they do not have the time to do the task themselves. They know exactly what they want. They could do it themselves if they just had the time.

Knowing your level of understanding is the first step. It is crucial. Those that deny the facts of their understanding will soon learn from the school of hard knocks. Ignoring your level of understanding is the first step that can lead to failure.

A word to the wise computer scientist comes to mind concerning the point of the employer recognizing their level of understanding. If you find yourself working for someone that you thought was at level 3 or higher and you find them at level 2 or lower you are in for a rough ride. They will not understand why you make requests for resources. They will make decisions purely on rules of budget even if you know the decisions will lead to complete failure. You will have to do something and do it quick. What is that something? You have to educate your employer in software development. Most likely it will not be possible. The employer will view your tactics as a means for you to lengthen your task to take the pressure off of your self. All I can say is good luck. Maybe luck will be with you and your employer will know another computer scientist that they trust which will back you up. I use the word trust here because in Maverick development you will find trust is the key to success. The lack of trust leads to many of the problems in business.

Hiring within your Level of Understanding

If you are not at a level 3 understanding then you are at greater risk of not knowing a good programmer from a bad one. Even if you are a level 3 or higher the risk is still there, it is just lessened. As Dirty Harry said, "A man has got to know his limitations." Once you understand this you can then work better. If you don't understand software development then you have to apply your resources and common sense. What are some of the "common sense" things to do?

Allow someone else to make the hiring decision for you.

Find someone that is at level 3 or higher. Do you know anyone that has hired successfully in a software development situation? Go through a staffing agency. Use a head-hunter to find someone for you. Hire a consultant to gather the requirements for the task and from these requirements then you can create an accurate job description.

Allowing someone else to make the decision is kind of like the chicken and the egg problem. In this situation it goes something like this. I do not really know what type of computer scientist I need to hire. I will consult with someone that does understand the job. How do I select this consultant? Since I do not understand the problem enough to do the task myself how will I know if the consultant I select really knows what they are doing? So now I need another person that understands how to choose a consultant. You eventually have to trust someone to do their job. Once again you can do some simple things when selecting a consultant. You can talk to their previous clients to ascertain their level of satisfaction.

If you are at level three or higher then you may decide to do the hiring yourself. Many at this level will have trusted relationships with staffing agencies and head-hunters to do some of the initial work.

Even level three's and up can review and improve their hiring process. Maverick development is about getting the job done. Traditional methods are not sacred. Methods that work for the task at hand are more important that organizational policies and former practices.

During the hiring process you must:

1) Define the job requirements

2) Define the employee arrangement (full-time, part-time, contract, on-site, off-site)

3) Interview with the purpose of discovering skills and talent that is relevant and pertinent.

Specify the Job Requirements

At level 3 the defining of the job requirements are at risk of being overly constrained in some areas while being to general in others. For example, the job requirements state that the candidate must have six years Java experience and three years database experience. Many times the language requirement is over constrained. As a senior computer scientist I know that the time it takes to switch from C# to Java is measured in a few days. The time it takes to go from Java to C++ is measured in weeks. So the real job description might say "Six years of object oriented development experience using abstract classes, interfaces, and virtual methods. Java knowledge is a plus." The requirement also says three years database experience. This is typically too general. Database setup and administration varies greatly. Is it an embedded solution? Are stored procedures necessary? Is it an SQL based solution?

Full-time, Part-time, or Contract

When defining the hiring arrangement be accurate and honest. Too often games are played with peoples careers. If you need a contractor for only six months then hire a contractor. Don't hire a developer full-time with the intent of down-sizing the operation when the software is finished. Full-time "types" are not smarter than contractors. There are many of the best talented computer scientists that enjoy the freedom and diversity of contracting. Also, their experience in specifying the entire gamut of issues in software development may make them more valuable to the level 1 and 2 employers.

Also, be accurate and honest by hiring a full-time employee when that is the desired goal. Hiring contractors or converting your full-time staff into contractors in order to re-arrange expense reporting maybe advantageous to a business in the short term it will not be so to your employee base in the near term. If you hire a contractor and treat them as a full-time salaried employee they will not be satisfied. They are hourly or task paid. They will not work 60 hours a week when they are hourly and you pay them for 40. It is not right to even ask them to do so. In the other situation where you take your full-time staff and convert them to contractors you can not expect them to be satisfied. Computer scientist that like full-time employment enjoy the opportunity to grow along career paths specified by the employer. Their benefits and salary are at a rate that justifies working without punching a clock. This means there will be long days and their maybe some short days, but on average every day is a busy day.

When hiring a contractor remind yourself that this is not a hard goods manufacturing process but it is the development of software. There is no parts list or building plans unless you are at level 5. The low bidder will not necessarily be the cheapest path. Every software developer knows that once you have started a task it will cost an extreme amount of money to switch horses mid stream. Suppose you hire a software developer and they have spent one year writing code. You are frustrated because the software does not do what the software developer promised it would do by this time. If you fire the software developer it could take one quarter of the time already elapsed to come to an understanding of what is already developed and how to proceed. In this example that would mean three months of absolutely no progress to the end solution. What if you don't fire the original software developer? Maybe they are about finished. It comes down to a matter of trust. Is this developer in over their head? If you are level 3 or lower how would you know? Maybe they are dishonest and are simply wasting your time and money. Everyone knows in software development the ploy of the lowest bid. They know that the employer will be familiar with the costs associated with switching developers mid-project and that the employer will avoid this choice at nearly all cost. So the unscrupulous contractor will bid eight months knowing full well that their true estimate is one and a half years.

Interviewing with a Purpose

Interviewing with a purpose is so fundamental you would think it wouldn't need to be stated. However, the way companies interview programmers vary so greatly I feel that a little refresher course is needed.
Consider the Person

The first thing you need to consider is the person. That is what you are hiring. The computer scientist is more than just a brain with hands that can type. Finding a person that fits the company culture is extremely important. Consider this analogy of buying a pure-bred show dog. Let's consider one of my favorite breeds the Australian Shepherd. You want a dog to win best in breed and in agility trials. You have a choice of a dog that does not meet the breed standard and is completely trained in the agility course and a dog that is near ideal to the breed standard but has not been trained in the agility course. These are your only two choices. Which dog do you buy? The dog that fits the standard because you can take the chance on training it in the agility course. The other dog can not change its looks. If you have a candidate for employment that is extremely talented but does not fit in or work well with others and you have a candidate that works well with others but lacks experience which do you hire? I would say the one that works well with others. If it is an out-sourced contract position this analogy will not be as pertinent.
Consider the Skill Set

After considering the person you must consider the skills and knowledge. This is where I feel many companies do not give due diligence in the hiring of computer scientists. What would be the ideal way to discover a developer's skills? Have them develop something. You know what task that you want them to do. Devise a thin thread of functionality, or some key part of the system, and have them implement it. Have a development machine setup. Have current books available. Online documentation. Access to the internet. Let them bring their laptop and any books they want. Give them the task to do and leave them to do it. No time constraints. They know to do it as fast as possible. If you have a coding standard, give them an easy 1/2 page abbreviated version of it to follow. Really test them. If there is some IDE or code tool that they prefer to use, allow them to install it, to go home and get it and reschedule for the next day. If you are going to pay this person a professional salary for years to come, what is the worth of the time to let them really show their stuff? Remember, good programmers are not necessarily good interviewers or good speakers or have developed social skills.

The same goes for hiring an architect or designer as it does for a developer. Have them do something associated with the position to be filled. Have them design a system and talk about the deployment issues. Have them role play and you be the customer and let them try to discover requirements and use cases. Maverick development is about understanding what the end goal is of a method. If there are other ways of achieving the end goal then those methods can replace the current method. The end goal in interviewing is to discover the best candidate. Do what ever it takes to discover this.

Have them Present their Results to the Team

After you have narrowed the candidates down to the best of the best have them come in together for a different phase of interviewing. In this phase they will talk about the solution to the development problem you gave them earlier. Have each of them in front of the team and the other candidates present their solution and talk about it. Question them all and let any that want to answer speak up. If someone is quiet then single them out and ask them directly for their comments. Then have the interviewers and the interviewees rank everyone that interviewed. Yes, have them rank their competition. This will reveal a lot about each candidate.

It comes to mind that there may be some issues with each candidate meeting with the other candidates and their discretion. What if two of the candidates are from the same company? What if one of the candidates is personal friends of the manager of another of the candidates. Once again it is a matter of trust and this trust is that these final candidates have and honor professional ethics. If you can't have the ideal situation with them all together then Maverick development says do the best you can. Use your imagination and talents and come up with an alternative approach that meets the goals of discovering a person's talents and skills. I cannot specify all of the possible scenarios that can occur in a paper or even a book. In the end it is up to you to be up to the task.

Preconceived Notions

Preconceived notions or implanted notions are extremely powerful. That is why they play such a significant role in philosophy and reason. If you have a particular notion about a candidate before you interview them it will be nigh impossible to not bias everything concerning the candidate through the affects of that notion.

One example is poisoning the well. If an employee poisons the well for a candidate and this employee would be working with the candidate then you have to step back and think. Remember thinking on your feet is allowed in Maverick. Why would this person not want the candidate to be hired? Are there real professional reasons? Maybe there are. Maybe there are not. Maybe the person has another candidate that they want to be considered and do not realize that their personal agenda is overwhelming their actions. You have to deduce the answer to the old "what's in it for them" question if you do not hire this candidate. If the things that are in it for them are all business aligned then the comments are appropriate, whether they are accurate or not remains to be known. It seems philosophy here comes to play and the lessons in fallacies. Poisoning the well is one of many fallacies that reveal what I think is human nature to try to convince people that your opinion is correct at all cost including throwing out reason.

Sweetening the water. I don't know if this term is reflects what I want to say. It is basically the opposite of poisoning the well. If a recruiter is sweetening the water and saying, "This is the best candidate for the job you will ever find" you have to ask yourself what is in it for the recruiter? Is their a conflict of interest here? The recruiter doesn't get paid unless you hire one of his candidates. It also implies that unless the recruiter gives this glowing testimonial about every candidate that he refers then those without the testimonial must be mediocre.

Preconceived notions seem to be the core of a long used interviewing tactic I refer to as tricky questions.

Tricky Questions

Tricky questions are built upon preconceived notions. I have heard it said about tricky questions, "I like to ask impossible questions. Stupid people will just stare at you." Really. Maybe this stupid person is saying to themselves, that is an impossible question and this interviewer has not shown me any reason not to believe they are an egocentric idiot. Only people that are having their first few interviews in life are surprised by all of the methods and tactics employers use to try to discover talent. If a seasoned professional looks at you like you are crazy for asking an impossible question then maybe you should ask, "Why do you feel this question is inappropriate?" Maybe the candidate is feeling that they have a tremendous set of skills and you haven't even begun to discover them. So, maybe you should ask, "Ok that question is difficult, and you seem impatient about using valuable interview/first impression time on that question. Is there something you would like to say to let me know concerning your skills and problem solving abilities?" There is little need for clever tactics or tricky approaches. Get to the point.

Why do interviewers ask these tricky questions? To determine if you can think. I think it would be fair if the interviewee could ask the interviewer some tricky questions as well. The boss should be as smart as the employee. Isn't it amazing that you can lose a job opportunity because you don't know why man-hole covers are round! My point is the value of the question is not properly weighted. Maybe a better question would be something to do with the programming task at hand, like, "what are the trade-offs of shared memory versus a messaging system?"

Also questions concerning development commodities are of little use. For example a question like, "How would you write a qsort" is not relevant when sorting is an IT commodity. You wouldn't write a qsort unless the one you where using didn't meet some criteria. Then, you would studying an algorithms book for a bit and decide what type of sort was needed, and then if it is a qsort then implement one by applying the collective knowledge of the algorithms text, the internet, etc.

Compensation

After you have selected a candidate prepare to compensate them in a rewarding way. One of the many things the Boy Scouts of America teaches the volunteer leader is the value of rewards and the motivating effect it has on people. It would definitely add skills to every manager to volunteer as a Scout leader. Maverick development tries to emphasize the difference between management and leadership and the Scouting program is an example of this.

Compensate the new hire well and use your head when doing so. Suppose you have 75K budgeted for the hire. Offer them 70K and a 5K bonus if they will stay on for at least a year. Or, maybe offer them a 3K bonus and then save the other 2K to give to them during the year as they mature into their position. Use your head. Make the most of the rewards. Start the new hire with 1/2 of the annual accrued PTO immediately available. Give them a pay-scale and range of titles and such so they know where they are and how the can strive for more. Actually tell them your expectation of when they should have achieved a promotion.

In the review process don't tell them, "No one gets the 'Exceeds Expectation' status, it is only there to drive you." How will that drive a logical person? If "no-one" ever gets it then I will never get it. What you do say is that last year six people received the exceeds expectation status and here is what they did!

Compensate them with knowledge and training. Let them have $500.00 budget for any books they want. Also, find conferences or user groups or something for them to attend every year. There are so many local area users groups that long distance travel may not be necessary. You don't have to "make them happy" you simply let them be happy. You say, "Why make them happy unless they deliver." If you say that then you have missed the point.

Firing an Employee

And what goes with hiring that is never talked about? Firing. How do you select people from your software development department to be fired, laid off, or what ever term you want to use. (Isn't it amazing how people come up with substitute words to describe undesirable things?)

Three Steps to firing.

1) Make sure the review process is fair and functioning. Maverick Development proposes that reviews are done by every person on the team and they review the others and their managers. The results are posted and are known company-wide. If a person receives a bad review then they have the right to pull all of the reviewers together and discuss the situation. Why? This does many things of which one is that the person doing the review is serious about their statements and another is that misconceptions can be faced openly and the opportunity for improvement is provided.

2) Make sure you address the issues and concerns of the employees. I know a developer that was to be fired. My manager told me that since I was the team lead it was my responsibility to let him go. I said that he is a fine worker and I see no need to fire him. The manager said that this employee never got anything done. I asked the employee what he needed to finish his tasks. He said, "Two weeks left alone without interruptions." The manager said that he could have his two weeks, but that this was a probation period. I watched very carefully during the two weeks. The manager continually interrupted this employee. He gave him side tasks. The manager used him as a sounding board for varied topics (because the employee had a vast amount of experience in many areas). The employee lost on average two hours a day. At the end of the two weeks the employee wasn't finished. The manager said to me, "We have to let him go, we gave him what he asked for and he still did not deliver."

Most of us know what we need to do our job. If you ask us what we need and then you don't give it to us then you might was well fire us because we are going to quit anyway. No one likes to be setup for failure. When you ask an employee what they need to get the job done then you can evaluate and say,"Ok, I can give you what you request, but this is critical and your job is on the line." Or you can say, "What you ask for is not normal or reasonable, I can get Joe Schmoe to do the same task without these additional resources. You are not the right person for this task. I am sorry." But be fair about this, if Joe Schmoe comes in and takes the task and then doesn't deliver you have to let Joe go as well. You can not allow someone to undercut someone else and then not deliver. It is never acceptable.

3) Don't turn on the employee when you have to let them go. Games like, "If you sign this paper that you will not sue us then we will pay out your vacation." Well, I wasn't thinking about suing before, but now I am. Also, when you let someone go you can not expect to dictate to them where they can work. "Sorry we have to let you go. Remember you can not work for any of our competitors for three years." This engineer has worked and developed a very specific set of skills while in your employment. He is not going to have up to date skills in areas other than those that are business related. He has to be able to provide for himself and most likely a family as well. The intellectual property is all that you own. You can't let someone go and then tell them who they can or cannot work for.

Conclusions

Understand the job to be performed and hire the correct person for that job. Don't hire an architect when you need a junior programmer. Understand yourself and your ability to select software developers. If you do not understand software development then you are at risk of being duped by an employment candidate. Allow someone that does understand software development do the hiring.

Before you can interview you must define the job requirements, select the employment type (contract, full-time, etc), and devise an interview plan that will allow you to discover if a candidate is qualified.

During the interview process allow them to perform tasks that are relevant to the job. Allow developers to write code on a computer using the tools of the trade. Allow architects to design something using the current methodologies. Have them perform a representative set of tasks aligned around the job requirements.

Avoid tricky questions like "why man-hole covers are round". Why, because they are loaded with preconceived notions that all programmers that are good know why man-hole covers are round.

Avoid questions concerning IT commodities such as sorting routines. Few developers write sorting routines anymore. If a developer is faced with this task they will definitely use reference materials to come up with a proper solution.

Understand rewards and compensation and how to use it to the company's advantage. If you have $75,000.00 budgeted for the new hire, set back $5000 of it to use for a bonus and make sure you give the bonus for some reason or another. Not giving the bonus is not an option. Use your compensation wisely.

Use an open review policy that allows everyone to review the others in their group and their chain of management. Do not have impossible grades in the review process. If no one every gets the grade "Exceeds Expectations" then why would any logical person strive to earn that grade. Give examples of people that have earned the highest grade and what they did to earn it.

When firing an employee it becomes clearer that the choice to fire is correct if the review process is in place and is working. When someone has to be fired do not treat the person as an enemy of the state. It is amazing how it is one big family when they hired you and now it is business when they fire you. Try to leave a positive impression on the person. Their morale is crushed. This may mean months of unemployment and struggle. Pay them their vacation without strings attached. Don't try to tell them who they can and cannot work for either. You have surely secured your intellectual property and that is sufficient.