March 4, 2015 at 10:29 am
Qualify what the problem may be is the first step.
Did it just start? Is it some users, or all users? Is it some queries, or all queries? Is it all of the time, or only at certain times?
Sure wouldn't want to start digging into an execution plan when it's a configuration issue.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
March 4, 2015 at 11:33 am
I know you looking for certain answer.
How i will answer that question: I use formalizes approach
1) i need to find root cause and talk about possibilities like as you mentioned
2) How do i find root cause by using DMVs, Waits, Profiler, third party tool .
3) different different solutions for different different possibilities
second thing i don't worry about interview time frame as a candidate.and i will keep answering that question with different different solution for different possibilities an as long as i am on right path or unless they wants me to stop.
as we all know this is not one or two line answer they are expecting.
So this all about How we approach to solve problem like slow running , slow running application. In question like this there are so many possibilities involves causing problem like slow running query. best answer is we need to give them answer on not a one certain scenario and come to conclusion . that'y we talk in general and stay on path.
March 5, 2015 at 8:02 am
jwiseh (3/3/2015)
However, remember, this is a job interview, not an hour-long training class. You have 60 seconds to give whatever these DBA's consider to be an intelligent answer. How would you answer the question, "Your users report slow queries. What do you do?" if you only have a minute or two to respond?I welcome your opinions on the subject, and thanks for your input!
I've asked variations on this question during interviews for data-layer developers and what I'm looking for when I ask it is some insight into how your mind works: how do you troubleshoot, how do you decompose a problem, etc. I don't assume that there's one correct answer (or, if there is that I'm smart enough to know what it is). If you responded by asking me more specific questions about the nature of the problem (e.g. has the query exhibited issues in the past, can the issue be recreated in the sandbox, etc.) that would score you points in my book.
In terms of narrowing things down, you're on the right track by listening to Jeff Moden's advice on the better tools/approaches. If you referenced his posts or articles in an interview with me, you'd be an automatic frontrunner.
March 6, 2015 at 2:53 am
Interviewing is a very subjective and personal process so you'll get a variety of different responses to your post. We've asked this sort of question in interviews recently and our personal opinion on this is that we're not expecting an exact answer, but instead we're trying to measure you on two aspects - attitude and approach.
Attitude
Attitude is really how you, as a new DBA to the team, will operate on a live system that you may not be fully familiar with. So we really don't want answers that just say "I'd kill the process", or "I'd change this setting because that's what I've found is best". We're want some evidence that you would approach this problem cautiously with a view to making the situation better and not worse.
Any appreciation of the relative priority of the problem is a bonus, for example if you recognise that it's the financial trading system so you need to drop everything as opposed to a single user archive system which may not be as important overall to the business.
Some evidence of team working goes down well here, at least an appreciation that the problem might be nothing to do with the database but that you could work with the virtualisation admins or the SAN admin to help come up with the solution. Team working extends outside of IT colleagues so some mention of how the interviewee would keep users AND management informed is very strong.
Approach
Approach is more if you have some sort of considered method of dealing with these sort of situations. Ideally we're looking for the first step to be some sort of triage to identify what the problem is. Is it all users? Is it all queries? Can you prove where the problem is - PICNIC, network, server, virtualisation, database, storage?
Second step is to refer to some sort of baseline to take this from an subjective statement from users, to an objective problem that can be qualified with measurements.
Third step would then to be to rule out any recent changes - whether planned or unplanned. For problem solving I like to keep it simple first, so if your output from a the first two steps suggest we've maxed out on CPU and it's a virtualised server, has another guest been added to this host, has the database server failed over from it's primary host?
If changes don't seem to be the culprit then what tools/techniques would you use to drill into the detail? Performance monitor, query DMV's, a monitoring tool you've used in the past?. We'd never mark you down for choosing a specific way of working here, everyone is different. As long as you can talk knowledgeably about it and link possible symptoms from a user to possible measurements you can take we would be happy. The very best answers will include examples of problems they have solved in the past and how they arrived at the solution.
For an interviewee this can be a real gem of a question. Yes it sounds daunting but it gives you the opportunity to take the interview into any direction you want. You can start off with your general approach, you can talk about past examples, you can move on to talk about monitoring systems to show how you'd be pro-active and avoid this problem being noticed by users in the first place, you can talk about an on-going performance improvement process you like to use on your systems, you can talk about your time management (e.g. spend 1 day a week trying to tune your top queries, some time every month updating baselines etc...). You can also finish by pushing the question back to the interviewer in some way - does this happen often or the last time this happened what was the cause or do you do root cause analysis after the event when you encounter problems like this? You want to turn it from an "interview" into "a conversation amongst like peers", make them feel you are already one of the team able to work on things together.
Final thing I would say is that as an interviewer we know this could be a really good question for a good candidate... so if you don't answer with passion/conviction and spend a good 5 minutes or more on it then you will score very poorly.
Good luck with the interviews. From experience I can safely say that normally the DBA's interviewing you are just as nervous as you are. Anything you can do to build rapport, turn it into a natural chat, even get some humour going will make the process much easier for everyone and help prove you will be an asset to the team regardless of your technical answers in an artificially pressurised environment.
March 6, 2015 at 2:28 pm
Heh... fine for others but, when I'm interviewing someone, I actually do want them to tell me something other than a general process because I want someone that has actually done this. Anyone that has done it several times will be able to clearly identify the steps they took and the tools they used to find and optimize queries.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply