So Easy a Caveman Could Do It

Back Draft

 

So Easy a Caveman Could Do It

 

By Jonathan Goodyear

 

Microsoft likes to tout how integrated all their products are and how easy it is to get them to work together to deliver compelling solutions to business problems. A lot of that is true, but at the end of the day, you re still writing software, and to do that, you need to have quality software developers on your team. I want to share with you some of the methods I use to hire ASP.NET developers for my consulting company, ASPSOFT (http://www.aspsoft.com). You can apply many of the concepts to hiring other types of software developers, as well.

 

The first contact I usually have with a potential job candidate is their resume. Even if I find the person through a mutual acquaintance, I still insist on getting a resume. The reason is that I can derive many clues about the candidate from that document. I don t pay a whole lot of attention to the actual content. After all, it s pretty easy to make yourself look like the perfect developer on paper. Instead, I look for things like the formatting. Is it neat and well organized? One of the not so popular things that software developers do is write specifications and documentation. If a candidate can t even put together a well formed resume (their interface to the employment world), then it is hard to imagine they would be any better with their on-the-job documentation duties. From experience, I have found that they usually do much worse.

 

I also look to see if there are any spelling errors. In today s world of modern word processors, there is simply no excuse for them. A spelling error tells me that the candidate does not review their work, nor use tools to help them ensure the quality of their work. Think of a resume as the work output from a functional specification (the candidate s work history). A spelling error is a bug. Spell-check functionality is a debugger. I don t like software developers who don t unit test and debug their work before handing it in especially to a client (in this case, me).

 

It s not a deal breaker, but I prefer to hire candidates who have a college degree. Mind you, I don t care if it s a computer science degree. After all, my degree is in accounting, and a diverse educational background can be helpful. Rather, I look to see if the candidate had the dedication to get through the four-year process. That tells me a lot about the candidate. I m not too concerned about work history, but I m not interested in job hoppers. Candidates must have at least one job in their background where they stayed for at least two years.

 

If the candidate passes the resume review I send them a coding test. At this point many candidates go away, but if they re not willing to show me what they can do before I hire them, then I m not interested. The test consists of four parts, and they can take approximately four hours to complete it. I let them take the test at home, and I put them on the honor system that they don t exceed the time limit by a large margin. The first part of the test instructs the candidate to create a simple Web application based on basic functional specifications in a text document that I give them.

 

An example of the type of application I have asked candidates to produce is something that resembles the email2face application my company created (http://www.email2face.com). There are always challenges that my company has already solved, so I am familiar with the problem domain. I allow them to make (and document) assumptions based on theoretical conversations with the client. This is an important step, because it limits the number of questions I have to answer for the candidate, and forces them to do a little critical thinking. The candidate has their choice between VB.NET and C#.

 

When I review the ASP.NET coding test, I m not looking so much at how much the candidate produces. The task is intentionally created to be too large to complete within the time allotted (which is documented in the instructions). Rather, I look more for the candidate s approach and coding style. Does the candidate use a coding standard? Is the code well segmented into tiers? Did the developer waste any time building extra features into the project that weren t requested? Are the parts of the project the candidate did complete functional, or did the candidate do a bit of everything but finish nothing? Are there any comments in the code? Did the candidate create referential integrity in the database and create stored procedures?

 

For the next part of the test I give the candidate a few start-up scripts to create a simple database. I then tell them to produce three or four queries to extract some information for me. I intentionally give the candidate scenarios for which there are both optimized and non-optimized ways of achieving the requested result. I m looking for whether the candidate knows how to produce optimized SQL. I m not interested in software developers who aren t comfortable working with databases. Just about any software application out there needs to interact with a database, so this is an essential skill.

 

The third part of the test consists of a simple coding problem. I instruct the candidate to produce a function that accepts some parameters and returns a result. One of the problems that I like to give candidates is to produce a function that determines whether a string that is passed in is a palindrome. At first, it sounds easy (in reality it isn t all that hard), but the candidate has to take into account capitalization, spaces, and punctuation. Essentially, the candidate should be able to produce the function in 20 minutes or less. This part of the test forces them to solve an analytical task, rather than just a CRUD-based (Create, Read, Update, Delete) business task.

 

The twist to this part of the test is that they must use the .NET language that they didn t use in the first part of the test. Translating between VB.NET and C# (and vice-versa) is not that hard, and should be trivial to any candidate I am interested in hiring. My clients usually choose the language that they want us to use, so this requirement is a must.

 

The last part of the test usually throws candidates for a loop. I give them a completely non-business related topic, and ask them to write me a three or four paragraph story about it. What I m doing here is testing the candidate s communication skills. A lot of client interactions these days occur via e-mail and instant messenger. Good writing skills are absolutely essential to a well-rounded software developer. They need to be able to organize their thoughts and put it on paper in a coherent format. It is amazing how many candidates simply cannot do this. Most other technical shortcomings can be overcome, but this skill is non-negotiable.

 

If the candidate has survived this far, I take them to lunch. Some companies like to have the candidate come into the office for an entire day and interview with several people, and (essentially) put the candidate through the wringer. I don t subscribe to that philosophy, but I do want to see how the candidate handles themselves in a professional atmosphere. What will my clients think of this person if I have to send them on site? I don t give the candidate a dress code, and you d be amazed at what people wear. I ve seen everything from jeans and a t-shirt to a three-piece suit. I usually wear shorts and a t-shirt, just to see if it throws the candidate off a bit.

 

An unusual thing I do is bring my wife along. I do this for two reasons. First, women are usually able to pick up on damaging character and personality quirks better than men. My wife is an attorney, so she is particularly talented at this. Second, candidates somehow feel more comfortable confiding in someone who does not work for the company (even the boss wife). I find a reason to excuse myself for a few minutes during the meal to give the candidate a chance to spill the beans. One final thing I do at the meal is ask the candidate about something on their resume, to make sure they aren t stretching the truth about their background.

 

The last step in the hiring process is to ask the candidate how much money they want to make. I ask them to be perfectly honest with me. If the candidate doesn t want to give me a number, then it s a no-hire decision. It is important the candidate get a compensation package with which they are happy, or they ll be looking for the next opportunity right away.

 

At the end of this entire process, I make a hire/no-hire decision. I use all the information I ve obtained throughout the interview process, but it often comes down to a gut feeling. Sometimes you just know. I ve honed this process from several years of analyzing what I did right and wrong while making both good and bad hires. Hopefully you ll be able to benefit from my experience and make better hiring decisions.

 

Jonathan Goodyear is president of ASPSOFT (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, an ASP.NET MVP, a Microsoft Certified Solution Developer (MCSD), and co-author of ASP.NET 2.0 MVP Hacks (Wrox). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish