by Phil Factor
I have mixed feelings about selecting a team for a development project. I’ve been so long in the industry and have played every part - from blushing young novice to hard-bitten contractor to harassed employer - that I should find the process a simple, straightforward affair. In selecting the right people to work with though, I’ve learned that the more I know the more I know what I don’t know.
One problem with selecting candidates to undertake an IT role is that so many of them write bogus resumes and lie unblushingly about their skills and experiences during the interview. In a well-ordered universe, all references would be contacted, qualifications checked, and previous employers phoned to check the story, but I have yet to inhabit this dream world. And even with these precautions, errors are made.
Making false statements regarding qualifications on a resume and thereby obtaining a job is a serious criminal offence. I’ve only heard of prosecutions against teachers or doctors, but if the police were to turn their attention to the IT industry, our prisons would be overflowing. Quite often, when employment agencies call about a job they want me to apply for, I’m asked to rewrite my resume so it fits the job requirements more closely. Occasionally, they want to do it for me.
The unworthy wunderkind
I once got a job as a SQL Server developer for a telecommunications company. The pay was good, and it was a restful job after the helter-skelter of the dot-com boom. A month after I started, the IT director rushed in excitedly, holding a resume, saying he had just interviewed, and hired, a most excellent fellow to be my team leader. Would I move my desk over to give him a cubicle commensurate with his qualifications? The name sounded vaguely familiar, but I shrugged and thought fondly of my hourly rate - the perfect panacea for stress in any contractor.
The wunderkind arrived a fortnight later. I recognized him immediately. I’d recently employed him as a C++ programmer, before his reincarnation as a database expert. He had, in fact, been a mediocre C++ programmer with a poor grasp of databases. Then he emerged, like a moth from its cocoon, as a SQL Server expert. For three months I stared at him like Macbeth’s ghost of Banquo as he messed up catastrophically. I had, of course, told the IT director, who assumed I was motivated by professional jealousy.
Programming in Croydon
In another position, I interviewed a programmer for some tricky database work that required interfacing with a variety of languages. Was he familiar with Pascal, I asked? Had he used Visual Basic? Having worked my way through the list of languages and been assured with great effusions of sincerity that he had programmed in all of them, I moved on to other questions.
Our office was located in an out-of-the-way borough of London, and, with my radar on alert from his overenthusiastic responses, I thought to ask the candidate if he minded programming in Croydon, which was, of course, the name of our town. To my surprise, he burst into a speech about his expertise with the Croydon language!
To make matters worse, when employment agencies get wind of an opening in the IT field, there’s often a feeding frenzy and the hiring manager is called repeatedly and bombarded with resumes. Over the past 20 years, I have known a good number of agents, some of whom are honest and check the resumes of their candidates. To these I send Christmas cards every year. Three extra cards is not a great expense, after all.
Some candidates go too far. One resume I reviewed stated that the applicant had two PhDs and had worked for IBM, Microsoft and a host of other large employers. I was intrigued enough to interview the man, at which time it was immediately apparent that his resume was a complete fabrication. He wasn’t old enough to have attained his alleged qualifications, let alone his work experience. His ignorance of the elementary principles of database theory was startling as well.
Questions from a wily nincompoop
After countless experiences like this, I determined that the way to weed out the poor candidates was to ask some searching technical questions. I have lost count of the times I have suffered these myself, and I know only too well that one’s brain can be reduced to jelly when having to remember a few facts that are so familiar that, outside of an interview setting, they are like remembering the names of one’s parents.
It’s monstrous to confront someone with an examination without warning, like some human resource departments did in the 1990s with their intelligence and personality tests. I always warn candidates, via their agents, that they may be asked a few relevant technical questions, but that these would not take too long.
When conducting an interview, I generally adopt the persona of a kindly, middle-aged nincompoop. I gaze at the candidate with the bonhomie one imagines Santa would adopt. Other employers adopt a sullen approach, but I try not to upset the candidate just in case he subsequently lies himself into a job from which he might one day interview me. It has happened. The following approach never seems to have caused resentment in a candidate.
The first part of the interview consists of a rather optimistic account of the company and the pleasure one would derive from working for it. After this softening-up exercise, I gaze at the candidate benignly and ask how he would rate his SQL Server skills. If I have done the first part of the interview correctly, he will tell me his skills are superb.
“Oh, good, so you wouldn’t mind answering a few simple questions about SQL Server?” I ask, with a kindly, paternalistic smile. “Nothing particularly technical, you understand, but I would like to see how you would approach a simple problem in any of the major SQL databases.”
“Of course I wouldn’t,” the candidate inevitably replies, in anticipation of being tickled with a feather duster.
The metaphorical baseball bat that I then use consists of a number of simple questions that anyone who had done serious work in SQL Server would easily tackle but which immediately seem to sort the wheat from the chaff.. In no particular order, below is a small selection of the questions I use, just to give the feel for what they are like.
You have two tables of identical structure, with some identical entries and some different entries. How would you list out the rows from one table that were not contained in the other? How might you list out all entries in either table that were not common to both tables?
Not hard, eh? There are several neat ways of doing this, all of which are valid. I’m pleased when the candidate gets the first part of the question right, and overjoyed if he gets both. More often I hear replies such as: “One would never have two identically structured tables in a database,” or “It can’t be done.”
Imagine you are in charge of a database that has a customer table with an identity field used as a primary key. You find out that this table has duplicate entries. How would you go about finding them? What strategy would you use for eliminating them? What might you need to watch out for?
A good candidate will rattle on about the various tactics that could be adopted and the pitfalls of any rash attempt at de-duplication. It must be difficult to have had experience at the sharp end of commercial database work without being faced with the task of mopping up. I get a little flush of pleasure if the prospective candidate mentions the possibility of using the “group by” clause.
You are asked to produce an accounting report that lists credits and debits in each row on a number of customer accounts, and requires a column that gives a running total for that particular account holder after the transaction. How would you tackle that?
It is always nice to hear the words “correlated subquery” in the answer, but that’s not often the case. Maybe simple financial accounting skills are not taught any more. But even if the programmer is not familiar with subqueries, it is fascinating to see how he wrestles with the problem.
In the interview, I spell out the problem in more detail, and often pull out the report so the candidate can see what I’m talking about. Many times I’m told with complete assurance that it simply isn’t possible to do what I’ve requested in SQL, and I’m given an elaborate account of creating a Java module to do it. How’s that for insight into the candidate’s work?
There’s nothing too technical in my questions. A smart database developer will do as much as he can without specific details of a particular database system or version, as this general knowledge has a long shelf life. It’s more important to know where to get the information to do the job in the shortest possible time.
Also important is an appreciation of set theory, an understanding of SQL, and insight into non-procedural programming. You would weep to know how few candidates who claim to be professional database programmers even understand the questions, let alone come up with answers. If they can tackle one question, they can generally tackle them all. And even if one question is, by a quirk of past experience, unfamiliar to them, they will come up with wonderful solutions that illustrate their essential understanding.
Works well with others?
Before one runs away with the idea that these questions represent the royal road to the ideal database developer, remember that knowledge is nothing if the candidate can’t work with the team.
At one multinational company I worked for, the resume and erudition of a new Sybase programmer dazzled the IT director. He seemed wonderful, and at least technically, he was.
Soon after he had been shown his desk in our crowded, open-plan IT office, he began laughing out loud sporadically and inappropriately while reviewing code. It wasn’t my code, so I didn’t mind. But then his strange mannerisms began, complete with bizarre, jerky arm movements. His digestion seemed to be shot to pieces, and foul air issued noisily from him. Work in the department slowed to a crawl as every neck craned to see what he would do next next.
I tried to fit the man into the team. He confided in me that fools and idiots surrounded him. He mercilessly criticized the work of his colleagues. He definitely lacked personal skills.
Finally, after he had cleared an impressive space around his cubicle, his indignation at the incompetence of his co-workers proved too much for his self-restraint.
“Look at this code,” he spluttered. “It is outrageous! I shall go and speak to the IT director!”
“Hmm. Not a good idea.”
“He must be made aware!” he said firmly and with great zeal. So off he went. The IT director made it clear to me that the man had to go. Shortly thereafter, we reclaimed our space and settled back to our former mundane harmony.
There is something to be said for top-notch technical skills on the development team, but only when combined with an affable personality and appropriate social skills.
###
Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 20 years of experience with database-intensive applications. Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.
I have mixed feelings about selecting a team for a development project. I’ve been so long in the industry and have played every part - from blushing young novice to hard-bitten contractor to harassed employer - that I should find the process a simple, straightforward affair. In selecting the right people to work with though, I’ve learned that the more I know the more I know what I don’t know.
One problem with selecting candidates to undertake an IT role is that so many of them write bogus resumes and lie unblushingly about their skills and experiences during the interview. In a well-ordered universe, all references would be contacted, qualifications checked, and previous employers phoned to check the story, but I have yet to inhabit this dream world. And even with these precautions, errors are made.
The unworthy wunderkind
I once got a job as a SQL Server developer for a telecommunications company. The pay was good, and it was a restful job after the helter-skelter of the dot-com boom. A month after I started, the IT director rushed in excitedly, holding a resume, saying he had just interviewed, and hired, a most excellent fellow to be my team leader. Would I move my desk over to give him a cubicle commensurate with his qualifications? The name sounded vaguely familiar, but I shrugged and thought fondly of my hourly rate - the perfect panacea for stress in any contractor.
Programming in Croydon
In another position, I interviewed a programmer for some tricky database work that required interfacing with a variety of languages. Was he familiar with Pascal, I asked? Had he used Visual Basic? Having worked my way through the list of languages and been assured with great effusions of sincerity that he had programmed in all of them, I moved on to other questions.
Our office was located in an out-of-the-way borough of London, and, with my radar on alert from his overenthusiastic responses, I thought to ask the candidate if he minded programming in Croydon, which was, of course, the name of our town. To my surprise, he burst into a speech about his expertise with the Croydon language!
To make matters worse, when employment agencies get wind of an opening in the IT field, there’s often a feeding frenzy and the hiring manager is called repeatedly and bombarded with resumes. Over the past 20 years, I have known a good number of agents, some of whom are honest and check the resumes of their candidates. To these I send Christmas cards every year. Three extra cards is not a great expense, after all.
Questions from a wily nincompoop
After countless experiences like this, I determined that the way to weed out the poor candidates was to ask some searching technical questions. I have lost count of the times I have suffered these myself, and I know only too well that one’s brain can be reduced to jelly when having to remember a few facts that are so familiar that, outside of an interview setting, they are like remembering the names of one’s parents.
It’s monstrous to confront someone with an examination without warning, like some human resource departments did in the 1990s with their intelligence and personality tests. I always warn candidates, via their agents, that they may be asked a few relevant technical questions, but that these would not take too long.
The first part of the interview consists of a rather optimistic account of the company and the pleasure one would derive from working for it. After this softening-up exercise, I gaze at the candidate benignly and ask how he would rate his SQL Server skills. If I have done the first part of the interview correctly, he will tell me his skills are superb.
“Oh, good, so you wouldn’t mind answering a few simple questions about SQL Server?” I ask, with a kindly, paternalistic smile. “Nothing particularly technical, you understand, but I would like to see how you would approach a simple problem in any of the major SQL databases.”
“Of course I wouldn’t,” the candidate inevitably replies, in anticipation of being tickled with a feather duster.
The metaphorical baseball bat that I then use consists of a number of simple questions that anyone who had done serious work in SQL Server would easily tackle but which immediately seem to sort the wheat from the chaff.. In no particular order, below is a small selection of the questions I use, just to give the feel for what they are like.
You have two tables of identical structure, with some identical entries and some different entries. How would you list out the rows from one table that were not contained in the other? How might you list out all entries in either table that were not common to both tables?
Not hard, eh? There are several neat ways of doing this, all of which are valid. I’m pleased when the candidate gets the first part of the question right, and overjoyed if he gets both. More often I hear replies such as: “One would never have two identically structured tables in a database,” or “It can’t be done.”
Imagine you are in charge of a database that has a customer table with an identity field used as a primary key. You find out that this table has duplicate entries. How would you go about finding them? What strategy would you use for eliminating them? What might you need to watch out for?
You are asked to produce an accounting report that lists credits and debits in each row on a number of customer accounts, and requires a column that gives a running total for that particular account holder after the transaction. How would you tackle that?
It is always nice to hear the words “correlated subquery” in the answer, but that’s not often the case. Maybe simple financial accounting skills are not taught any more. But even if the programmer is not familiar with subqueries, it is fascinating to see how he wrestles with the problem.
In the interview, I spell out the problem in more detail, and often pull out the report so the candidate can see what I’m talking about. Many times I’m told with complete assurance that it simply isn’t possible to do what I’ve requested in SQL, and I’m given an elaborate account of creating a Java module to do it. How’s that for insight into the candidate’s work?
There’s nothing too technical in my questions. A smart database developer will do as much as he can without specific details of a particular database system or version, as this general knowledge has a long shelf life. It’s more important to know where to get the information to do the job in the shortest possible time.
Also important is an appreciation of set theory, an understanding of SQL, and insight into non-procedural programming. You would weep to know how few candidates who claim to be professional database programmers even understand the questions, let alone come up with answers. If they can tackle one question, they can generally tackle them all. And even if one question is, by a quirk of past experience, unfamiliar to them, they will come up with wonderful solutions that illustrate their essential understanding.
Works well with others?
Before one runs away with the idea that these questions represent the royal road to the ideal database developer, remember that knowledge is nothing if the candidate can’t work with the team.
At one multinational company I worked for, the resume and erudition of a new Sybase programmer dazzled the IT director. He seemed wonderful, and at least technically, he was.
Soon after he had been shown his desk in our crowded, open-plan IT office, he began laughing out loud sporadically and inappropriately while reviewing code. It wasn’t my code, so I didn’t mind. But then his strange mannerisms began, complete with bizarre, jerky arm movements. His digestion seemed to be shot to pieces, and foul air issued noisily from him. Work in the department slowed to a crawl as every neck craned to see what he would do next next.
I tried to fit the man into the team. He confided in me that fools and idiots surrounded him. He mercilessly criticized the work of his colleagues. He definitely lacked personal skills.
Finally, after he had cleared an impressive space around his cubicle, his indignation at the incompetence of his co-workers proved too much for his self-restraint.
“Look at this code,” he spluttered. “It is outrageous! I shall go and speak to the IT director!”
“Hmm. Not a good idea.”
“He must be made aware!” he said firmly and with great zeal. So off he went. The IT director made it clear to me that the man had to go. Shortly thereafter, we reclaimed our space and settled back to our former mundane harmony.
There is something to be said for top-notch technical skills on the development team, but only when combined with an affable personality and appropriate social skills.
###
Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 20 years of experience with database-intensive applications. Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.
No comments:
Post a Comment