showing what you know

Last night I participated in the Board of Review process for a new Boy Scout troop founded by the graduates of the Cub Scout pack my sons belong to. It was the first time that I’ve been on the delivery end of the Board of Review process–I went through plenty of them myself as a Scout a quarter century ago–and it was an interesting experience. The purpose of the Board of Review, held when a Scout has completed the requirements for his next rank badge, isn’t so much to quiz the Scout–that’s for the Scoutmaster to do, and we take his word for it that all the requirements have been met–but to assess how well the troop is serving the Scout’s interests. It’s more of an “upward feedback” or “manager assessment” session, a rarity in the business world.

In the spaces between the four sessions (three Tenderfoot, one Second Class), I heard some interesting stories about of the Scoutmaster conferences from the troop committee chair . The troop’s Scoutmaster is a veteran Scout leader, with an encyclopedic knowledge of all the things that kids like to do and a deep commitment to Baden-Powell’s “game with a purpose”; he was the Cubmaster of the pack when I joined, and a big reason that we picked this pack.

One of the problems of twelve-year-old boys (and there are many…) is that they often know what they know, but can’t express it in words. When asked to describe how to set up a tent, or to name the rules for ax safety, or explain the first aid treatment for shock, they’ll stare blankly at you and fidget. Their hands might know all these things, but the pathways from hand to head to mouth are not quite cleared yet. Needless to say, most Boy Scouts, at least the younger ones, would not do well in a formal job interview.

During the Scoutmaster conference for one of the Second Class Scouts, which requires knowledge of first aid for a puncture wound, the Scoutmaster broke out a packet of theatrical blood and “punctured” his own hand. The Scout, who had been slouching and fidgeting through the verbal quiz, sprang into action, demonstrating that he knew what to do even if he couldn’t say it out loud.

It reminded me of a series of job interviews that I conducted when I did desktop support early in my IT career. The job was mostly about putting out fires, and there were plenty of fires to put out in those days: overloaded printer queues, missing network files, virus outbreaks, keyboards drowned in Diet Coke. During the interviews, conducted at my desk since I didn’t have the seniority required to book a conference room, I was frequently interrupted by fires. Rather than shoo the problems away, I sat back and let the candidate handle them. It let me see if they had the right combination of sang froid, courtesy, and technical know-how to handle the fragile computer environment of the early ’90s. It also gave me a breather for a few minutes.

In my current job search, I haven’t had an interview at all like this. Most IT interviews are thoroughly intellectual exercises: you get quizzed on some technical minutia and Java theology, demonstrate your grasp of TLAs and buzzwords, and then talk with the non-technical people about “opportunities” and “resources” and “initiatives.” Very little of it has to do with the actual day-to-day work. What would be more interesting and valuable would be if the candidate were given a real problem to solve–a web page that doesn’t parse, a servlet that doesn’t load–and the resources to solve it (an IDE and an Internet connection should suffice). In an alloted amount of time–15 minutes, 30 minutes, an hour, depending on the problem and the position–the candidate should at least show some progress toward solving the problem, and have some ideas for how to finish it up. The quality of the solution would much better demonstrate technical skills than the ability to rattle off some technical trivia.

I have a job interview this afternoon, where I expect to be asked the difference between an interface and an abstract class, the thread-safety status of vectors and array lists, and the merits of generics in JDK 1.5. These are roughly the same questions I’ve been asked for the last year and a half, and I’ve yet to find a real world problem that hinges on knowing the right answers. Perhaps I’ll break out the theatrical blood this time and demonstrate how to properly clean a wound.

Blog Widget by LinkWithin