April 18, 2009 at 5:32 pm
Alvin Ramard (4/18/2009)
Why not the gurus? Sure I'm interested in what they think, but if they answer first that will like affect how "junior" members answer.
Sure you are absolutely right, they may (will) be affected by other answers. I'm just not sure if they dare to answer. I think many people are just afraid about this possible "this system is down and we loose money"-day but really don't know how they should handle it.
They can learn so much from the pros here. This is a situation where any mighty TSQL knowledge ends and the planing, analysis, researching and some other things I don't know for DBAs start.
I know this situations from the other site. I know things I did wrong in the past and see other people doing the same or others in handling of system failures.
Maybe you could share your next steps...
Greets
Flo
April 18, 2009 at 5:35 pm
Lynn Pettis (4/18/2009)
My thought on his request told me he had a good idea what we might say, so he wanted us to hold off and see what others might say before we ventured forth with our suggestions on what we would do.Makes sense in a way, see what others think before we taint their ideas.
Sorry, I didn't see your answer. Complete agree since you/he/anybody would give an answer if nobody else does ;-).
April 18, 2009 at 5:41 pm
Starting with the following:
It's 3pm on a Friday, your production OLTP environment is down, every hour down costs the company one million dollars. People are phoning constantly, folks are rushing the hallways, running into your work area and freaking out wanting to know what you are doing, and why it's not fixed yet.
What do you do?
I'll start with just one step. Determine the nature of the problem. Just from this description, I actually can't tell you if the problem is a database problem, server or SAN problem, network problem, or a combination of all three. What needs to be done is based on what the actual problem is we are faced with. I may not have to play any role in the recovery at all.
April 18, 2009 at 5:51 pm
Right on Lynn.
Before you can solve any problem you need to know what the problem is. What does "your production OLTP environment is down" mean? Is it not responding? Is it showing incorrect information? Are error messages popping up all over the place? Is it just slow? And don't forget, especially if WordPerfect stopped working too, did the lights go out at the same time the problem started?
This is not so much a question to test someone's SQL skills as it is a question to test someone's troubleshooting skills.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
April 18, 2009 at 5:59 pm
Sorry if my first question came across a bit brutal. I spent three long years trying to find a DBA worth hiring and the only one I found was a guy I used to work with (who got me started with SQL damn him)
. I'm real tough on resume's and have a personal record of under two minutes for an interview (based upon a good resume).
When you ask someone the first thing on their resume and they don't know what you are talking about, plus walked into the lobby with two other people there's something fishy going on.
The first question was just about what an instance was (resume mentioned having installed and configured many SQL instances). So I just said I thought we were done. The classic thing is that they asked me twice on the way out the door if they had got the job.
I always would weed out resume's that had widespread knowledge, or intricate knowledge that didn't match their experience. Also, anyone with the MCDBA credentials and without at least 3 years under their belt were a no-no. The credential is great, but you have to back it up with experience and not have it because of a brain dump.
The big thing, don't lie on the resume, hiring managers with any experience can spot it a mile off. That will get you in the door.
Once in the door know everything that is on your resume and be prepared to talk about it if asked (and you will be asked). If you are asked about something that is not on your resume and that you have a basic knowledge of, explain that it's not something you have worked on, however are familiar with it and know the resources that you can use to answer anything that you might not be sure about. As with the resume do not lie, again, anyone hiring you will see it a mile off.
Always be prepared to back up you interview answers or resume items with the actions required to perform them. For example, a DBA I would not expect to be able to code up to the standard of a developer, however they need to have at least basic TSQL skills.
I had someone with a great resume, they interviewed well and could answer everything on their resume. The ACID (yeah, bad pun) test came when sticking them down in front of a laptop connected to a development SQL Server. That's where things kinda went pants. I had a request to update some data in a table based upon the values in another table, but that I wanted a copy of the data that would be changing in another backup table just in case of issues down the road. When he opened Enterprise Manager and started dragging tables into a visual window then get lines between tables I knew we were in trouble. Ultimately he wasn't able to do this. Not good.
Just be who you are, know what you claim to and be prepared to provide information sources for anything that you don't.
April 19, 2009 at 12:28 pm
Lynn, Alvin
Thanks a lot for the feedback!
Greets
Flo
April 19, 2009 at 8:18 pm
There's been lots of good discussion and feedback here. My initial thought on seeing the "what do you do in case of a major disaster" matched Alvin's -- lock the door and get to work. But I realized that in cases like that, our team has generally had to have someone passing information to the outside world (management or whatever) as they may have to make decisions based on expected progress or notify clients. So the real answer is to have multiple communication channels going with someone on the team handling the status updates while the most qualified to deal with whatever the situation is are allowed to do just that. I suppose that fits with the answers that suggest your manager do that.
Now, back to the goal of the original postl: getting a job as a DBA. I think the advice given here is solid. By asking a couple of times "but what's the resolution?" to the OLTP system crash straw-man question, I'm afraid the OP has given himself away as relatively inexperienced. THERE'S ABSOLUTELY NOTHING INHERENTLY WRONG WITH BEING A BEGINNER. But if he is (and both this thread and his other posts on SSC seem to point that way), I think he should be asking about ways to build his skills and for advice on career development, not for sources of interview cheet sheets. An interviewer may ask what sound like technical questions, but since a job interview is not the same as an exam in school, (s)he may actually be more interested in your reaction to a tough problem or in the way you apply real-world considerations ("...lock the door. tell the manager to order pizza...") than in the technical steps you may take.
The number one piece of advice is be honest. If you're new to the field, no matter how well you know SQL, your inexperience will probably still show in an interview, so don't blow it by lying. Be that as it may, here are some questions you should probably be ready for:
What's your actual experience with data processing? Work? School?
What experience and/or training have you had with MS-SQL?
What versions of SQL have you used? One of your posts indicated you're using SQL 2000. Why this older version?
Are you really looking for a DBA position, or to be a developer who uses SQL?
April 20, 2009 at 7:30 am
What's your actual experience with data processing? Work? School?
What experience and/or training have you had with MS-SQL?
What versions of SQL have you used? One of your posts indicated you're using SQL 2000. Why this older version?
Are you really looking for a DBA position, or to be a developer who uses SQL?
im currently a DBA now for about 2 1/2 years, I've used sql 2000 and 2005 and oracle 9i and 10g, and within the past 6 months I've been starting to do some development, interviewing for a new position at another company.
April 20, 2009 at 7:43 am
What position are you applying for?
Main advice I can give you is to relax, be honest and be willing to admit that you don't know something. Especially for a junior position, you cannot be expected to know everything.
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
April 20, 2009 at 7:52 am
It's 3pm on a Friday, your production OLTP environment is down, every hour down costs the company one million dollars. People are phoning constantly, folks are rushing the hallways, running into your work area and freaking out wanting to know what you are doing, and why it's not fixed yet.
What do you do?
If I'm ever given such a open question as this I like to give myself a bit of thinking time by throwing questions back at the interviewer asking what would I know at the time this happened things like, has a change recently be put in, who has assess to this system get some hints are the developers in this place allowed access to production systems. What can I see in the logs. Has this happened before, is it a regular occurance. It shows I'm thinking rationally about a problem but ensuring I can think about the issue properly. Also gets you some idea of what to expect if you get offered the job.
April 20, 2009 at 7:57 am
Steve Jones - Editor (4/18/2009)
I agree with Gail and Alvin. You want to represent yourself well, and show what you know on your resume. I have talked to dozens of people that eliminated candidates that could not back up what was on their resume.If you don't have experience, you don't have experience. You won't be able to answer questions well and discuss things you don't know. It's not a quiz show where you give an answer to pass. Most interviews I've had in the last 10 years required me to give more of an explanation about the answer, not just answer.
And peoplesavvy enough to demand the explanation and not the answer will smell whatever you're shoveling from a mile away, so be sure you back up what you present.
On another note - another else have an unholy fear of having a technical interview with Gail on the other side of the table? I've had pressure interviews before, but I don't think I'd survive that one....:)
----------------------------------------------------------------------------------
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?
April 20, 2009 at 8:01 am
its for a sr dba position with oracle and sql server, i've been doing more oracle than sql server, but i have good sql server skills, it just takes longer on some issues to figure out, but i have gotten better.
April 20, 2009 at 8:13 am
On the down OLTP server, my first question would be, "what do you mean 'down'?". There's a big difference between "the web pages are slow and customers are complaining" (which has been defined as "down" to me before), and "the server room has smoke coming out of it and the halon alarm just went off to warn people to get out of there", and there's a LOT of room in between those two.
Everything after that depends on the answer to that question.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 20, 2009 at 8:17 am
The question is more about how you handle a pressure situation than the actual details. If you can handle that being thrown at you in an interview and not get all flustered then it's a good start and it will give the interviewer a good impression.
April 20, 2009 at 8:25 am
GSquared (4/20/2009)
"the server room has smoke coming out of it and the halon alarm just went off to warn people to get out of there"
Now that's one I haven't had yet. I've seen smoke pouring out of the generator room, but never the server room. Yet.
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
Viewing 15 posts - 31 through 45 (of 97 total)
You must be logged in to reply to this topic. Login to reply