19.09.2015 Views

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!