Monday, October 31, 2005

The Code Scrapheap

In a recent post Brian Foote talkes about the death of design, and the rise of scrapheap techniques (I'm paraphrasing of course). The scrapheap technique involves scouring a virtual heap of code, and scavanging the parts you need to build something new. Ihe scrap heap in this context is the Internet, and the scouring tool of choice is Google.

Now, this got me thinking. Google has a search tool for searching the web, another called Froogle for searching for products, Blog Search for blogs, Google Print for books, and many others. So where is my "Google Code"? If I am going to dig up the tasty morsels, I will need a tool built specifically for this purpose.

But perhaps this is not something I should wish for. Perhaps a tool like this would promote Software Devolution, and in turn to more mud than I care to wade through. I am in the software maintenance business, so I already get to see more mud than I care for.

Update 11/2/05: Chad Fowler pointed out that a search engine like this already exists, http://www.koders.com. I like the fact that it lets you filter by language and license.

Sunday, October 30, 2005

Interview Testing

A couple of months ago I was mentally reviewing some of the interviews I had given, and my not so stellar performance in finding real talent. It's difficult to determine if someone will be a good fit for the job just by talking to them. I look over their resume, which may have listed certifications and diplomas, but in some cases that didn't amount to much. I could have asked a set of technical questions, but if they are Java certified, it is likely that they would know the answer. I then thought about how Goolge had a Code Jam recently. In Code Jam the participants are given problems of logic, and then required to write the code to solve the problems. I figured that this was something I wanted to try.

The test I created, and now give to potential hires, consists of implementing two interfaces in Java. The first is a maze object, which has methods to initialize and move around the maze. The methods for movement (moveUp, moveDown, moveLeft, moveRight) return a boolean value, true if the move succeeded, false if the path is blocked. This part of the problem is fairly straight-forward, it only needs to store the maze data and store the current position.

The second interface is the maze solver. This interface has a single method, solveMaze(), which takes a maze object and uses the movement methods to find the end of the maze.

Thus far we have given this as a take home exam, putting no restrictions on how it might be solved. We specifically state that there is no time limit and that the Internet may be used as a resource. We also explicitly state that we will not be running the code, so it is ok if there are syntax errors or flawed logic. Our goal is to get a little insight into their thought process which is done by reading their code, not running it.

When we created the test we started passing it around the office to see how well we coul do. A few of us would have little impromptu meetings to go over someone's solution and discuss it. We found that there were many ways to solve this problem, and most of them were flawed in some manner. One used recursion, but would crash if the maze was too big. One used a complex algorythm, that seemed to stall if the maze was too big. One was very simple, but ended up going around in a circle when presented with a open field. Then there were others that were just plain flawed, and wouldn't solve much of anything.

I found that an important part of the test was the discussion I would have with the participants afterward. If the solution was flawed, I would point it out to them. Some of them verbally offered some suggestions on how they could fix their code. This was something I saw as a positive trait, where someone is being being criticized and offers solutions on how they might fix the problem. The answer I didn't want to hear was their affirmation of the problem, and not propose a fix.

It is also nice to see the outside-the-box thinking. For example, I am impressed when a participant not only provides me with a solution, but also provides me with a test application as well. I have also liked the way the some participants modified the provided Java interface to allow for the code to be cleaner. JavaDocs and an explaination of the solution were also nice to see when provided.

There are also some cases where you look at the code, then look at the resume again, then look at the code again, and scratch your head. When someone says that they are a J2EE programmer, or Sun Certified, you normally expect them to be able to use the language well. This sort problem isn't something that will typically come out in the face-to-face interview, especially if they look over-qualified on paper.

In short, we found that the test was more than just "solving the problem". It allowed us to role play with them, were we played the customer, and they played the vendor. In a small way we replicated the cycle of presenting a problem, presenting a solution, evaluating the solution, and altering the solution as required. This is very close to how the my organization deals with customers, and it allows us to learn a lot more about the interviewee by playing the customer role.


Recently I came across Code Kata, a set of logic problems from Dave Thomas. If you are interested in using testing as part of the interview process, these problems are a good place to start, either to be used as questions, or just to inspire some thought.

Saturday, October 29, 2005

Understanding Offshoring

I came across a book by Chad Fowler a week ago, and had to pick it, partly due to the seemingly humerous title, "My Job Went To India". I haven't been affected by offshoring yet, but it has been mentioned, so I thought it would be worth a read. What I found was a little different than I was expecting, but I'm really not sure what I was expecting.

The book is broken up into 52 short sections, each only a page or two. It therefore doesn't cover any one topic in detail, but the information that was covered got me thinking. One of those chapters was one that talked about understanding your business. I'm a programmer, and like most programmers, I tend to stick to my craft and not mess around with that boring business stuff. After reading this book, I am beginning to rethink my avoidence of learning the business speak. Coincidentally, my office had a meeting with the CEO of the company, and I found that even though this book covered very few details, I suddenly found myself understanding what the CEO was referring to when he started talking about "hurdle rates".

This book gave me a lot to think about, and offers pleanty of suggestions for further study and action. It also made me realize that there is more to my job than just programming (although I had a suspicion).