A Little Interviewing Advice

  • Revenant (7/3/2011)


    TravisDBA (7/2/2011)


    . . . I have never gotten the real answer from an employer during an interview as to why the prior DBA left the position until after I was hired and a coworker told me. . . .

    If they told you, the previous DBA could sue them for $100k plus legal expenses.

    Welcome to today's litigious America. (And that includes both the US and Canada.)

    No kidding Sherlock? Hence the statement I made "they lie as a matter of policy." They do this as a matter of policy to cover their bases legally. The real point I was trying to make here is that they practice deception in interviews, for a lot of different reasons, this is just one reason. It isn't just about prospective candidates practicing deception. It's definitely a two way street, as Steve alluded to in his editorial. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • I am a newbie in database administration, as much as I try to be honest about what I know/don't know, this is when I couldn't get a job. My intention is to let my potention employer know what I don't know but I do emphasis that I am keen to learn, which I do. But most of the time I will not get a job if I do this.

  • Lee San (7/10/2011)


    I am a newbie in database administration, as much as I try to be honest about what I know/don't know, this is when I couldn't get a job. My intention is to let my potention employer know what I don't know but I do emphasis that I am keen to learn, which I do. But most of the time I will not get a job if I do this.

    You will, when I am the interviewer.

  • Lee San (7/10/2011)


    I am a newbie in database administration, as much as I try to be honest about what I know/don't know, this is when I couldn't get a job. My intention is to let my potention employer know what I don't know but I do emphasis that I am keen to learn, which I do. But most of the time I will not get a job if I do this.

    You might get the job, but odds are you won't hold it long. I can't tell you how many times DBA's didn't make their probation period because they either lied or exagerated their skill set on their resume, or in their interview. Usually with people who did not interview with me, because I usually can catch this in the interview with a few pointed questions that are not found on the Internet. Try explaining that on your resume why you didn't even make 3 months on your last job.... Even if you don't list the job on your resume, you still have to account for the time out of work. It's just better to be honest up front sbout what you don't know, at least in my book anyway. What you know might outweigh what you don't know, and if I know what you don't know up front I can handle/compensate that in various ways on the job. What I can't deal with is lying, because I can't prepare for what you are not telling me correctly, kapish? Anyway, you don't want to start out in a DBA position in a very crucial high volume shop by lying. If people figured you will lie once, you will do it again, and on the job that could really be disastrous. I cut those kind of people loose real quick...:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • TravisDBA (7/11/2011)


    Lee San (7/10/2011)


    I am a newbie in database administration, as much as I try to be honest about what I know/don't know, this is when I couldn't get a job. My intention is to let my potention employer know what I don't know but I do emphasis that I am keen to learn, which I do. But most of the time I will not get a job if I do this.

    It's just better to be honest up front sbout what you don't know, at least in my book anyway.

    Which is exactly what he says he does.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (7/12/2011)


    TravisDBA (7/11/2011)


    Lee San (7/10/2011)


    I am a newbie in database administration, as much as I try to be honest about what I know/don't know, this is when I couldn't get a job. My intention is to let my potention employer know what I don't know but I do emphasis that I am keen to learn, which I do. But most of the time I will not get a job if I do this.

    It's just better to be honest up front sbout what you don't know, at least in my book anyway.

    Which is exactly what he says he does.

    Exactly, which I seconded as a good move in general based on my experience, which I was sharing with him.. We are allowed to do that:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • I think that employers, clients, and managers appreciate when an IT professional openly admits what they don't know while still demonstrating what they actually do know. When I've done job interviews in the past, it's not unusual for me to answer a question with something like the following, and it never prevented me from getting hired:

    "I don't know the answer to that off the top of my head, but I could easily look it up in MSDN."

    "I've never used ABC on a project in the past, but I know it's useful in situations where one is working with XYZ."

    Likewise, there have been times when I've been asked to sit in on technical interviews, and I'll ask one oddball technical question for which I'd not expect the candidate to know the answer. I don't expect them to actually provide the answer but rather for them to tell me how they would look for the answer. If they come back with a b-s- answer, then they failed that one.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I get really annoyed by interviewers who expect you to know every bit of syntax off the top of your head and don't accept answers like the above. I think this job is about knowing where to look and understanding what you read/what you're asked for, far more then memorizing stuff.

  • Freddie-304292 (7/13/2011)


    I get really annoyed by interviewers who expect you to know every bit of syntax off the top of your head and don't accept answers like the above. I think this job is about knowing where to look and understanding what you read/what you're asked for, far more then memorizing stuff.

    Yes, it is silly. We wouldn't walk up to a coworker's desk and ask them to repeat off the top of their head the complete syntax of a MERGE command and what options are available, so why expect a job candidate to know it? The interviewer probably wouldn't know the answer, if they didn't have it written down on paper in front of them.

    What's more important is that a developer know the pros and cons of using a MERGE statement versus a Slowly Changing Dimension task and also know in general how to use either when needed.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (7/13/2011)


    Likewise, there have been times when I've been asked to sit in on technical interviews, and I'll ask one oddball technical question for which I'd not expect the candidate to know the answer. I don't expect them to actually provide the answer but rather for them to tell me how they would look for the answer. If they come back with a b-s- answer, then they failed that one.

    Same here. Have to admit, most of the time they try the b-s answer...

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Being a good BSer is a critical skill if you are trying to get elected to a public orifice.

    The probability of survival is inversely proportional to the angle of arrival.

  • Eric M Russell (7/13/2011)


    "I don't know the answer to that off the top of my head, but I could easily look it up in MSDN."

    I agree, that this is a good answer for a particular thing you do not know or have not memorized. However, if an interviewer asks you hypothetical questions (I do this all the time) that kind of response is just not enough. For example:.

    "You come in one morning and a user comes to you saying a production SQL Server is not responding, what steps would you do to rectify the situation and in what order?"

    "You get a phone call on Friday afternoon that a production database has unexpectantly gone suspect, what specific steps would you take to address this issue?"

    "A user is complaining that her production report that calls a particular stored procedure on a particular production database is taking over 20 minutes to run. What steps would you do to resolve this?"

    In other words., I want to know how quickly and well a candidate can think on their feet on a daily basis when REAL issues arrive and how keen their problem solving skills are. This is where the wheat is separated from the chaff in my opinon, and how you answer these kind of questions will reflect your REAL experience level every time, at least to me anyway. I am less interested in asking questions that have a particular one word or sentence answer that can either be looked up on the Internet or memorized and just spit out.. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • Freddie-304292 (7/13/2011)


    I get really annoyed by interviewers who expect you to know every bit of syntax off the top of your head and don't accept answers like the above. I think this job is about knowing where to look and understanding what you read/what you're asked for, far more then memorizing stuff.

    BWAA-HAAAA!!!! I "love" precise syntax questions. That's where I turn around and say to the interviewer "the answer is in BOL" and I follow that up with "Now, let's see how YOU would do the following problem... it's called "The million row Fizz-Buzz"... 😛

    --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)

  • Jeff Moden (7/13/2011)


    Freddie-304292 (7/13/2011)


    I get really annoyed by interviewers who expect you to know every bit of syntax off the top of your head and don't accept answers like the above. I think this job is about knowing where to look and understanding what you read/what you're asked for, far more then memorizing stuff.

    BWAA-HAAAA!!!! I "love" precise syntax questions. That's where I turn around and say to the interviewer "the answer is in BOL" and I follow that up with "Now, let's see how YOU would do the following problem... it's called "The million row Fizz-Buzz"... 😛

    So what's the rest of the problem??

  • It's a "dumb" little test to (supposedly) separate people who know how to code from the ones that don't. A whole lot of time has been wasted on it, too! (see the Google link below on what the problem consists of...) 😀 I find that most people giving the interview don't know how to solve it correctly in SQL Server and it gives me a chance to explain to the interviewer what "thinking outside the box" can mean because I show them both the typical "While Loop" method that so many developers use and the "Pseudo-Cursor" method that people should use. Most interviewers have never seen such a thing... it makes for a really good ice-breaker and allows me to turn the interview around to stuff that I want to talk about instead answering the normal "droll" questions presented during an interview.

    http://www.google.com/search?num=30&hl=en&biw=1016&bih=555&q=fizzbuzz+sqlservercentral&btnG=Search&aq=f&aqi=&aql=f&oq=

    --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)

Viewing 15 posts - 46 through 60 (of 87 total)

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