LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

When Hiring, Smarts Beat Skill Lists


By Allen Holub
June 1, 2004 — 
During dinner after the last day of a five-day training session on object-oriented design, the manager who'd hired me posed an interesting question: How do you identify above-average Java programmers in a job interview?

To my mind, that's the most important question that any competent manager can ask. The days of the manager doing the work while the peons do his bidding are long past. The best work is done by a team of great programmers, with their managers making it possible for them to do nothing but program. Finding an exceptional Java programmer-someone who can work 10 times more effectively than an average programmer-is not easy, but it's essential.

Nonetheless, it's amazing to me how bad a job most companies do when they hire. I occasionally log in to the big job boards just to see what skills are hot at the moment, and I'm always shocked by the ads that I see. First, the ads often consist of marketing hype that doesn't accurately describe the work to be done. Since competent programmers typically want to know what they're getting into, that fact alone probably weeds out scads of qualified candidates.

Next come the laundry lists: compendiums of random, often mutually exclusive skills. I just saw an ad requiring Linux, Unix and Windows system administration, in-depth knowledge of Oracle, SQL Server and Sybase, mastery of C++, Java and Visual Basic, and an in-depth understanding of WebSphere, Apache/Tomcat and WebLogic.

This ad tells me a lot about the company: They don't know what they're building or how they're going to build it.

It is sometimes the case that you have to hire before you have a well-defined architecture, but in that case you need to be looking for smart people who can do quality design work, not a bunch of dilettantes who know a little of everything but can't do anything well. Some clown in HR will probably take this laundry list literally and weed out everyone who doesn't have the entire list on their resume, eliminating lots of excellent programmers who aren't willing to lie to get a job.

It doesn't matter if a candidate has written a kazillion EJBs, if they were all garbage. I'd much rather hire a smart programmer who knows both the core language and object-oriented design principles inside and out, but who has never written an EJB, than a marginal programmer who has written 200 of the things badly. More important, I want someone smart enough to recognize that I shouldn't be using EJBs at all if they're not appropriate, someone who can quickly pick up the technology necessary to implement an evolving system.

The laundry-list approach (especially when coupled with automated keyword scanning of a resume) just doesn't work.

So what does?

First, if you're not an excellent programmer, you won't be able to recognize one. Hire a consultant, if necessary, to do the vetting. Good consultants are expensive, but this is no place to pinch pennies.

Have a candidate bring in some code and any related design documents. Cut the interview short if you can't understand what the code does simply by reading it: Are variable and method names well chosen? Are comments present where they're needed (and absent where they're not)? Is the code well structured and formatted for readability?

Look for a solid understanding of the core language. Average Java programmers don't understand interfaces, inner classes or access privileges (they declare everything as protected). They don't understand when extends is appropriate and when it isn't.

Threading-which is central to every real production application-is typically a mystery to a marginal programmer. At minimum, your candidates should understand deadlock and how it happens. They should understand the synchronize statement thoroughly and how it affects both static and nonstatic objects.

Then comes the design can of worms. I personally believe that it's inappropriate to program a procedural system in an object-oriented language like Java. Object-oriented systems have, at their core, an interesting paradox: They're both more complex than procedural systems and easier to maintain.

Procedural systems written in object-oriented languages tend to have all the complexity of an object-oriented system without any of the maintenance advantages. I wouldn't even consider a candidate that didn't know how to design. They should know the Gang of Four design patterns cold, for example.

Can the candidate understand UML diagrams? Can they produce an Activity diagram from a couple of scenarios? Do they even know what a Use Case is? Do they understand dynamic modeling and the associated diagrams? Look at their code again. Someone who, by rote, makes the data fields of a class private, but provides a getter and setter method for every data field, does not understand basic object-oriented principles like data abstraction and implementation hiding. Is the protected keyword used correctly (that is, primarily for template methods)?

So that's a start. I don't have room, here, to cover more details, but I think you get the idea. Give up the laundry lists and start looking for real competence. The hiring decision is the most important one that a manager can make.


Share this link: http://www.sdtimes.com/link/27901
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading