The smell of the turkey roasting in the oven brings back many a memory of family gatherings around the holidays, but something is mysteriously missing at this years Thanksgiving.  Great Food!

I remember my grandmother making huge batches of mashed potatoes, bowls of turkey gravy, several pumpkin pies, and of course, the ever delicious apple pie.  Unfortunately all of this is but a distant memory. Today, the culture is all about healthy foods and how to "immitate" the Thanksgiving experience with substitutes to those famous dishes.

So what are we having this year?  Well thank God the turkey and stuffing are still present, but that is where the similarities come to a total halt.   This year the potatoes have been replaced with "real" vegetables, the pies are crustless pies because of course white flour is evil and the gravy well, you know, it is fatty of course so that is missing.

Is this celebrating?  I find it a poor and totally lacking substitute for the real deal.  At the same time I get the fact that we are becoming a fat, lazy and unproductive society.  It seems, however, that we could still be a productive society, yet still eat all of those great foods.  Our country fathers made the country what is is today and I'll bet they had some apple pie at Thanksgiving.

I recently wrote a Windows service using Microsoft .Net technologies to act as a broker between two heterogeneous systems.  Being a service, there is obviously no user interface for one to get feedback on how the process is executing or if it has gone into a state of error.  My solution to this was to build a very complex logging mechanism which logs information to the Event Viewer, a text file and when needed snds emails to the administrator.

All of this of course works very much as expected, but what about data integrity.  What if one of more of my systems has suspect data?  Of course the typical response to this question is for the developer to simply say, "Well the data has to be right since the app has to have good data at the very least in order to have basic operation."  So I don't believe anyone reading this would argue with that, but there are times when dealing with third parties that data can become corrupt due to errors in both their database and the communication layer.  When this happens, who is really hurt by the bad data?  The answer of course is the developer and his management chain.  It is not immediatly the third party.

To battle this problem there has to be a mechanism for at least handling data integrity issues so that better information can be sent to the admin to combat the issues.  Currently, the way we are dealing with this is by placing in-line rules into the service code as needed and passing as much data as possible back to the admin to further investigate so he can escalate the issues with the vendor.

Many information technology departments, already saddled with a heavy load due to budget cutting in a bad economy will have a difficult time building the appropriate rules into the code simply because they don't have enough time in the day.  Currently I don't have a good solution to the problem other than to make sure that every company has a data steward.  Just a food for thought blog entry.

I have been in the software development business now for twelve years.  I have worked as a contractor, consultant and an in-house developer and thus have been on many an interview along the way.  First, it should be understood that companies generally do not know how to interview as noted in the book "What color is your parachute?" by Richard Halls, but worse than that most companies put other developers in the room to interview the job candidate as they wish.  These are people who have their own agendas and often expect more in the interview than they would expect from an interview.  I want to outline several problems I have seen over the years in the IT interview process so that perhaps someone might read this blog and find a better solution to this dilemma.  I don't expect you to agree with everything here but please read it with an open mind and try to make real changes in your interview process.

The Standard IT Interview Process
Interviews usually go through the following workflow.  First, the resume is received by a human resources team or a recruiter who specializes in finding IT talent.  On their desks it is scrutinized for spelling mistakes, overselling and the ability of the job candidate to articulate his skill set.  I really do not see a problem here as this is what one would expect from a good HR employee.

Next, the handful of candidates who were chosen based on their resume are often scheduled for a phone interview.  The phone interview varies but is often peppered with questions about who you are and where you have been and in many cases a series of basic programming syntax questions are asked. 

Finally, one or two candidates are chosen from phone interview for a face to face interview.  A candidate coming in for a face to face interview could be subjected to several interviews with various levels of management and development staff.  In some cases these combined interviews can last several hours and produce very little toward the goal of hiring a candidate.  The last step is often repeated one or two more times until the company in question is sure they have the right employee.  Below I have outlined several interview types which I have identified over the years and why they are effective or in most cases not effective.

The Test Driven Interview
Nothing is more daunting to both the developer and the interviewer than the test driven interview.  In this interview scenario, there is often a verbal and/or written examination which can vary from simple syntax questions on a particular language to full blown project related questions where a developer codes a business scenario under a given time window.
Testing has a purpose in an interview, but testing is often not realistic and not focused.  First, asking a seasoned developer syntax questions is often just an exercise in futility.  Veteran developers have authored projects in languages ranging from Java to  T-SQL to Objective C and realize that syntax is pretty much the same across all OO languages.  A good handle on Google is about the only tool a long term developer needs.  So if you are interviewing a senior or lead developer keep the syntax questions to a very minimum. It is better for the interviewer to tailor their questions toward the subject of architecture and problem solving.  In other words, a for loop is a for loop so who cares how it is executed.

The Good Ol' Boy Interview
In this type of interview, general questions are often asked which probe the developer to see what kind of a fit he would be in a particular team.  I have been asked questions such as "Do you drink beer?" or "Do you play World of Warcraft?" or "What is your political affiliation?"  These types of questions do have a  place in the interview but one needs to be careful that the entire interview isn't questions about hobbies and life stories.  Personally I would stay away from questions regarding alcohol and political preference.  The interviewer should be able to get a good feeling about the candidate without asking personal questions.  Just as a note, I usually excel at the Good ol' Boy interviews because, well, I am a good ol' boy.

The Bad Cop, Bad Cop Interview
Did I mean "Good Cop, Bad Cop?"  No, I meant bad cop, bad cop.  In this type of interview the interviewers make every attempt to intimidate the developer and make him crack.  I think somehow they think if the ask every question like a police office trying to get someone to confess to murder they will weed out the weak.  In this particular case they often project themselves with a solemn face and ask questions in monotone.  My personal feeling is that they really don't want to be there and they really don't want another developer on the team so they try to run the poor guy off.  Usually they ask very difficult questions in an effort to completely fluster the candidate.  In one bad cop interview I was asked "How many parameters can be passed into a stored procedure in SQL Server 2005?"  Really, is anyone passing 1024 parameters into a stored procedure?  Think about the questions you ask. Are they practical and meaningful or just trivia?  In one instance I became so angered by the silly questions they were asking, I just started asking them difficult questions.  Of course they didn't know the answers either.  Interviewing is not a game of Jeopardy, it is a way to find out if a candidate will be a good fit and be productive in an organization.

The Senate Hearing Interview
Similar to the Test Driven Interview, in this scenario, the candidate is faced with a panel of perhaps 6 to 10 developers firing away question after question ranging from simple to the absurd. These interviews can often last over an hour.

In our world, there is a concept called fight or flight.  When a person is put into a pressure cooker situation such as a panel of interviewers the fight or flight mode is activated.  I have reacted in this situation in one of two ways.  Either I become angry that they are asking so many questions from so many directions and I begin to get defensive or I just give up.  Remember that you are hiring a developer not an attorney.  A software developer does not need to be able to stand up to a barrage of questions coming from 10 different directions.  Most developers are involved in very small groups and do a large amount of head down development with small meetings scattered in.  By the end of this interview the developer is tired and generally turned off about your organization.

An interview should be composed of between 1 to 3 people and be structured as follows.

  • Get to know the developer time  (10 minutes) - question to ask might include topics about where he is from where he went to school and what type of hobbies he participates in.  Do not ask him where he sees himself in 10 years.  This can be a huge turnoff for me anyway.
  • Project Related Questions (10 minutes) - questions might include topics about the business problems solved and how architecturally they were solved.  Also ask questions about technologies used to solve the problem.
  • How To Questions (10 minutes) - questions might include topics about how would I connect to a database and what types of objects are involved. Be creative here but not ridiculous.  Don't ask questions about the value of "x".  This is a waste of time!
  • Questions from the Candidate (10 minutes) - this is the time for the candidate to ask you questions.

The interview lasts no longer than 40 to 45 minutes!  Note that in the end no interview process is going to giv e you the perfect candidate but it can make the choice a little easier.  Culture and fit probably play the biggest role of all in finding the perfect developer.  Technology can be learned but communication skills cannot.  Finally, don't forget about the technical references.  Usually they are coworkers or a manager and can offer good insight into what technologies he knows and what he has done.