Hiring good programmers - Part 2

In Part 1, I outlined some problems with common practices in hiring programmers (or anyone else for that matter).  What can the hiring manager do about these problems?

I would start by defining the tasks the position requires as honestly, realistically, and specifically as possible.  This isn't as easy as it sounds.  For example, many openings that I've seen for programmers require someone who can complete code "on time, within budget, and bug-free".  If a company is having trouble finding programmers who meet these requirements, what is the problem?  Yes, skill deficiencies in the programmers themselves can cause any or all of these issues.  But so can poor requirements, poorly controlled scope creep, poor communication, etc.  What exactly is the need?

A better approach might be identifying which aspects of the finished product are most important.  A programmer trying to be one of the first to create a game for a new mobile system might be more focused on time and budget than bugs.  To contrast, programming for medical devices would require much more focus on creating bug-free software.  Along with this, be aware of any road blocks within your company preventing programmers from getting work done.  Do the programmers frequently get poor requirements?  While improving the requirement gathering and documenting process, I would focus on getting programmers with enough of a business sense to be able to extrapolate missing information from the requirements.  Are projects frequently under time pressure?  Then finding programmers who can get work done quickly should be a priority.

Once the tasks have been defined, I would then break each of the tasks down into Knowledge, Skills, and Abilities (KSA).  For the sake of example, I'll start breaking down a few of the tasks and KSAs needed for a completely hypothetical mid-level ASP.NET developer position.  This position might be for a mid-sized company looking to add onto a web application designed to track inventory within a supply chain looking to add a developer to a team that can handle simpler tasks to free up some senior developers to work on other projects.

Tasks:

1. Creates reusable, maintainable, reliable components in C#
2. Tracks down bugs with little assistance from more experienced developers
3. Integrates third-party components into web applications

Task 1 could be broken down into the following KSAs:

1. Working knowledge of Object-Oriented Programming concepts
2. Experience creating effective unit tests
3. Makes intelligent decisions as to when a component should be broken down into sub-components

Task 2 could be broken down into the following KSAs:

1. Can read and understand code in C#
2. Can read and understand documentation
3. Can refactor poorly written code into more usable/readable components
4. Can write unit tests to reduce the amount of time testing through the user interface

Task 3 could similarly be broken down into the following KSAs:

1. Can read and understand third-party documentation
2. Can integrate third-party code into a larger application as seamlessly as possible
3. Can anticipate problems with third-party components and comes up with reasonable work-around solutions

A real KSA breakdown would include many more tasks and KSAs, but hopefully you get the idea.  Now that the needed KSAs have been identified, it is time to identify the important ones.  Reading and understanding C# and documentation are common KSAs, as is seeing how small pieces fit into a whole, and writing effective unit tests.  Not found is the need for keeping up with the latest technologies or understanding large-scale structural issues.  (Keep in mind this is a hypothetical position - these skills may be needed in other ASP.NET positions depending on the company.)

With this information, you can design questions for interviews.  Since we need to identify people with an understanding of creating reusable, maintainable components, here are some questions that we might ask:

• If you are asked to fix a method that has a return type of an object and returns a due date if the user is valid and 'false' if not, how would you go about doing so?
• If you have some functionality in one of your classes that is needed by another, what is the best way to move that functionality to the new class?
• If you are using a third-party library to send information from several different ASP.NET pages to a third-party store, where do you put the logic?

These questions are all specific and are all targeted to certain tasks I would need the interviewee to perform.  I have my ideal answers for each and can evaluate the interviewee consistently.  It is important to ask several questions that get to the same point because of the possibility of miscommunication or misinterpretation on either side.

It is also important to evaluate employees by watching them do work that is representative of the job they would be hired for.  I might run into someone who can talk about different technologies or approaches fairly well, but when they get to doing the job, they fall short.  I would take a similar approach to designing the test as I would designing questions; I would identify important KSAs and create tasks that would require them.  Taking this one step further, I also like to break down my tasks into three categories: tasks that every person ought to be able to do, tasks that require skills that are "nice to have", and tasks that I don't expect the candidate to complete.  This way I can get a deeper sense of the understanding a candidate has for particular skills.  A candidate who can complete some of the tasks in the last category will have an advantage over those who don't.

Finally, you may be wondering about how to determine cultural fit.  Unfortunately, cultural fit is tough to pin down and therefore it is difficult to create good questions to get at it.  To make it even tougher, many of the questions that could be asked to ascertain cultural fit open the door to discrimination lawsuits.  I don't have any good ideas here.  If anyone has any ideas, please feel free to leave a comment.  I'm certainly open to ideas.

Hiring good programmers - Part 1

One thing that I've struggled with, and I know I'm not alone in this, is how to accurately decide if someone will be a good programmer for a company or not.  Traditionally, companies will first screen resumes, looking for particular experience, skills, etc.  They will next have a phone screen to further weed out candidates.  Finally, the candidates will be brought in for a face-to-face interview.  How effective are these methods, and what can we do to be more effective?  In Part 1, I will outline issues with common current methods of evaluation, and in Part 2, I will suggest an alternative.

What about the resume?  Many companies will pre-rank candidates (either explicitly or implicitly) based on the quality of the resume and the information presented on it.  There are a few problems with this.  First, I don't have a reliable source handy, but I recall hearing that 50% of people lie on their resume.  50%!  Couple with the proliferation of sites (such as fakeresume.com) that are intended to give advice to people who want to get away with lying on a resume, and it's tough to know which resumes to trust.  Second, many of your potential employees will have hired a professional resume writer in order to get your attention.  Great resume?  Is it because they are a detailed worker or just hired a great resume writer?

What about a degree?  Most of the jobs posted on the major job sites for programmers ask for some sort of technical bachelor's degree.  This certainly should be a consideration for an entry-level candidate.  However, in observing a number of people in a number of different industries, I've come to the conclusion that the benefits of the quality or type (or even presence) of a degree decreases severely after about 1-3 years of experience.  For experienced candidates, the ability to learn new concepts and apply those concepts in new situations becomes a much more important asset than the quality or source of their original education.  Putting it in another way, does the candidate have 10 years of experience, or 1 year of experience repeated 10 times?  In fact, I might be more inclined to hire the person with the poor quality of education who somehow managed to become a good programmer, since they have the proven ability to learn and apply concepts in less than ideal circumstances.  (Or maybe I just think that because I'm a self-taught programmer.)

What about the interview?  A lot of good information can be gotten from an interview, but a lot of misleading information can be gotten here, too.  I'll speak more about interviews in Part 2, when I actually start talking about methods that can help you find good candidates rather than merely eliminating bad ones, but I will mention here that you should always be aware of the implications of what you are asking even if the legality of questions weren't an issue.  As an extreme example, I read an article on BNET that quoted a hiring manager saying (and I'm paraphrasing) that they hired someone based on the answer to this question: "If you would be a character from 'The Wizard of Oz', which would you be and why?"  What can you learn from the answer, assuming you get one?

1. The interviewee thinks well on his or her feet and handles the unexpected well
2. The interviewee has an active fantasy life and empathizes with characters easily
3. The interviewee is a huge 'Wizard of Oz' fan
4. The interviewee trusts you that you know what you are doing, even though you are asking a question that seemingly gives you no insight into his/her ability to do your job or him/her insight into their fit into your culture, making him/her a likely "yes person"
5. The interviewee does not have the ability to sense when something is or is not a waste of time and would be a poor choice for leadership positions

You could legitimately make a case for any of the five.  #1 is definitely a plus for your company, #2 may or may not be, depending on the position, culture, and point of view, #3 is completely irrelevant, and #4 and #5 would be considered negatives for most positions out there.  I can't see how the interviewer in this case learned anything worth knowing from this question given the uncertainty involved.

Finally, many companies have some sort of programming exercise as a part of the interview processes.  Even a poorly designed exercise will likely separate the completely incompetent from the competent programmers.  For example, what does having the programmer show all the prime numbers from 1 to 100 show about his or her ability?  You may need someone who can think mathematically, but you may not.  Here again, the best designed exercises will have specific goals and will not be some generic problem designed to eliminate the worst programmers.

In Part 2, I will demonstrate some methods for getting at the heart of the job position which will hopefully make it easier to scan resumes, design interview questions, and design programming exercises.

Should programmers be middle managers?

Recently, I wrote about whether programmers should get an MBA here, and said that an MBA would be helpful for the programmers who wanted to get into management.  Related to that, I came across an article on CIO.com about the inherent skills needed for programmers, middle management, and executives.  I don't have any particular insight into the article, or what it means for I.T., other than it's an article worth reading.  I think I might put the book on which the article is based on my reading list.

Using simulation software for better project estimation

Most technology professionals that I've encountered have difficulty in creating accurate estimates.  Unclear requirements, differences in personnel skill, feature difficulty, and scope creep can all contribute to uncertainty in estimates.  There are, of course, different ways of getting around these problems, such as using pre-determined formulas, padding estimates, making frequent adjustments, etc.  It's about time that I.T. professionals think about adding simulation tools to their tool belts.


(In interests of full disclosure, I'm writing this article with Palisade's @RISK software in mind, since that's the software I used in my Quantitative Analysis course.  I'm reasonably certain that there are similar software packages out there.)


How would these simulators work for estimating an I.T. project?  First, you should break down your effort into smaller, manageable components.  For the sake of example, let's say that you need to add a new feature to an existing web site.  You know that there will be 5 new pages, 7 new tables, and some business logic.  However, the business logic is extremely difficult and one of the pages will require quite a bit of extra work, perhaps using an unfamiliar technology.  You break it down, and your estimate might look like this:

1. UI for 4 simple pages: 2 hours each (+/- 1 hour)
2. 7 database tables: 1 hour each (30 minutes minimum, 2 hours maximum)
3. Complex UI for one page: 8 hours (could be 6, but it could explode to 16)
4. Business logic: 16 hours (but for whatever reason, you really don't know)

You could enter these assumptions into the software (#4 would likely be done using a normal distribution) and it would tell you the average amount of time, as well as the best- and worst-case scenarios.  Before the software, our range of possibilities would be from 20 to 70 hours.  With the software, we can reasonably say that the effort will likely take somewhere between 30 and 50 hours.


This was a relatively simple example for demonstration purposes.  I can't speak for all risk analysis software, but @RISK makes it relatively easy for a programmer to add some pretty complex logic into your scenario.  You could pretty easily plan for uncertainties due to uncertain staffing, add provisions for scope creep, or add profits (if you're a consulting firm) to you model.  The sky is the limit.


While the software can be useful, it does not protect you from errors from false assumptions.  In the example above, I didn't add provisions for getting the data from the database into the business logic layer, nor did I add a provision for testing.  If these components weren't already built into the estimate, your estimate is going to be low. Therefore, approach the information you get back from the system cautiously.


If you're interested in reading more about the subject, I would suggest the textbook I learned from, which is Data Analysis and Decision Making by Albright, Winston, and Zappe.  The examples they give are not I.T. specific, but it shouldn't be hard to apply those concepts to your estimation process.  If nothing else, you can continue to watch this blog since I plan on continuing to post about the subject from time to time.

Should programmers get an MBA?

One question that I see among a few computer programmers these days is whether or not they should go back to school to get their MBA.  The answer really depends on what he or she wants to do in their career in the next five years.

Before I get any further into this, let me first describe what an MBA can (and can't) do.  The MBA is a very general degree focused on giving business decision makers the background they need in order to make their business thrive.  MBA programs cover high-level topics such as accounting, finance, operations management, economics, and business strategy.  Programmers, on the other hand, often need to get well acquainted with the details of the day-to-day operations that keep a business growing.  The two areas aren't completely separate, but they don't go hand-in-hand, either.

Getting back to the original question, programmers who wish become managers at some point in their careers will find knowledge gained from getting an MBA useful.  No degree should be mandatory for any position, since most knowledge can be gained through other means, but I couldn't imagine trying to be a manager without the skills I've gained from my MBA studies.  Too many people assume that being good at a job makes one qualified to manage others doing that job, which is absolutely not true.  Managing and doing are two completely different skill sets and have completely different knowledge required.  The MBA can help fill in some gaps in management skills.

For the non-managing programmer, I could see how an MBA could help a programmer understand business requirements (which was my original intent for getting mine), since the degree is about the high-level functioning of business.  I can also see why an MBA degree is strongly desired to work in the large consulting companies, since the degree not only gives you the tools to speak with business stakeholders but also helps prepare the student for project management.  I'm not convinced that the MBA is the best use of time and money for a programmer with these career goals, though.  The fit isn't bad, but there are other alternatives out there, such as PMP certifications or industry-specific degrees.

Many people look to MBA degrees as a way to help avoid unemployment.  I can't think of a worse reason for a programmer to get this degree.  (Well, maybe that's not true.  I can think of worse reasons to get an MBA.  Most of them wouldn't be considered by someone seriously considering the degree, though.)  The competition for jobs seems to be a bit stiffer for MBA grads than for experienced programmers with knowledge of the latest "hot" technology.  In fact, programmers who wish to remain programming after getting their MBA might find job hunting tougher due to the perception of being over-qualified.  Programmers should also think very carefully about spending significant amounts of time away from technology-specific studies.  Technology is changing all of the time.  Much of it should be easy for any IT professional to pick up due to its similarity to previous technologies, but some of it is not.  While it is not impossible to keep up with technology while studying for an MBA, it is not an undertaking that can be done by everyone.

In the end, it was worth it for me to get my MBA because I'm very interested in business strategy, and my MBA helps me understand issues related to management and strategy that I might not have as a pure programmer.  Also, I'm not as interested in specific technologies as I am in finding the right solution to solve problems.  That doesn't mean that the degree is right for every programmer, but what course of study is?