December 20, 2013 at 1:25 pm
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.
December 20, 2013 at 1:28 pm
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
December 20, 2013 at 1:31 pm
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/
December 20, 2013 at 3:20 pm
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.
December 20, 2013 at 3:39 pm
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.
December 20, 2013 at 3:40 pm
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
December 20, 2013 at 3:45 pm
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
December 20, 2013 at 3:47 pm
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.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
December 20, 2013 at 4:05 pm
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
December 20, 2013 at 7:13 pm
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
December 20, 2013 at 8:54 pm
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
December 20, 2013 at 9:02 pm
GilaMonster (12/20/2013)
Does this get the weird question of the week award? http://www.sqlservercentral.com/Forums/Topic1525137-391-1.aspxI 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. 😛
December 21, 2013 at 10:07 am
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
Change is inevitable... Change for the better is not.
December 21, 2013 at 1:29 pm
If anyone is interested, I will find on Monday what the on-call policy is for the third-level SQL Server support.
December 21, 2013 at 1:56 pm
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