James C. Liu's Weblog

Wednesday September 08, 2004

Worthiness Filter

Phone Answering Image

In my youthful days, I was much more eager to please and be responsive, so I'd answer every phone call and voicemail religiously. I'd be at work by 7:30am and leave at 9pm. No girlfriend, no wife, no worries about greasy hair and personal hygiene except on days when customers or other colleagues were coming into the office for a face-to-face. Heck, we had vending machines and they carried Pork Rinds and Mountain Dew. What else did a single guy software guy need? But that's all changed, now that I'm married and more senior. Old age, wisdom and vanity are setting in. I'm forced to drink Diet Coke now. All the caffeine, without the sugar. In addition, I now have twill cotton, pleated front slacks (a.k.a. Dockers) hanging neatly in my closet. How my wife knows and finds my size is a mystery; however, old habits die hard and the slacks remain hanging in the closet because I still wear shorts to work most days, although my wife has figured out there are Dockers shorts too, like the kind Tiger Woods might wear if Levi's sponsored him.

In my seasoned experience, I've learned from other senior engineers to stop making myself seem too available. Otherwise, it might cheapen the way people perceive my value, and I wouldn't want that. Never mind that some poor fellow engineer elsewhere might be suffering kernel panic convulsions or performing rituals of self-flagellation at some ISV site so as to appear to be working on the problem, but I've learned that those guys can sweat a little and maybe they'll solve the problem on their own too. Because, heck, what would we know about that particular panic or crash dump? It's been so long since some of us have slung code or hacked UNIX, that most of us have forgotten the basics of looking at a crash dump by hacking the Temp or Swap FS. Some of us don't even know that we reboot a system after a crash, and while we wait for the system to recover from the crash, we pray that we have enough space in /var for the dump. Why, because the crash goes there. "What? You mean they moved the thing into /var/crash? When the heck did that happen?" is a common reaction by some real old guys that are still stuck on Solaris 2.5.1. But, you have to give us old guys some credit. Some of us have gotten really good at making slideware and using every known font and graphics transition invented by the StarOffice team. And another thing we do, is ration our phone calls - doling them out only to those that are worthy.

But I've always wondered who exactly would make a worthy caller. My Director? My Veep? Surely they are worthy, because I wouldn't want to make them unhappy by my unresponsiveness. But what about the rest of the world. I'd hazard a bet that most folks are like me and just wing it. My filters are driven quite frequently by my current mood or train of thought. I'm prone to answering even trivial calls when I'm meandering over a boring roadmap presentation or in a boring non-technical conference call. In fact, it's quite common for me to actually put the original caller on hold and take this new call coming in - whomever it's from. Never mind that my HOLD button might be pre-programmed with the latest lite-soft-baby-rock elevator music that the other 2 dozen callers will now hear, or that the mute button actually isN'T engaged on the desk phone if a call comes in on my cell. It's gotta be worthy, whatever that's supposed to be.

I suppose we could play psychological games with colleagues and managers by selectively not answering calls. For example, if lots of opportunities exist in other groups or outside, do we purposely not answer calls, just to get our management worried that we're a flight risk? Couple that with wearing long slacks, dress socks and penny loafers and suddenly, management might think you've planning on jumping orgs or at least interviewing. Nah. I would do it more often just as a joke, but having 4 servers in the office with a late summer heat wave outside mandates this dress code: shorts, t-shirts and birkenstock sandals.

Sometimes I wonder if this isn't a sad state of affairs that I need to spend so much brain power just on the subtle task of phone call screening. It sure seemed a lot easier in the old days when I answered the phone whenever I was at my desk, or answered voicemail as promptly as I could when I checked my messages. Helping others solve their problems seemed a lot simpler too, even if there were lots of calls and it seemed like drinking from a firehose. At least the firehose quenched some inner thirst for integrity and engineering passion that drinking this Image Kool-aid can't.

Sifting the Wheat from the Chaff

NOW HIRING. The signs are up and down the street. And even internally, while some folks are being RIF'd, we're hiring too. And to do due diligence, I need to sink a lot of time into sitting down and screening the half or full dozen candidates for just the one job opening.

And here, it's impossible for one person to do all the interviewing. But with teamwork, it may be possible to divide and conquer. And that's where our team of interviewers has learned to optimize on each others' skills. Some folks are masters of the Personality. They can size up the candidate and tell if they have the emotional and personal skills needed for our line of work. Others are masters of the resume. They can pick out inconsistencies and exaggerations in 30 minutes or less. Others are masters of the background check. Has this person committed a felony? Do his/her references provide supporting data? Did he/she graduate from the claimed school?

My part in the interview process is the technical evaluation. Having performed probably over 200 interviews in my 9 years, I've built up a way that I think can pretty much guage if someone has the technical resourcefulness to handle a job here at Sun. I'm no good at personality assessments because I don't concern myself with emotional fit. My goals are simple: Folks who get a thumbs up from me have a pretty good chance of technical success at Sun, and hopefully if I'm doing it right, we're always increasing our average IQ with a hire and not going the other way.

So what's my approach? On the outside, it looks pretty easy. I ask a set of questions that cover 5 technical areas: OS, Programming, Networking, DataBases, and General Problem Solving. Each area has its own score, and I evaluate one last area which is communications, based on my overall impression on how easily I could communicate the question and that the candidate could understand and relate questions or answers back to me. Certainly, correctness to the questions asked counts significantly in the score, as well as approach to answering the question. Most of the questions I ask could be answered in a sentence or less; some have more than one correct answer. The interview could be as short as 15 minutes if the candidate is so technically superior that he/she "Walks on water." Or it could go over an hour and end up badly if the candidate just isn't technically qualified.

Ironically, the questions I ask are actually quite simple. But from these simple questions I can effectively gleen a candidate's Self-Reliance, Current Expertise Level, and Computer IQ. The self-reliance I'm looking for is in fact an Emersonian self-reliance. It shows itself by the level of trivial tips and tricks one acquires in order to maximize one's own productivity with minimal effort. Most of these tips and tricks are learned either by practical on-the-job problem solving or late at night hacking on a home computer that runs some minimally support UNIX distribution. But knowledge gained in such self-struggle is often the deepest and best learned, unlikely to ever be forgotten. Those who have the Emersonian bug can't and won't let themselves give up. They won't quit trying to figure out something until the cold pizza and Diet Mountain Dew wears a pseudo-ulcer in the their gutts and they have no choice except to run off to the washroom and seek relief via one orifice or another. But they always come back and eventually master whatever they were seeking before. That kind of tenacity is quite desirable in working with complex technologies where we become the last line of support for our partners. They count on us to be the final authority on technology.

Time, however, is an enemy. It never stops marching forward. And so we must also identify the brighter and more gifted individuals who have the aptitude to learn fast and work fast. Afterall, as tenacious as we might be, if we're too slow-witted, we won't be able to keep up with our own pace of technical evolution; i.e. the dumb get dumber. Too often, there are also much bigger companies out there already entrenched with their global services guys at a partner's site. They are all neatly dressed in suits, pressed white shirts, ties, and wing-tips. Sometimes, the lone Sun engineer faces a flock of 50 pairs of wingtips and must engage in a battle of wits and implementation. The Kung Fu from the One Sun engineer must be stronger than the Kung Fu of those 50. And such Kung Fu isn't solely learned; It's talent already inside that we happen to discover and unleash. So the interview process must try to get candidates to reveal their resourcefulness; get folks to think on their feet.

For those of you who've survived a thesis or dissertation defence against a committee of "slaughterhouse" professors, you'll be familiar with the overall feel of the kind of interview atmosphere I try to create. Only, I'm no where near as harsh as my dissertation committee, and I try to set the mood and complete my line of questioning in no more then 45 minutes rather than 4 hours. But, like the Professors, I like to start with simple questions about underlying fundamentals.

For example, something so simple as moving a file system in UNIX from one machine to another can reveal a lot about any candidate. It's such a basic skill it has to be in every UNIX engineer's standard repetoire. And there are multiple ways of doing it; some being more robust than others. How each person does it can reveal whether they were a user or system admin; whether they had root or not; whether they shipped software source or packaged binaries, or even at which decade they entered and started using/learning UNIX. Such a question can also be pretty humbling to someone who claims to be a senior engineer but has to finally admit that he's never really transferred a filesystem in his life. He always called the ServiceDesk and had them move it for him instead. Such an admission is usually a major ding against the Self-Reliance score I'm looking for. In addition, such a statement casts all claims of software development experience into doubt. For surely, anyone here who's ever had to do any software coding or porting has inevitably run into disk shortages, disk errors, disk migrations, disk backup, and a plethora of other technical issues and this must have forced them to transfer filesystems. Either the candidate never did as many projects as claimed on the resume, or really was not a main contributor to the projects listed.

Another CV-Resume-Checkbox-Line-Item that I see a lot is expertise as a Java programmer. Many people claim it. Very few exhibit real expertise at Java coding that would make me feel comfortable about having them help a Partner architect a high-performance Object-cache based on SoftReferences. Here too, I can ask a simple question that can then reveal a lot of understanding and practical experience with Java programming. For example, I like to ask if:

        public static void main(String[] args) throws Exception {}

defines a valid entry point method for a Java application. I remember one person I interviewed smiled and quickly answered, "Yes. I use this all the time. It's a shortcut so I can prototype some functionality without the hassles of all the try-catch blocks and curly braces." Bullseye! Exactly the answer I was looking for. He knew the answer because he had practical experience and he liked to discover shortcuts. I usually follow-up and ask why it's okay or not okay to add the clause throws Exception in the method declaration. Folks who program a lot know that the JVM ultimately catches all runtime Exceptions and the default behaviour is to stop execution, dump a stack trace and exit. So adding the clause is okay. For folks with less practical experience, or who've primarily played with Java not through source code, but through an IDE that autogenerated 90+% of their code for them, they wouldn't be so sure of the answer. The key again is I'm looking for self-reliance and some quick-wittedness. I'm seeking out whether the candidate ever did so much prototyping, especially for Java network and IO code, that he got fed up with Exception code blocks and the encumberance of code frameworks the IDEs enforce and was curious enough to try this little bypass to simplify his life. Curiously, among the 4 top Java coders that I've worked with inside my department, we all cheated this way at one time or another and we all discovered this trick independently.

I've got a whole list of other questions I ask. But I wouldn't want to give away all the goods in a public forum. Someday I might try to formulate this and write some web application to capture all the cool interview questions each one of our engineers asks candidates during interviews and what each interviewer should look for in the answer and what possible follow-ups are available. When that day comes, the technical interview should become a piece of cake for any interviewer, technical or not, and so they won't need me any longer. After all, I've always thought of the technical interview as the easiest and most objective part in candidate selection. The hard part is figuring out if that someone is actually possessed by the spirit of a deceased, volatile whack-nut gun collector who, in his former life, was a U.S. Postal worker in a cold, northern Midwest State. That's why we need top management talent for these interviews, too. September 08, 2004 05:43 PM PDT Permalink