Interview guidelines

  • Good point and a wise ordering of questions. No point in finding out how they would research every little thing they needed to know.

  • At my current place we start with the technical interview. Since we're curently looking for people to do performance tuning and monitoring, I'll usually start with a very simple question on indexes.

    By HR's rules we can't decide based on a single question so, if they get that wrong, I'll usually ask a few more simple things, but is essentially interview over.

    If they pass the interview, they get a technical test. Only after that do they come for the more traditional interview ("Why do you want to work here, what are your goals, ....) with management.

    The process takes far longer than it should.

    Grant: why not write a CLR procedure to call a web service, then shred the resultant XML? 😀

    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 (4/10/2008)


    At my current place we start with the technical interview. Since we're curently looking for people to do performance tuning and monitoring, I'll usually start with a very simple question on indexes.

    By HR's rules we can't decide based on a single question so, if they get that wrong, I'll usually ask a few more simple things, but is essentially interview over.

    If they pass the interview, they get a technical test. Only after that do they come for the more traditional interview ("Why do you want to work here, what are your goals, ....) with management.

    The process takes far longer than it should.

    Grant: why not write a CLR procedure to call a web service, then shred the resultant XML? 😀

    Now, THAT's the order that I'd like to see the interview cycle take!

    Grant and Gail:... you don't need to do all of that... just do it in the GUI 😛

    --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)
    Intro to Tally Tables and Functions

  • Mahesh:

    I would suggest that in addition to preparing for the set of questions that come from the person reviewing you that you also be prepared and have yourself a set of questions that you ask when you go to the interview. There are a number of reasons to want to do this but the biggest reason is that both you and the company that you are interviewing with want to be sure that this is a job that you really want. Frequently, you will get asked if you have any questions. I would suggest that you take that point to ask whatever is important for you to know at that point. Some of these would not need to be asked if the question has already been asnwered. In addition, some of these questions might put a little pressure on the interviewer and you might not choose to ask these questions for this reason. However, it the person interviewing you is potentially going to be your boss it is better for you if you know in advance how your boss will respond when the time comes for you to ask your boss a pressure question. Some questions might include:

    + What would my role be over the first six months?

    + What would my role likely be in 18 months?

    + What do you personally like most about working for this company?

    + What do you like least?

    + Has there been a high turnover rate for this position?

    + Why has there been a high turnover rate for this position?

    + Do you have a set of standards that you go by for development?

    + Security Standards?

    + Platform Standards?

    + What is the most frequent recurring problems?

    + What is your biggest present challenge?

    I especially like asking the last question. The more details that I can get about that question the better my chances are that I can either outright solve that problem or outline a plan to solve that problem. This has all kinds of benefits to you if you are very interested in the job.

    Also, make sure you voice positive feedback statements about what you hear that you like, but again like others have said, make sure these are honest statements. Two biggies:

    + It sounds to me like I would like to work here.

    + I like that. (Whatever it is)

    + I hope I get the job.

    Also, I have no problem saying one or two like

    + I don't care for that. (Whatever it is)

    + I don't care for that, but that is not a big problem because ...

    There are two reasons I will allow potential brief negative feedback. (1) Personal integrity. (2) Your yeses become meaningless if all you ever say is "yes". Also, it demonstrates that you can say "No" and your boss must always be sure that you can say "no" when you need to.

  • [To me] the more DBA the position, the more specific syntax-type questions I ask, while the more Developer the position, the more conceptual the questions. (admittedly, I haven't interviewed many people). So when I was part of some interviews a year ago, my first question was the following:

    "You have table , but it fails telling you there's a primary key violation. Find the records causing the problem, and propose a solution."

    In other words, if I were interviewing you for a developer position, expect "How" type questions that also demonstrate basic techniques (joins, identity fields, indexes/keys, etc.)

    FWIW.

  • GilaMonster (4/10/2008)


    At my current place we start with the technical interview. Since we're curently looking for people to do performance tuning and monitoring, I'll usually start with a very simple question on indexes.

    By HR's rules we can't decide based on a single question so, if they get that wrong, I'll usually ask a few more simple things, but is essentially interview over.

    If they pass the interview, they get a technical test. Only after that do they come for the more traditional interview ("Why do you want to work here, what are your goals, ....) with management.

    The process takes far longer than it should.

    Grant: why not write a CLR procedure to call a web service, then shred the resultant XML? 😀

    don't be silly - if you're going to go CLR - write a kernel-level windows service to roll your own NTP query to the nearest atomic clock, resampling every 25 ms.....sheesh.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Hi all

    I don't know how much help Mahesh got but I think I got all the questions for the technical test for the next interview. Thnks guys 🙂 😛

  • [font="Verdana"]

    I would like to thank you all for such a kind support. I get a better idea, what kind of questions (technical and non-technical as well) can be asked in interview.

    Now the fog is over. I can drive smoothly 😉

    Thanks again,

    Mahesh

    [/font]

    MH-09-AM-8694

  • good luck at your interview! remember to shave! 🙂

    ---------------------------------------
    elsasoft.org

  • Wear clean trouser and shirt. Don't forget to clean your shoes and lastly please comb your hair. :hehe:

Viewing 10 posts - 16 through 24 (of 24 total)

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