Are the posted questions getting worse?

  • I think we phone screened that person for a job once. Every question resulted in awkward silence, then some non-related babble, followed by an extremely well stated answer that exceeded the candidate's apparent spoken English skills.

  • Andrew Notarian (12/20/2013)


    I think we phone screened that person for a job once. Every question resulted in awkward silence, then some non-related babble, followed by an extremely well stated answer that exceeded the candidate's apparent spoken English skills.

    Well, if you were trying to fill the position of "Senior Googler" or "Google Ninja", I hope you hired that candidate!

    Jason Wolfkill

  • wolfkillj (12/20/2013)


    Andrew Notarian (12/20/2013)


    I think we phone screened that person for a job once. Every question resulted in awkward silence, then some non-related babble, followed by an extremely well stated answer that exceeded the candidate's apparent spoken English skills.

    Well, if you were trying to fill the position of "Senior Googler" or "Google Ninja", I hope you hired that candidate!

    Overqualified!!!

    _______________________________________________________________

    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/

  • WayneS (12/20/2013)


    I'm curious as to the different ways that you fine folks have seen / dealt with being on-call, and what you perceive the pros/cons of these are?

    For instance:

    on-call for a week at a time, rotating weeks.

    on-call for a day at a time, rotating days.

    etc.

    Thanks!

    All suck.

    However, a week at a time was easier to plan things for. I could plan to limit activities, or enagage in a few things with a week to deal with.

    Rotating days just sucked. You might get a bad day, then you have to work, then you're back on call. Harder to recover, but then I like to bunch together stuff I dislike, so maybe weeks worked better for me.

  • WayneS (12/20/2013)


    I'm curious as to the different ways that you fine folks have seen / dealt with being on-call, and what you perceive the pros/cons of these are?

    For instance:

    on-call for a week at a time, rotating weeks.

    on-call for a day at a time, rotating days.

    etc.

    Thanks!

    The best on-call rotation I has was a month at a time. It sounds awful but was good. We had enough people that you were on call only 1 month out of the year.

  • So far seeing two trends emerge with the oncall question.

    1. Week is better (or several days grouped together) or a the daily rotation

    2. Oncall just SUCKS.

    And I definitely agree with the second of those 2:w00t::w00t:

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • OCTom (12/20/2013)


    WayneS (12/20/2013)


    I'm curious as to the different ways that you fine folks have seen / dealt with being on-call, and what you perceive the pros/cons of these are?

    For instance:

    on-call for a week at a time, rotating weeks.

    on-call for a day at a time, rotating days.

    etc.

    Thanks!

    The best on-call rotation I has was a month at a time. It sounds awful but was good. We had enough people that you were on call only 1 month out of the year.

    Being oncall for that month, when stuff broke - did you work like crazy to ensure you did not have the same thing turn into multiple nights or multiple failures? I'd imagine most would but I tend to see a lot of passing the buck with the daily rotation style. Chief reason for that is they wouldn't have to worry about the problem the next day.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Hey, all brand new SQLSaturday in a new state- SQLSaturday 293 - Maine. Be among the first to submit to speak, http://sqlsaturday.com/293/callforspeakers.aspx. Especially those of you who live in New England.

  • New blog post for your weekend enjoyment:

    Things That Make You Go "D'oh!" - Part 1: My Arithmetic is Overflowing???

    Like Bartles & Jaymes, we thank you for your support.

    Jason Wolfkill

  • SQLRNNR (12/20/2013)


    OCTom (12/20/2013)


    WayneS (12/20/2013)


    I'm curious as to the different ways that you fine folks have seen / dealt with being on-call, and what you perceive the pros/cons of these are?

    For instance:

    on-call for a week at a time, rotating weeks.

    on-call for a day at a time, rotating days.

    etc.

    Thanks!

    The best on-call rotation I has was a month at a time. It sounds awful but was good. We had enough people that you were on call only 1 month out of the year.

    Being oncall for that month, when stuff broke - did you work like crazy to ensure you did not have the same thing turn into multiple nights or multiple failures? I'd imagine most would but I tend to see a lot of passing the buck with the daily rotation style. Chief reason for that is they wouldn't have to worry about the problem the next day.

    Yes. It really made a difference because you could concentrate on issues. We found that the number of problems decreased over time. It became a rare instance when you were actually called. Maybe 1 or 2 times a month. One year we went 4months without a call. It also made us a lot more serious when implementing changes. Four of my colleagues had been pretty cavalier about not testing changes and just implementing them. That changed pretty quickly because one of the on call rules was if you did something to cause a call, you had to join the current on call person for the remainder of his month. Not only did the on call person get called, but, then he called you.

    About a week before you were due to be on call for your month, you met with the current on call person and checked the on call logs to see if there were any issues not solved, and, you worked hard to solve them before you went on call. There were generous flexibility in work schedule if you did get called.

    Tom

  • OCTom (12/20/2013)


    SQLRNNR (12/20/2013)


    OCTom (12/20/2013)


    WayneS (12/20/2013)


    I'm curious as to the different ways that you fine folks have seen / dealt with being on-call, and what you perceive the pros/cons of these are?

    For instance:

    on-call for a week at a time, rotating weeks.

    on-call for a day at a time, rotating days.

    etc.

    Thanks!

    The best on-call rotation I has was a month at a time. It sounds awful but was good. We had enough people that you were on call only 1 month out of the year.

    Being oncall for that month, when stuff broke - did you work like crazy to ensure you did not have the same thing turn into multiple nights or multiple failures? I'd imagine most would but I tend to see a lot of passing the buck with the daily rotation style. Chief reason for that is they wouldn't have to worry about the problem the next day.

    Yes. It really made a difference because you could concentrate on issues. We found that the number of problems decreased over time. It became a rare instance when you were actually called. Maybe 1 or 2 times a month. One year we went 4months without a call. It also made us a lot more serious when implementing changes. Four of my colleagues had been pretty cavalier about not testing changes and just implementing them. That changed pretty quickly because one of the on call rules was if you did something to cause a call, you had to join the current on call person for the remainder of his month. Not only did the on call person get called, but, then he called you.

    About a week before you were due to be on call for your month, you met with the current on call person and checked the on call logs to see if there were any issues not solved, and, you worked hard to solve them before you went on call. There were generous flexibility in work schedule if you did get called.

    Tom

    Now see that seems like a very good solution.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • GilaMonster (12/20/2013)


    Does this get the weird question of the week award? http://www.sqlservercentral.com/Forums/Topic1525137-391-1.aspx

    I believe the answer is "A SAN"

    Yeah, that's probably the lame question of the week. It just screamed "homework" or "online test". I didn't think of an interview question, in which case they probably aren't qualified. I enjoyed the Jeopardy categories you and Sean posted though. 😛

  • We have a wonderful "on call" policy. Anyone and everyone can be called at any time.

    The neat thing is that, in the 2 years I've been working for this most recent company, I've only been called twice in those two years and both times were during the day and neither had to do with production code. I "blame" the 100% peer review policy and the QA/UAT testing for the lack of urgencies.

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

  • If anyone is interested, I will find on Monday what the on-call policy is for the third-level SQL Server support.

  • Jeff Moden (12/21/2013)


    We have a wonderful "on call" policy. Anyone and everyone can be called at any time.

    The neat thing is that, in the 2 years I've been working for this most recent company, I've only been called twice in those two years and both times were during the day and neither had to do with production code. I "blame" the 100% peer review policy and the QA/UAT testing for the lack of urgencies.

    Our calls were infrequent. Usually something on the ERP was running late, so we couldn't start on time.

    Or someone shut down a system, forgot to start it back up, and once we figured this out, called them.

    The best one though - they seemed to not put edits in the ERP system. So a fast typing shop floor person would punch their clock number into the completion field. 601xxxxx into a field normally under 100. If they did not catch and reverse this, we would see all the parts on the BOM issued out. After a couple times we when saw this, we put our own edit in.

    Reversing the transaction was a circus. Many of the screens didn't even show the whole number involved, so they would reverse what they thought was the right amount, only to see another number still remaining.

    Never could figure out why this didn't rise up in priority to put an edit in. I guess finance liked the excitement when this happened. 1 transaction was more than several years of sales.....

Viewing 15 posts - 42,436 through 42,450 (of 66,738 total)

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