Finding the Answers

sleuth.gifToo many people place an emphasis these days on retained knowledge. This is especially prevalent within technical fields. Computer programmers are often asked to recite arcane utterings of alphabet soup during job interviews. This isn’t important. What is important, however, is simply knowing where to find the right answers.

I will admit this up front – this post is going to ramble a bit.

At one point in my career, I was guilty of this as well. I was poking around some old boxes here in my office the other day, and I came across some of old interview notes I made on several candidates. Here are some examples of questions that I used to ask of senior level C/UNIX programmers in a job interview:

What does the use of the raise() system call accomplish?

What is the difference between the dup() and dup2() system calls?

Given only a shared memory key and shared memory flags, how can you attach to a shared memory segment if you do not know the size?

How (specifically) can you install an ANSI-compliant, unreliable signal handler?

What in the world was I thinking?

I’m surprised that (A) anyone passed my interviews (surprisingly, a few folks did), and (B) that I had the ridiculously narrow view that all “good programmers” memorized every little niggling detail of every system call and library function available to them. I should point out that the ones who did actually ace those old interviews usually turned out to be very strange workmates. Think about that for a second, and we’ll move on.

While a certain amount of detailed questioning is useful, it really isn’t an all-encompassing way of measuring a person’s potential value to your organization. Sometimes, the best answer of them all is simply knowing where to turn to find out more. This is one of the first things they teach you in the consulting world. When placed in a new client situation, it isn’t important to know the perfect answer on day one. Instead, the focus is on understanding what the problem is, inventorying the assets that you have available to you, and then filling in the gaps on-the-fly. I am reminded of one of the unofficial mantras of the U.S. Marine Corps: “Improvise, Adapt, and Overcome”.

Now for some jobs, being able to readily and completely recite the answers to life, the universe, and everything (a la Douglas Adams) is probably a handy skill to have. Say, for instance, a nuclear physicist. However, I am not a nuclear physicist, and I doubt you are either. So, read on.

One of my original mentors, Russ Miller of The Knowledge Tree, used to quip:

To be a good computer programmer, you simply need to know three things: One, what the data looks like. Two, how you can access the data. And three, what to do with the data once you get it.

A bit of an oversimplification, but I can’t count how many times in my career I’ve been forced into an environment that used a “foreign” programming language or platform. Instead of making some vain attempt at digesting every nuance of a new programming language, you instead focus on just the pieces you need to accomplish the mission at hand. All programmers understand the concepts of data, data access, and logic/flow control. They all know what needs to happen to open a file and read a bunch of records. They are also very well aware that loops, IFs, and other flow control constructs are available in any language (yes, including assembler, with its self-documenting JMP instruction).

Reduce it to the simplest form, and research the things you already know. The rest will generally work itself out. Russ Miller’s simple little rules have always served me well.

Instead of asking those granular questions I listed above at the beginning of this article, I should have been asking questions that focused on their accomplishments, work ethic, and programming philosophies. I should have focused on discovering their aptitude, and not every facet of their skillset. Thankfully, I learned this lesson a while ago, and now have a much more “balanced” approach to conducting technical interviews.

Sure, I want to know whether or not this person can “walk the walk” from a technical standpoint. However, I am equally interested in cultural fit, critical-thinking and problem-solving skills, communication style, and passion/commitment levels. In fact, if the truth be known, I would rather have someone with more of the soft skills, and raw aptitude. I can teach you library calls and syntax. I can’t begin to teach you how to communicate effectively, or how to find the path of least resistance. But I digress.

Back when I was a technical instructor I used to constantly reinforce the utility value of the single most important UNIX command/tool available: The man command. For those of you not familiar with UNIX (or Linux, BSD, et al), the “man” command allows you to access the online “manual” pages. Think of it as the UNIX equivalent of the F1 key in Windows. You can find out just about anything related to the operating system, tools, libraries, etc. with one single command. Nice. And if you don’t know what you are looking for, but you know what you are trying to achieve, the “man” command allows you to search based on keywords as well.

Instead of asking a UNIX programmer to recite all of the possible arguments to the ioctl() system call, I simply ask them to tell me what the single most important UNIX command is. If they say anything other than “man”, I start to question their ability to improvise, adapt, and overcome, as it were.

By the way, the above is a great tip for you junior UNIX techies out there. If you are ever asked a UNIX-related question that you are not sure of, just respond that you would look up the answer using “man.” Nine times out of ten you’ll get a pass.

You don’t know the answer to everything. No one does. The good news is, you don’t need to know the answer to everything. You simply need to know where to go to find the answer. Do you know where to go to find the answers you seek?



  1. Josh Watts · May 15, 2006 at 9:52 am

    Great post Scott. This really gets to the heart of what a programmer/developer/software engineer does – solve problems. In my experience, the best quality a software developer can have is the ability to process and assimilate new information. Whether it be a new language, data processing technique, or user-interface library, the trick is to gain enough knowledge and be able to use it very quickly. You won’t be an expert and you won’t have the time to create the optimized solution but most problems do not require either. Good may be the enemy of great but in 95% of software development efforts, there is a very fine line separating the two and the additional effort required to make the jump from good to great is not economically justifiable.

    Technical interviews are difficult in many cases; developers usually do not get any training in this area which leads to them to ask highly specialized questions because we don’t have anything else to talk about. We also have a tendency to think that the person we hire needs to be exactly like us. This leads to great interview discussions like the one you write about where if a person can’t discuss arcane technical minutiae, he’s shown the door and told “Don’t call us….”. It’s worth remembering that Google really changed how developers work – it’s the ultimate ‘man’ page. It’s a waste of time and effort to memorize something than can be referenced within 1-2 minutes. I wish more companies focused on using an interview to get a feeling for how a person thinks and how they arrive at a decision – this is the true essence of programming.

    I really appreciate the blog Scott – keep up the good work.

  2. Great followup, Josh.

    I especially agree with your reference to Google as the “ultimate man page.” You hit the nail on the proverbial head – it is all about problem solving. A person can recite all of the arcana they’d like, but if they can’t string 5 lines of code together to solve a problem, it is a wash.


  3. Pingback: Tte webnaplja

  4. I agree with all that has been said. Although I am commenting on this a bit late, this is a great post. Thanks for sharing!

Leave a Comment

Your email address will not be published. Required fields are marked *