Interview Questions

  • Sean Lange (6/17/2016)


    Ed Wagner (6/17/2016)


    Sergiy (6/16/2016)


    My point was - the question about finding current time does not have a correct answer without specifying additional conditions.

    And I think that's fine. If you don't know how, you don't know how. If you know a way, that's a good thing. If you several ways, that's also a good thing. If you can intelligently discuss the differences, that's a very good thing.

    I think one difference lies in understanding how something works versus just using it. If you understand something simple, then you're more likely to understand something more complex. This points to the bottom line of intellectual curiosity versus not caring one way or the other.

    Another point your statement about "additional concerns" raises is about questioning things. How many times have we received 100% clear, unambiguous specifications of what someone wants designed or written and it was actually right? Now, how many times do we have to pose questions to them to determine what they're really after. If you ask questions of the requester for something as simple as a date, you demonstrate that you understand things enough to ask clarifying questions.

    Does this make any sense at all or am I just babbling?

    We have a long standing joke around here. When I finish a project it is exactly what the business unit asked for...however, it is rarely what the business unit wants. 😉

    I understand completely. That DSS (defective specs syndrome) is not limited to your organization. We're plagued by it as well.

  • Ed Wagner (6/17/2016)


    Sergiy (6/16/2016)


    My point was - the question about finding current time does not have a correct answer without specifying additional conditions.

    And I think that's fine. If you don't know how, you don't know how. If you know a way, that's a good thing. If you several ways, that's also a good thing. If you can intelligently discuss the differences, that's a very good thing.

    I think one difference lies in understanding how something works versus just using it. If you understand something simple, then you're more likely to understand something more complex. This points to the bottom line of intellectual curiosity versus not caring one way or the other.

    Another point your statement about "additional concerns" raises is about questioning things. How many times have we received 100% clear, unambiguous specifications of what someone wants designed or written and it was actually right? Now, how many times do we have to pose questions to them to determine what they're really after. If you ask questions of the requester for something as simple as a date, you demonstrate that you understand things enough to ask clarifying questions.

    Does this make any sense at all or am I just babbling?

    My whole point is that if you don't even know how to get the current date and time, no matter the reason or the method, then you're not a Senior DBA or Senior Developer and because of your arrogance in thinking you are and your ignorance in what is supposed to be one of your primary skills, you've wasted my time and are endangering the data of any company you may be working for because you won't know the details of anything else important, either.

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

  • Ed Wagner (6/17/2016)


    Sean Lange (6/17/2016)


    Ed Wagner (6/17/2016)


    Sergiy (6/16/2016)


    My point was - the question about finding current time does not have a correct answer without specifying additional conditions.

    And I think that's fine. If you don't know how, you don't know how. If you know a way, that's a good thing. If you several ways, that's also a good thing. If you can intelligently discuss the differences, that's a very good thing.

    I think one difference lies in understanding how something works versus just using it. If you understand something simple, then you're more likely to understand something more complex. This points to the bottom line of intellectual curiosity versus not caring one way or the other.

    Another point your statement about "additional concerns" raises is about questioning things. How many times have we received 100% clear, unambiguous specifications of what someone wants designed or written and it was actually right? Now, how many times do we have to pose questions to them to determine what they're really after. If you ask questions of the requester for something as simple as a date, you demonstrate that you understand things enough to ask clarifying questions.

    Does this make any sense at all or am I just babbling?

    We have a long standing joke around here. When I finish a project it is exactly what the business unit asked for...however, it is rarely what the business unit wants. 😉

    I understand completely. That DSS (defective specs syndrome) is not limited to your organization. We're plagued by it as well.

    I think every company is plagued by it. Next to having Access at everyone's fingertips it is the second leading cause of corporate cancer.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Jeff Moden (6/17/2016)


    Ed Wagner (6/17/2016)


    Sergiy (6/16/2016)


    My point was - the question about finding current time does not have a correct answer without specifying additional conditions.

    And I think that's fine. If you don't know how, you don't know how. If you know a way, that's a good thing. If you several ways, that's also a good thing. If you can intelligently discuss the differences, that's a very good thing.

    I think one difference lies in understanding how something works versus just using it. If you understand something simple, then you're more likely to understand something more complex. This points to the bottom line of intellectual curiosity versus not caring one way or the other.

    Another point your statement about "additional concerns" raises is about questioning things. How many times have we received 100% clear, unambiguous specifications of what someone wants designed or written and it was actually right? Now, how many times do we have to pose questions to them to determine what they're really after. If you ask questions of the requester for something as simple as a date, you demonstrate that you understand things enough to ask clarifying questions.

    Does this make any sense at all or am I just babbling?

    My whole point is that if you don't even know how to get the current date and time, no matter the reason or the method, then you're not a Senior DBA or Senior Developer and because of your arrogance in thinking you are and your ignorance in what is supposed to be one of your primary skills, you've wasted my time and are endangering the data of any company you may be working for because you won't know the details of anything else important, either.

    And you're correct.

  • Jeff Moden (6/17/2016)


    Ed Wagner (6/17/2016)


    Sergiy (6/16/2016)


    My point was - the question about finding current time does not have a correct answer without specifying additional conditions.

    And I think that's fine. If you don't know how, you don't know how. If you know a way, that's a good thing. If you several ways, that's also a good thing. If you can intelligently discuss the differences, that's a very good thing.

    I think one difference lies in understanding how something works versus just using it. If you understand something simple, then you're more likely to understand something more complex. This points to the bottom line of intellectual curiosity versus not caring one way or the other.

    Another point your statement about "additional concerns" raises is about questioning things. How many times have we received 100% clear, unambiguous specifications of what someone wants designed or written and it was actually right? Now, how many times do we have to pose questions to them to determine what they're really after. If you ask questions of the requester for something as simple as a date, you demonstrate that you understand things enough to ask clarifying questions.

    Does this make any sense at all or am I just babbling?

    My whole point is that if you don't even know how to get the current date and time, no matter the reason or the method, then you're not a Senior DBA or Senior Developer and because of your arrogance in thinking you are and your ignorance in what is supposed to be one of your primary skills, you've wasted my time and are endangering the data of any company you may be working for because you won't know the details of anything else important, either.

    Jeff, if you're after a senior one then don't ask junior level questions.

    My remark was about this statement from you:

    the candidate probably shouldn't over-engineer the answer, especially in the form of multiple questions for clarification of such a simple question clearly asked to test the basic knowledge.

    If a candidate for a senior position does not "over engineer" the answer on such a question, you may stop the interview right there.

    He/she might be a good junior, probably even intermediate level DEV/DBA, but he/she does not have a set of mind required to go beyond the fixed answers provided by the instruction manuals.

    It's not a senior material and will never be good for such a position.

    I don't know - did you solve the tasks about a pool and 2 pipes in the school?

    Did you realise that the answer which is good for a school student would be totally inappropriate for a university graduate.

    "Over engineering" is what makes the difference between Senior and all other levels.

    _____________
    Code for TallyGenerator

  • Sergiy (6/17/2016)


    Jeff, if you're after a senior one then don't ask junior level questions.

    My remark was about this statement from you:

    the candidate probably shouldn't over-engineer the answer, especially in the form of multiple questions for clarification of such a simple question clearly asked to test the basic knowledge.

    If a candidate for a senior position does not "over engineer" the answer on such a question, you may stop the interview right there.

    "Over engineering" is what makes the difference between Senior and all other levels.

    If I'm after a "senior one", then they should be able to tell me how to get the current date and time. Like I said, I do explain that the first couple of questions are going to be very simple questions just to get the to relax.

    A "senior one" will also understand that they have the opportunity to shine with something like the answer I posted that starts with "It Depends..." and then rattle off several different methods. If they don't know the answer to the first question, then they're not a "senior one" and I've saved myself and the others a whole lot of time.

    And, no... I wouldn't stop the interview if anyone got through the first 3 questions even with simple one word answers for each question. It would be too refreshing a change to dismiss.

    Seriously... would you hire someone or waste your time on more complicated questions if someone couldn't answer such a simple first question? Would you, for example and even with all the things that may enter your mind even after I explain that I ask no trick questions, fail to correctly answer that simple first question? I don't believe so.

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

  • Sergiy (6/15/2016)


    Jeff Moden (6/15/2016)


    An interview is the one place where volunteering information can do nothing but good... if you know what you're talking about. When someone asks a simple question about how to get the current date and time in T-SQL, they can really start to strut their stuff by answering something like the following instead of asking for clarification on such a simple question...

    You are soooooo wrong!

    You obviously have not been on another side of an interview for quite a long time.

    Unfortunately, too many folks who've been appointed to conduct an interview have a limited knowledge of the subject. And they probably have no idea about that range of options you're talking about.

    They expect you to answer with that one particular option they do know about.

    If you start bringing all the other smart sh.t they will fill threatened, label you "nerd" in their minds and, at the best, report you as "overqualified for the position". At the worst - difficult to communicate.

    There must be a dozen of interviewers like that in the world, and 99% of applicants will never even see your advertisement.

    To be successful in job hunting applicants need to fit into a more common pattern, like - figure out what kind of answer they want from you and give that single simple response the interviewer would be able to digest.

    And when they get to your interview they have no indication that they deal with an odd freak, and they must behave differently.

    Give then a sign - and you'll get totally different sorts of applicants and answers on your interviews.

    Ah, but do you want to work in a place where they have the attitude "I don't want anyone too good"?

    You are quite correct, you do get some interviewers with the attitude you describe. Frankly, I don't want to work with them, or in an environment where that kind of attitude thrives.

    Happily, it does seem quite rare in my experience (NE UK based) - but then again, so are candidates of the dubious quality Jeff has inflicted upon him.

    Last time we interviewed we had two absolutely outstanding candidates, one decent and one who would have been acceptable as a junior, but not at the grade we were interviewing for, and believe you me - I work for the NHS - it's not like we're attracting people with big (or even medium sized) money.

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

Viewing 7 posts - 106 through 111 (of 111 total)

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