Hiring Process

Recently, I got involved in the hiring process at the company I work for, mainly having to interview candidates. While preparing, I also went through some online resources.

• The Guerilla Guide to Interviewing had some interesting points. Smart and gets things done is definitely a critical criteria to keep in mind. Joel's overly self-conscious writing style can be a bit tiring after a while, though. His Growing a Team section has more interesting articles on this topic, i.e. the article on a Programmer's Perspective.
  

• The TSS article Hiring the Phantom Java Architect is worth reading before actually posting a vacant Java developer/architect job description. I don't really agree with the author on the architect/developer distinction he makes, but knowing what exactly you are seeking for is surely crucial.
  

• I don't think I would ask such kind of questions myself, but the Technical Interview Questions are quite fun to solve (or at least to try to solve). Find some the solutions in Joel's Forum.
  

Some of the experiences that I have gained so far from interviewing applicants are

• make them feel comfortable by letting them talk about their favourite project of the past
  

• ask some questions specific to their resume to get a feeling of how well what is written in the resume matches the truth (I'm really disappointed when people put some cool technology in their resume and then you find out that they only used it once for exercise 1.b of their CS course)
  

• let them explain how the team setup and the interactions were at the former job and what their role was
  

• make them write some code that must actually work (which is a big difference to writing some fuzzy diagrams with arrows, place holders, etc.)

• ask a technical question that they probably don't have the answer for and see how they approach this situation
  

• observe whether they can give precise answers to precise questions
  

• I still have a lot more to learn about interviewing efficiently
  

Information Flood Management

Today, I almost constantly feel overwhelmed by all the information, messages, and questions I get flooded with each day. Mails, bug reports, blogs, ICQ messages, phone calls, shoulder tapping, etc. I still haven't quite figured out how to manage and control this flood of information input and the right tools are definitely only part of the solution. I think it's more a human problem than a technical problem of how to handle this situation. But the right tools definitely help.

Google I use to actively find information. Their concept of a simple search UI with a smart and powerful search engine behind it has definitely revolutionized the way many search UIs work today. By the way, TwinEngine, formerly known as YaGooHoo!gle, is as simple as it is interesting.

GoogleDesktopSearch is the tool I use to search my local harddisk for mails and documents. It's super-fast and very easy to configure and use (as expected from a Google product). Often, I even prefer this tool to the built-in search of mail and web clients.

Firefox is the browser I use to browse the web. No more IE, no more Opera. Firefox is slim, fast, and I love the Themes/Extensions concept, e.g. the Web Developer extension is great.

OmeaReader by JetBrains is my favourite tool to handle the RSS feeds from blogs and newsletters that I have subscribed to (unfortunately, it only runs on Windows, yet). It's free, fast, and very configurable. The Clipping and Annotation features are cool, too. Thunderbird's RSS support would probably suffice but as a big fan of JetBrains products it's clear I go with OmeaReader.

Tadalist by 37signals is a neat little web application to keep my todos uptodate. I love their idea of removing as many features as possible instead of adding more features than needed. By the way, 37signals is the company that developed the CodeZoo website.

JIRA by Atlassian is what we use for bug tracking at the company I work for. It's the best bug tracking tool out there that I can imagine. Period. One could write a whole separate blog covering the functionality.

Configurator Pattern

Recently, I was refactoring some code which I was not happy with at all: there were many 'if instance of...' statements and I was looking for a way to get rid of them. Since time pressure was high (what a lame excuse), I coded faster than my mind could think about the problem. In the end, I had invented the Configurator Pattern, which can be applied to almost every problem:

public interface Configurator {
   Object configure(Object inSource)
}

It allowed me to get rid of the 'instance of' checks and all I had to do is write some detailed JavaDoc for each implementation of the interface to make sure it's clear what the method expects as input parameter and what it returns as result.

Once I was done, I finally took the time to look at the design. I liked it for about 20 seconds (I'm not that fast). After this period of relieve about having found a solution, I entered a much longer period of being puzzled: how could I have gotten so carried away and end up with such an odd solution? I still don't know and I'm still uncomfortable about it... But it was only 9pm, therefore, plenty of time to make history undone and to come up with something to be proud of - which I did, after sitting back and thinking more deeply about what the problem and the context are and only then implementing a satisfying solution I could come up with (it turned out ot be the Visitor pattern, but that's not the essence of this story).