Wide Awake Developers

« October 2005 | Main | January 2006 »

New Interview Question

So many frameworks... so much alphabet soup on the resumes.

Anyone that ever reads The Server Side or Monster.com knows exactly which boxes to hit when they're writing a resume. The recruiters telegraph their needs a mile away. (Usually because they couldn't care less about the differences or similarities between Struts, JSF, WebWork, etc.) As long as the candidate knows how to spell Spring and Hibernate, they'll get submitted to the "preferred vendor" system.

Being one of those candidates is tough, but that's not the part I'm concerned about now. I'm interested in weeding out the know-nothings, the poseurs, and the fast talkers.

When I'm interviewing somebody, my main criterion is this: would I want to work on a two-person project with this candidate? My secondary criterion is "Would I feel comfortable leaving this person along at a client site? Will they deliver value to the client? Will they look like an idiot, and by extension, make me look like an idiot?"

My friend Dion Stewart had a great idea for a weed-out question. No matter what frameworks the candidate shows on the resume, ask them what they disliked the most about the framework. (I have my top three list for each framework I've worked in... except NeXT's Enterprise Objects Framework. But that's another story.)

If they can't answer at all, then they haven't actually worked with the framework. They're just playing buzzword bingo.

If they answer, but it sounds like bullshit, then odds are they're bullshitting you.

If they have never thought about it, haven't formed an opinion, or say "it's all good", then they lack passion about what they do.

A candidate that is driven, that cares about the quality-without-a-name should be able to go on a rant about something in each framework they've actually worked with. In fact, you've really hit the jackpot if your candidate <i>can</i> go on a rant, but does it in a professional, reasoned way. I love to see a candidate that can show some fire without seeming like a loon. That's when I can see how they'll react when the client makes a decision the candidate considers boneheaded. (I've seen some spectacular pyrotechnics from consultants that forgot whose money they're spending. But that's another story.)

Technorati Tags: resume, jobs

JAI 1.1.3 in beta

I've been using JAI 1.1.2 for the past year. It's an incredibly powerful tool, though I will confess that the API is more than a bit quirky.

Early this year, Sun made JAI an open-source project available at java.net. That project has been working on the 1.1.3 release for most of the year. It's now in beta, with a few enhancements and a lot of bug fixes.

The most significant enhancement is that JAI can now be used with Java WebStart. Previously it had to be installed as a JRE extension.

Also, one of the big bugs is fixed. Issue #13 is fixed in the beta. It could cause the JPEG codec to use excessive amounts of memory when decoding large untiled images. (Which we do in our app a lot!)

Technorati Tags: java

Ruby expressiveness and repeating yourself

Just this week, I was reminded again of how Java forces you to repeat yourself. I had an object that contains a sequence of "things to be processed". The sequence has to be traversed twice, once before an extended process runs and once afterwards.

The usual Java idiom looks like this:

public void preProcess(ActionContext context) {
  for (Iterator iter = updates.iterator(); iter.hasNext(); ) {
    TwoPhaseUpdate update = (TwoPhaseUpdate) iter.next();
    update.preProcess(context);
  }
}

public void postProcess(ActionContext context) {
  for (Iterator iter = updates.iterator(); iter.hasNext(); ) {
    TwoPhaseUpdate update = (TwoPhaseUpdate) iter.next();
    update.preProcess(context);
  }
}

Notice that there are only two symbols different between these two methods, out of 20 semantically significant symbols. According to the Pragmatic Programmers, even iterating over the collection counts as a kind of repetition (and therefore a violation of DRY - don't repeat yourself.)

The Ruby equivalent would be something like:

def preProcess(context)
   updates.each { |u| u.preProcess(context) }
end

def postProcess(context)
   updates.each { |u| u.postProcess(context) }
end

Now, there are two differening symbols out of 10 (20% variance instead of 10%). There's been no loss of expressiveness, in fact, the main intention of the code is clearer in the Ruby version than in the Java version.

Can we make the variance higher? Perhaps.

def preProcess(context)
   each_update(:preProcess, context)
end

def postProcess(context)
   each_update(:postProcess, context)
end

def each_update(method, context)
   updates.each { |u| u.send(method, context) }
end 

Now the two primary methods have 2 symbols out of 7 different or nearly 28%. The expressiveness is damaged a little bit by the dynamic dispatch via "send". It would be unthinkable to use reflection in Java to make the code clearer. (Anyone who's worked with reflection knows what I mean.) Here, it's not unthinkable, but it might just not help clarity.

Technorati Tags: java, beyondjava, ruby