The database mole

Bogus resumes and unblushing lies: navigating the database hiring waters and selecting a development team.

Bogus resumes and unblushing lies: navigating the database hiring waters

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.

Tags: , , , ,


  • Rate
    [Total: 31    Average: 4.5/5]
  • Anonymous

    Bogus resumes
    Simply hilarious. I’ve sent a link to at least five friends.

  • Phil Factor

    Bogus Resumes
    Bless you, and thank you for those kind words. I’m pleased that you enjoyed this.

    I’ve just noticed that some of the formatting of this article got lost in the transfer. In particular, the interview questions should be in quotes and indented. Hopefully we’ll get it fixed soon!

  • Anonymous

    Bogus Resumes

    As a database programmer, I’ve met and read some questions and articles posted at certain sites with absolute horror. What exacerbates the content is that the authors claim to be gurus in the subjects.

    Thanks for the great article.


  • Anonymous

    Great Stuff
    Made me Google for a solution to the accounting problem. Great answer at (circa 2001 but relevant today!)

  • Anonymous

    But Why?
    In 6 years as a permie and 20 years as a contractor I’ve only ever been asked something technical on 3 occasions. This simply amazes me. Are interviewers too embarrassed or too ignorant? Or a bit of both?

    The first was for my first job with CAP Scientific (long gone) when I was privileged to be interviewed by their top technical man (Dr Mike Christie). The best he could come up with was “Could I define the mean and standard deviation of a population?”. Since I’d just been teaching maths to A level and Oxbridge scholarship students for the previous 2 years (probably the best use I’ve ever made of my Oxford maths degree), I burst out laughing and told him. He blushed and basically echoed the message above – people habitually lie in their CVs and in interviews – even 26 years ago!

    The toughest technical question (4 years later) was could I describe an algorithm for calculating Atan(x) on a 16-bit processor. Since I just told my interviewer that that was the toughest thing I’d had to do on my then current project (working on the FMCS for Airbus A310) it was a very fair question, not too difficult for me in the circumstances and a good test of whether I’d been telling porkies (I regret to say I wouldn’t have been able to work it out from first principles under pressure). What I didn’t tell him, though, was that the reason the algorithm was damned clever was that we’d hacked Intel’s microcode (on the 8087) and used their algorithm ;-). His deflationary response was that he’d have just used a look-up table.

    The third question (just 8 years ago and reflecting the declining technical standards in the business) was could I write some pseudo-code to generate prime numbers. That took about two minutes but then I had to explain what the Sieve of Eratosthenes is, which probably took longer. Sad.

  • Josh

    This is a great little article Phil. I myself am a university student enrolled in a co-op program where I must adopt a new job every other term. Because of this, I have to go through volleys of interviews regularly. This article really gives me a sense of what it’s like at the other end of the desk.

  • Anonymous

    the famous 3 years’ past comment
    Not a long while ago, I’ve been tasked with coming up with like-wise questions but further more to define each with a single good answer. It’s an interesting exercice because I think we suffer from a tunnel view about the past. After 14 years in DB: group by Pk having count(*) > 1 to identify repeating tuples seems at best an intermediate level question and answer.

    But trying to come up with at least a real tough one, I looked at my current code library and found one dealing with unicity of non-contiguous time range. Looking at it to try to find a way to formulate the problem, I found two better solutions/optimizations. I had to tell my boss, listen I can make a series of questions but I will have to be present in interviews to evaluate answers because each problems has many answers.

    Obviously, the whole exercice is to find someone to replace me so my question list was shelved.

    I am now the proud leader of three juniors that were all -one after another- hired to replace me and my growing team.

    In the end, it will surely work because I will not be a dba/developper anymore but just a team-leader of slugs.

  • A E

    It is funny, but everything depends on expectations of both sides
    Hi Phil

    Humans are deprived of self evaluation ability. Our brains neuro-network returns search/decision results based on our focus, so we honestly believe that if we focus hard we can solve any problem in our live. The only complain is lack of memory abilities, but it can be compensated by books we heard about before. So as a result our problem complexity vision inversely depends on lack of actual knowledge.

    Yes, there are two approaches in interviewing, raise knowledge bar to the skies, so if candidate not capable to match, he/she just kicked out.
    In this case if you don’t mind to stay without any candidates at all, it is absolutely fine.

    And another approach is exactly your way is bombarding with trivial questions, so it helps to better arrange candidates, but it does not guarantee that those who pass your selection are properly sorted.

    What do you think about latest trend which is called "checking candidates ability to speak up"?