Confessions of an IT Manager_Phil Factor
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Section IV: Hiring, Firing <strong>an</strong>d other acts <strong>of</strong> Villainy 179<br />
particular order, below is a small selection <strong>of</strong> the questions I use, just to give<br />
the feel for what they are like.<br />
You have two tables <strong>of</strong> identical structure, with some identical entries <strong>an</strong>d<br />
some different entries. How would you list out the rows from one table that<br />
were not contained in the other? How might you list out all entries in either<br />
table that were not common to both tables?<br />
Not hard, eh? There are several neat ways <strong>of</strong> doing this, all <strong>of</strong> which are<br />
valid. I'm pleased when the c<strong>an</strong>didate gets the first part <strong>of</strong> the question right,<br />
<strong>an</strong>d overjoyed if he gets both. More <strong>of</strong>ten I hear replies such as: "One would<br />
never have two identically structured tables in a database," or "It c<strong>an</strong>'t be done."<br />
Imagine you are in charge <strong>of</strong> a database that has a customer table with <strong>an</strong><br />
identity field used as a primary key. You find out that this table has duplicate<br />
entries. How would you go about finding them? What strategy would you use<br />
for eliminating them? What might you need to watch out for?<br />
A good c<strong>an</strong>didate will rattle on about the various tactics that could be<br />
adopted <strong>an</strong>d the pitfalls <strong>of</strong> <strong>an</strong>y rash attempt at de-duplication. It must be<br />
difficult to have had experience at the sharp end <strong>of</strong> commercial database work<br />
without being faced with the task <strong>of</strong> mopping up. I get a little flush <strong>of</strong> pleasure<br />
if the prospective c<strong>an</strong>didate mentions the possibility <strong>of</strong> using the 'group by'<br />
clause.<br />
You are asked to produce <strong>an</strong> accounting report that lists credits <strong>an</strong>d debits in<br />
each row on a number <strong>of</strong> customer accounts, <strong>an</strong>d requires a column that gives a<br />
running total for that particular account holder after the tr<strong>an</strong>saction. How would<br />
you tackle that?<br />
It is always nice to hear the words 'correlated subquery' in the <strong>an</strong>swer, but<br />
that's not <strong>of</strong>ten the case. Maybe simple fin<strong>an</strong>cial accounting skills are not<br />
taught <strong>an</strong>y more. But even if the programmer is not familiar with subqueries, it<br />
is fascinating to see how he wrestles with the problem.<br />
In the interview, I spell out the problem in more detail, <strong>an</strong>d <strong>of</strong>ten pull out<br />
the report so the c<strong>an</strong>didate c<strong>an</strong> see what I'm talking about. M<strong>an</strong>y times I'm told<br />
with complete assur<strong>an</strong>ce that it simply isn't possible to do what I've requested<br />
in SQL, <strong>an</strong>d I'm given <strong>an</strong> elaborate account <strong>of</strong> creating a Java module to do it.<br />
How's that for insight into the c<strong>an</strong>didate's work?<br />
There's nothing too technical in my questions. A smart database developer<br />
will do as much as he c<strong>an</strong> without specific details <strong>of</strong> a particular database<br />
system or version, as this general knowledge has a long shelf life. It's more<br />
import<strong>an</strong>t to know where to get the information to do the job in the shortest<br />
possible time.