Interviewing Agile Candidates

At my current client project, the group I am with is expanding rapidly based on recent success of agile projects in the last two years. With the reputation of our group increasing, our group is in demand for development to support the business. This is a great thing.

This means the group has opened up several positions for agile developers. It also means that the core members of the group have to interview several candidates to fill 6-10 positions. Not only does this take time and effort, but it also takes a disciplined approach to obtain the best candidates.

Along the way, we have developed a patterned approach to interviewing candidates. So far it has yielded high quality agile members joining the team. I hope to give an brief overview of the approach taken.

Team Members Participate in Interview

The interview process does not just involve the manager and the new candidate. We include a few members of the team during the interview as well. This gives the benefit of various perspectives and also establishes team ownership of the decision to bring on an individual. Existing team members, along with the managers, get exposure to the new candidate for up to 3 hours possibly (we first do a phone screen, then a face to face). This amount of exposure across team members only helps with obtaining high quality developers.

5 Handy Groovy Shortcuts

Groovy's main advantage over Java programming is the ability for a developer to implement a solution in fewer lines of code. Groovy's idioms produce concise, short, and clean code. Of course, on first look the code may look strange to a Java developer. But once you learn Groovy's shortcuts you realize the value of consciseness and how less noise produces easier maintenance of code. To me, this is simple: "Since there is less code to look at, there is less code to understand. Learn the shortcuts and idioms and produce less code to do more."

Over the last year, I adopted Groovy as an enterprise implementation language. Here are 5 Groovy programming shortcuts that I found to be very handy. They are listed as tests, in the model of TDD.

Spread Dot Operator

The spread dot operator calls a method on every item in a collection. Upon the invocations, it creates a new list from the return items.  So instead of looping through a collection to make a call on each object, use the spread dot operator.

Let's say we want to get the first 3 letters of each username:

    void testSpreadDot() {
      def emails = ["nirav@yahoo.com", "bob@gmail.com", "jacob@msn.com"]
      def firstThreeLetters = emails*.getAt(0..2)
      assertEquals(firstThreeLetters, ["nir", "bob", "jac"])
    } 

This is very useful when utilizing several common design patterns or just plan old polymorphism. You are able to call an interface many times with minimal code.

mockFor and MockFor in Grails

I recently came across a small shortcoming in Grails' mockFor feature. I wasn't able to return a value from a service that was mocked. I get an error where the return value is always a closure, not the value I intended. (Note this occurred in grails v1.1).

I found that using Groovy's MockFor is just as convenient and does not contain this shortcoming.

Concept Overview

Often a developer would like to use mocks to isolate code and verify that a unit of code is operating correctly. The rationale is: "Given that collaborators are behaving in a specific way, the code under test behaves as expected." In other words, if collaborator returns A, then the code under test will perform B. If the collaborator returns C, then the code under test will perform D.

Many Java mock frameworks provide this ability, including EasyMock and JMock, to name a few.

mockFor Shortcoming

On a grails project, I wanted a mock to return a certain value. This did not work. Let me provide an example to illustrate the problem.