Cramming for Interviews

  • majorbloodnock (1/15/2013)


    GSquared (1/15/2013)


    majorbloodnock (1/15/2013)


    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.

    IMHO, of course.....

    Pretty much matches the interview process I prefer when I'm managing.

    I pay minimal attention to skillsets I can't verify, but aim for honest, intelligent, and energetic. I can turn that kind of person into any sort of technical expert I need, regardless of their resume experience or lack thereof. Can't turn educated but dishonest into anything useful.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • GSquared (1/15/2013)


    majorbloodnock (1/15/2013)


    GSquared (1/15/2013)


    majorbloodnock (1/15/2013)


    Gary Varga (1/15/2013)


    ....

    ....

    ....

    ....

    Pretty much matches the interview process I prefer when I'm managing.

    I pay minimal attention to skillsets I can't verify, but aim for honest, intelligent, and energetic. I can turn that kind of person into any sort of technical expert I need, regardless of their resume experience or lack thereof. Can't turn educated but dishonest into anything useful.

    Agree totally. Skills can be taught, but attitude cannot.

    Semper in excretia, suus solum profundum variat

  • Let me try working through a few variables on this one!

    If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)

    If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out!

    If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation?

    How about the many different degrees of competence on either of the interview participants part? How does that pan out?

    Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions!

  • patrickmcginnis59 (1/15/2013)


    Let me try working through a few variables on this one!

    If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)

    It's usually pretty easy to spot most interview questions on the forums. Not always, but it doesn't take any particular perception skills to know that, "What are the differences between temp tables and table variables?" is frequently an interview question. Can be a valid forum question, in which case, answering it the next day works for a valid question, and defeats the interview-hack (the interview is probably long-since over). Foolproof? Nope. But it's probably as good as we'll get on this situation.

    If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out!

    That works. If you think it's a test/homework/interview question, ask. I do that pretty frequently. Again, delaying the answer by a bit is usually enough to make it still valuable to someone who's on the forums to learn, and to defeat the purpose of a cheat.

    If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation?

    The interviewer isn't usually trying to defraud anyone. They're doing their best effort to fix a business-problem by paying for expertise. Not always the case, but it is most of the time. It would be dishonest of a business to hire someone and then not pay them, but it's not dishonest of them to hire someone to fill a gap in their knowledge assets. It's difficult, and has risks, but it's honest. Trying to interview for a job you can't actually do is inherently dishonest. It's trying to take money from someone without providing any value to them. Definition of fraud/theft/scam.

    How about the many different degrees of competence on either of the interview participants part? How does that pan out?

    Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions!

    We can't catch every attempt. Some will be more clever than we can deal with in this medium. No way around that. Something like 80% of all murders in the US go unsolved every year, and a lot more effort and expertise goes into those than will ever go into trying to catch out interview/exam cheats, and for darn good reason (not even vaguely the same order of magnitude). So I'm sure we miss quite a few. But that's not a valid reason to ignore the ones we could prevent, or at least call-out.

    Generally, I start out by trusting everyone. Assume that even seemingly dishonest/unscrupulous looking activities are probably not because of actual intent. Life is more pleasant when you assume you can trust people till proven otherwise. But I will ask, "This looks like an interview question. Is it?", if it does look that way. And quite a few people will admit that it is, and then I'll work with them so they can learn for future interviews. I'll refer them to source material (usually MSDN or TechNet) that they can study for their next go. Most often, even the people who are trying to "cheat", will straighten out when confronted on it. Only about 2.5-3% of humanity is willfully criminal, but some of the rest need some guidance on matters of ethics, etc.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • As those that have come to know me over the years will tell you, this is a REALLY sore spot with me especially for people that have alphabet soup after their name.

    I can absolutely guarantee that there is no way to "cram" for a "Jeff Moden" interview. Although I don't ask difficult questions, I can guarantee that only a couple of the questions I ask are actually on one of those God forsaken interview question blogs. Those are used as "warmup" guestions to get the inteviewer to relax because everybody knows the answers. After that, you're required to actually think or show what you've actually done in the past in the form of thoughful dialog.

    I used to be incensed by people that published those damned interview questions and even more incensed by moroffs that used them for anything other than, perhaps, a study guide of what they need to try, practice, and verify. Then, it dawned on me that a good number of those bloody sites had some really stupid and incorrect answers and so decided that I'd not correct the answers nor even acknowledge that some of the answers were wrong. In fact, I've taken to using those incorrectly answered questions as the warmup questions. Lord help the gamers that come to an interview with me and give me one of those incorrect answers. We will find out if they like high velocity pork chops or not.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I'm mostly a production DBA. Keep 'em up, running and tuned. I'm also responsible for front line troubleshooting of our software, and database issues. I've done about 15 different DB systems from dBase III to Oracle and MS SQL. I also can program fairly well in VBA, T-SQL, and SQLPlus. I've also done batch files, VBScript and touched other languages as needed.

    I've been in interviews where the DBA's interviewing me were Oracle, but I can answer in their language as well.

    Now I am occasionally on the tech interviewer side. The first question I generally hit a DBA interviewee with is "What do 'DDL' and 'DML' stand for?" Then I start to delve into the DML command side. I have as yet to get to the DDL with a junior DBA. I'll also hit them with recovery models and such.

    If they have no clue, but show intelligence and honesty in their answers -- I can deal with that. I can train them. If they can't even retain the DML commands after I give them the answer -- they are a waste of time. It's a question of how to end the interview gently.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Jim P. (1/15/2013)


    I'm mostly a production DBA. Keep 'em up, running and tuned. I'm also responsible for front line troubleshooting of our software, and database issues. I've done about 15 different DB systems from dBase III to Oracle and MS SQL. I also can program fairly well in VBA, T-SQL, and SQLPlus. I've also done batch files, VBScript and touched other languages as needed.

    I've been in interviews where the DBA's interviewing me were Oracle, but I can answer in their language as well.

    Now I am occasionally on the tech interviewer side. The first question I generally hit a DBA interviewee with is "What do 'DDL' and 'DML' stand for?" Then I start to delve into the DML command side. I have as yet to get to the DDL with a junior DBA. I'll also hit them with recovery models and such.

    If they have no clue, but show intelligence and honesty in their answers -- I can deal with that. I can train them. If they can't even retain the DML commands after I give them the answer -- they are a waste of time. It's a question of how to end the interview gently.

    Just curious, do you expect DBAs to have the syntax of the various DML statements memorized?

  • Lynn Pettis (1/15/2013)


    Just curious, do you expect DBAs to have the syntax of the various DML statements memorized?

    No. I just expect them to know the DML verbs at least. The general syntax doesn't hurt. I just want the verbs. And TRUNCATE I consider more of a DDL than a DML, and is not really a DML statement..

    The syntax is sort of DB specific. But the same four DML verbs are pretty consistent among the SQL-92 standard languages.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Jim P. (1/15/2013)


    Lynn Pettis (1/15/2013)


    Just curious, do you expect DBAs to have the syntax of the various DML statements memorized?

    No. I just expect them to know the DML verbs at least. The general syntax doesn't hurt. I just want the verbs. And TRUNCATE I consider more of a DDL than a DML, and is not really a DML statement..

    The syntax is sort of DB specific. But the same four DML verbs are pretty consistent among the SQL-92 standard languages.

    Okay, just curious. I had a phone interview a while back (about a year) and I am pretty sure I didn't get a call back because I couldn't list off the DBCC Commands, even though I told them I would look them up in Books Online if I needed them.

  • patrickmcginnis59 (1/15/2013)


    Let me try working through a few variables on this one!

    If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)

    If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out!

    If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation?

    How about the many different degrees of competence on either of the interview participants part? How does that pan out?

    Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions!

    The posts from GSquared and Jeff Moden have covered pretty well the detail of what you've outlined, but I can't help thinking this is missing the point a bit. It may, of course, be a simple difference of interpretation, but I didn't read the editorial as an attempt to make all SSC members into interview police. All I saw was a blatant message to cheats that they're doing no-one any favours, and a secondary message to SSC members encouraging them to temper their natural helpfulness with a modicum of worldliness.

    Yes, there is, and always will be, quite a bit of game play going on. DBAs are well paid generally, so there will always be some who want to muscle in on the lucrative side before their experience warrants it. Same with most good careers. None of us will be able to stop it, but we don't have to make it unnecessarily easy for fraudsters.

    Semper in excretia, suus solum profundum variat

  • Lynn Pettis (1/15/2013)


    Okay, just curious. I had a phone interview a while back (about a year) and I am pretty sure I didn't get a call back because I couldn't list off the DBCC Commands, even though I told them I would look them up in Books Online if I needed them.

    I've been doing SQL for 10+ years and I don't know many of the DBCC commands offhand and their syntax. That they expect you to know them well means that someone is doing way too much DR work. :w00t:

    The position a production DBA should be able assume on a regular basis is feet up on the desk, cup of coffee at hand and listening to the latest podcast from Steve Jones. 😀



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • majorbloodnock (1/16/2013)


    patrickmcginnis59 (1/15/2013)


    Let me try working through a few variables on this one!

    If the interviewee is going to fool a completely competent and prepared interviewer, he's going to fool the SQL forums and get his answers. (I'm obviously mistakenly ommitting the geniuses here who will see through every scheme no matter how sophisticated by the sheer power of their perception, but in that case I'm an ordinary joe that can subsequently answer questions the faker posts because well I'm an ordinary joe and Steves advice does not apply to me in this case.)

    If the interviewee is not going to fool a completely competent and prepared interviewer, will he fool the SQL forums and get his answers? If I find him out, I'm going to answer him but tell him it sounds like he wants to cheet and will probably fail because if I'm an ordinary joe unskilled in HR and spotted his dastardly scheme, the competent HR department will surely find him out!

    If the interviewee is going to have an incompetent and unprepared interviewer, do we reward incompetence and lack of preparation by refusing to answer questions in order to protect the incompetent and unprepared interviewer? Or might this somehow dilute free market forces that would otherwise penalize incompetence and lack of preparation?

    How about the many different degrees of competence on either of the interview participants part? How does that pan out?

    Additionally, if an applicant is truly dishonest (and especially good at being dishonest), are we saying he's going to fool the interviewer but not the forum participants? Heck, he's got an easier job fooling forum participants because by definition in his participation here he's not providing answers, he's formulating questions!

    The posts from GSquared and Jeff Moden have covered pretty well the detail of what you've outlined, but I can't help thinking this is missing the point a bit. It may, of course, be a simple difference of interpretation, but I didn't read the editorial as an attempt to make all SSC members into interview police. All I saw was a blatant message to cheats that they're doing no-one any favours, and a secondary message to SSC members encouraging them to temper their natural helpfulness with a modicum of worldliness.

    Yes, there is, and always will be, quite a bit of game play going on. DBAs are well paid generally, so there will always be some who want to muscle in on the lucrative side before their experience warrants it. Same with most good careers. None of us will be able to stop it, but we don't have to make it unnecessarily easy for fraudsters.

    Thanks for the well considered response!

    The subject was pretty easy to reach a conclusion on, it wasn't a hard subject to play out in my mind. I'm not going to spot the really skilled cheaters, I'm not going to sweat the comically bad cheaters and I'm going to insist that the focus needs to be on the hiring process from the point of view of the hirer. I think Jeff actually has the best take on this, and I wish more folks would focus on that side of the process rather than letting the interviewers off the hook unconditionally.

    I know that in modern times management is considered a skill in itself, but can we really be effective managers without the ability to at least research the tasks that our employees will be engaged in? Or is this just somehow out of style nowadays? Sounds like maybe thats what I need to consider from Steve's post, and maybe he's just in a roundabout manner giving me some bad news in this department. I can certainly now accept that for my own consideration!

  • Patric, normally I'd treat private as private. You're the only person I've ever moved it public for. And it's only because I find your particular behavior so reprehensible that I feel that helping you hide that kind of hatefulness would be a mistake. I feel that others need the warning about your behavior, so that they can at least be informed before you attack them. Kind of like the "do not play on or around" signs on trash compactors.

    I know you think you're the innocent party here. That's normal for your personality type. You belittle, insult, ridicule, and then claim that you were the one wronged by a person who confronts you on any of that. It's normal for you. I understand that. But there's just no way I'm going to stand aside and let you attack people with impunity. I don't stand for attempted bullying. Not of me, not of anyone.

    Others will need to judge whether they think I'm the aggressor here. That's why I present the data I do. People will come to their own conclusions. Some may decide that I'm the problem. I hope not, but it's their judgement to make, and my job in that is simply to provide them with the most accurate data I can on our interactions and on all of my thousands of interactions with others (besides you) on these forums. As needed, I can provide full and complete context, including timeline, etc. If Steve or anyone else wants that, I'll provide it without the slightest qualm.

    I don't expect you to change your behavior because of anything I do or post. But I do hope that anyone reading this is warned what kind of person you are, and thus doesn't get hurt by your bullying. These posts aren't for you, they're for anyone else who reads them.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • On the topic of cramming for interviews, I have an experience I'd like to share. At my office, we do semi-technical phone screens before we bring the person in for a face-to-face interview, to save everybody's time if the candidate isn't up to snuff. One guy we screened had an 8-page resume that made him look like a SQL Server guru. Did amazingly well on the phone screen. When he showed up in person, he didn't know the first thing about SQL Server. The interview was over in about 3 minutes, because he could not answer the most basic questions (for example, didn't know what a stored procedure was, didn't know what normalization was). Apparently, he got somebody else to take the phone screen for him!

    Side note: why does anybody need an 8-page resume? I find anything more than 2 pages tedious to read. Anything more than 4 pages, I'm inclined to send it to the recycle bin, because most of the times it's repetition and difficult to read and badly formatted and just not worth the time.

    Hakim Ali
    www.sqlzen.com

  • hakim.ali (1/16/2013)


    On the topic of cramming for interviews, I have an experience I'd like to share. At my office, we do semi-technical phone screens before we bring the person in for a face-to-face interview, to save everybody's time if the candidate isn't up to snuff. One guy we screened had an 8-page resume that made him look like a SQL Server guru. Did amazingly well on the phone screen. When he showed up in person, he didn't know the first thing about SQL Server. The interview was over in about 3 minutes, because he could not answer the most basic questions (for example, didn't know what a stored procedure was, didn't know what normalization was). Apparently, he got somebody else to take the phone screen for him!

    Side note: why does anybody need an 8-page resume? I find anything more than 2 pages tedious to read. Anything more than 4 pages, I'm inclined to send it to the recycle bin, because most of the times it's repetition and difficult to read and badly formatted and just not worth the time.

    Definitely an interesting one! Makes me curious what he thought would happen when he showed up and suddenly didn't know the things that "he" knew on the phone. Did he not expect to have more questions? Interesting.

    And totally agree on the resume bit. At the very least, summarize in about half a page right at the beginning of the thing. There are people with extensive work histories, especially if they've done a lot of short-term contracts (nothing wrong with that, of course), but it needs a brief summary up front.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Viewing 15 posts - 16 through 30 (of 49 total)

You must be logged in to reply to this topic. Login to reply