A reasonable interview will test deeper understanding, however, the biggest problem is that some interviews are conducted so poorly these people that "learn by cramming" sometimes succeed. If they didn't then it wouldn't be worthwhile trying it on and therefore wouldn't be an issue.

Gary Varga (1/15/2013)A reasonable interview will test deeper understanding, however, the biggest problem is that some interviews are conducted so poorly these people that "learn by cramming" sometimes succeed. If they didn't then it wouldn't be worthwhile trying it on and therefore wouldn't be an issue.

To an extent, I agree. Cramming only helps with facts, and detailed facts at that. It doesn't do anything for understanding concepts. The value of a decent DBA is their ability to understand concepts and theory, and put that understanding into practice, so that's what an interview should be attempting to tease out.

That said, this world is full enough of charlatans as it is, so whilst I'm tempted to say any blagger and any company lax enough to hire them deserve each other, I certainly wouldn't want to do anything to help introduce them. After all, despite my best efforts, it may be my details they end up working on.

Misrepresenting one's skills and/or knowledge does a disservice to everyone involved. I once found myself in a position where the new employer misrepresented my skills to the rest of the organization - essentially set me up for failure with my new co-workers before I ever set foot in the door. Although I was eventually able to do the job, the long-term effect was a lot of bad attitude. Consequently I have a tendency to "undersell" myself ever since.

Gary Varga (1/15/2013)A reasonable interview will test deeper understanding, however, the biggest problem is that some interviews are conducted so poorly these people that "learn by cramming" sometimes succeed. If they didn't then it wouldn't be worthwhile trying it on and therefore wouldn't be an issue.

To an extent, I agree. Cramming only helps with facts, and detailed facts at that. It doesn't do anything for understanding concepts. The value of a decent DBA is their ability to understand concepts and theory, and put that understanding into practice, so that's what an interview should be attempting to tease out.

That said, this world is full enough of charlatans as it is, so whilst I'm tempted to say any blagger and any company lax enough to hire them deserve each other, I certainly wouldn't want to do anything to help introduce them. After all, despite my best efforts, it may be my details they end up working on.

The problem with the part I added emphasis to, is that quite often a company needs to hire a DBA because they don't have anyone who knows anything significant about the subject. So they really can't effectively screen against fraudulent interviewees.

The usual answer I see on that one is, "pay someone to do the tech screening for you". But how can a company know whether or not the person/company doing the tech screening knows their business or not?

I've had technical interviews by people, frequently at recruiting companies, who quite obviously didn't know SQL well enough to detect whether I did or not. Questions like, "why are table variables faster than temp tables", and when I reply that they aren't, and provide details on why, and explain that it's a "DBA urban legend", they start to look like deer in the headlights. I swear, when those people ask their second question (usually, "what recovery models do SQL databases have"), I could tell them that "SQL Server doesn't actually use recovery models. It uses azimuths generated by flux capacitors to power the warp coils for wormhole navigation", and they'd be so intimidated by the reply to the first question that they'd believe me.

So how can a normal small business tell? That's why so many small businesses end up with people who can baffle with BS instead of actually competent technical personnel. See it all the time.

Gary Varga (1/15/2013)A reasonable interview will test deeper understanding, however, the biggest problem is that some interviews are conducted so poorly these people that "learn by cramming" sometimes succeed. If they didn't then it wouldn't be worthwhile trying it on and therefore wouldn't be an issue.

To an extent, I agree. Cramming only helps with facts, and detailed facts at that. It doesn't do anything for understanding concepts. The value of a decent DBA is their ability to understand concepts and theory, and put that understanding into practice, so that's what an interview should be attempting to tease out.

That said, this world is full enough of charlatans as it is, so whilst I'm tempted to say any blagger and any company lax enough to hire them deserve each other, I certainly wouldn't want to do anything to help introduce them. After all, despite my best efforts, it may be my details they end up working on.

The problem with the part I added emphasis to, is that quite often a company needs to hire a DBA because they don't have anyone who knows anything significant about the subject. So they really can't effectively screen against fraudulent interviewees.

The usual answer I see on that one is, "pay someone to do the tech screening for you". But how can a company know whether or not the person/company doing the tech screening knows their business or not?

I've had technical interviews by people, frequently at recruiting companies, who quite obviously didn't know SQL well enough to detect whether I did or not. Questions like, "why are table variables faster than temp tables", and when I reply that they aren't, and provide details on why, and explain that it's a "DBA urban legend", they start to look like deer in the headlights. I swear, when those people ask their second question (usually, "what recovery models do SQL databases have"), I could tell them that "SQL Server doesn't actually use recovery models. It uses azimuths generated by flux capacitors to power the warp coils for wormhole navigation", and they'd be so intimidated by the reply to the first question that they'd believe me.

So how can a normal small business tell? That's why so many small businesses end up with people who can baffle with BS instead of actually competent technical personnel. See it all the time.

Hmmm. Yes and no.

You're quite right, of course, that I was being overly flippant, and I hold my hands up; guilty as charged.

However, there still exists the problem of how a company needing skills about which they've no prior experience can successfully interview. I was certainly being unfair to label them as lax by lumping them straight in with those that only go through the motions. However, I'll argue that if you don't have the technical expertise to spot a blagger, you shouldn't attempt to perform a technical interview per se; if you do, you effectively become another blagger and it's just a contest of who blags the best. I'd argue instead that the company should concentrate rather harder on understanding the candidate's attitude and outlook, and scrutinising closely their past professional experience. In short, interview harder in the areas you really are qualified to judge. If you can enlist outside help to judge technical excellence, great. Ditto if you can find any other way to give you an interviewing edge.

Personally, I see a lot of small companies balk at the cost of a DBA, so try to enter into the world of databases on the cheap by trying to take on someone who's only starting out in that area. It's arguably better value to look for someone with quantifiable prior experience which, whilst not eliminating the risk, swings the odds more in your favour that you'll get someone at least half competent.

I agree to the article highlighted by you. The best example I can see i sme. Not long ago when I started my career into SQL Server it seemed like an ocean( which it is still .. ), a simple error like "ambigous column name" seemed something like alien. I did crammped a lot of book, but they seemed like homepathic medicine, though they would be effective but did not knew when. It was until when I started answering the QOtD that I started to understand what it exactly meant.And I must confess that I answered all questions wrongly and learnt a lot from the discussions.I would like to extend my heart-felt thanks to the whole SQL Server Central team for this, even though I am not a master but I am able to answer and undesratnd the nuances of SQL Server better than before.

Cramming even though is a strategy to learn, but it the interest that will help you to pin until the last drop.