Rajesh Jayaraman

Interviews - Fact and Opinion

I have been involved with quite a few interviews of late, attending some, conducting some. So I can make out the difference between a good interview and a bad one pretty well.

Technical interviews can take many forms. But broadly, you have interviews which test your knowledge and interviews which test your skill. Of course, in order to perform well as a programmer, you need to have both.

A carpentar needs to know how to use a saw and a file equally well in order to perform his job. Knowing Java and C++ are in the same league. The provide you with a set of tools to do your job as a programmer.

But building the table is more than just knowing these tools. Building a table requires you to know how to saw the wood to shape, how to take measurements, how to fix them and also how to do so with the least wastage of wood. It is also critical for the carpentar to know which tool to use when, and which wood to use where and what compromises can be made for certain parts of the table.

So also, a programmer need to understand when to use a reference instead of a pointer, a tree instead of a hash. She (;-)) also needs to know how to use inheritance and aggregation together to make an object graph. She must know what design patterns to use under what conditions and must be able to code them too.

Of course, you have carpentars who don't know the difference between a saw an a see-saw. Like this guy I interviewed, who said a pointer is a Star (*) and a reference is an And(&). Well, thats definitely one difference!

The issue is not whether the programmer knows how to use pointers and references and when to use either. The programmer needs to know both. This much an interviewer should ensure. That the programmer knows how to use the basic tools really well and has the discretion to know when to use either. So far, skill and knowledge are both required.

But if you want to run a quality software shop, you need to go further than that. The basic tools and the basic approaches are not sufficient. Here is where we must diverge.
Using the same carpentar analogy, should a carpentar know how to use a double-sided saw (if such a thing exists) even if it is something that you use only once a year or probably never. Or should he rather know how to make an efficient dovetail.

In programmers parlance, the former might take the shape of knowing whether u know everything about a particular library, while the latter takes the shape of whether you can think through building a more efficient data structure.

The former requires knowledge. He needs to have read about the double edged saw, or used one (which might be rarer). The latter requires an application of the mind on the spot. No amount of reading can tell you how to build a dovetail for a specifc scenario, or build a data structure for a particular situation.

Given that a programmer generally has full command over only the tools that he continuously uses, and given the fact that she has only so much time, the interviewer and the organization need to make a choice. Whether you want a person who has a lot of knowledge or a lot of skill?

Given the rate at which technologies come and go, I would say, bet on skill. The specialized knowledge can be picked up by googling for what you want.

blog comments powered by Disqus