June 27, 2006 at 1:17 pm
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/jyao/surviveasqlserverdbatechnicalinterview.asp
July 10, 2006 at 8:10 am
coming from both sides ( I often get involved in interviews ) I'd pass on one piece of advice - don't put things in the cv that you can't back up. As a technical interviewer I dissect the cv and drill in on specific areas, especially items which make personal claims e.g. "I tuned a database to resolve i/o contention "
I've never failed to be amazed on how much a cv can be exaggerated to sound better!!! and often how little the applicant knows.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 10, 2006 at 11:44 am
I totally agree with Colin!!!
I recently accepted a dba position at a new company, so I just went through a 2 hour technical interview and am helping interview my replacement candidates at my soon-to-be former job. Our CTO and I agree that we are wary of anybody that puts on their resume that they are an expert in SQL Server. If they trully are an expert, then they'd better not miss a single question .... or even hesitate when answering it.
I think that one thing that really benefitted me in my recent interview was that I tried to make sure each question was fully answered. I didn't give short, terse answers, I fully explained everything. More than once, the interviewer commented that I was the only person that had covered certain aspects of the questions. For example, when asked to describe the different types of indexes, I was the only one that defined a covering index.
July 11, 2006 at 3:44 pm
Just went through this on both sides. Don't put SEQUEL in your resume unless you're referring to something other than SQL. (And that's not even worth pulling in for an interview from what I've seen.)
Agreed with the other quotes - know your stuff and know the type of position for which you're interviewing. If it's Dev DBA, be prepared to know DB Design and TSQL coding. If it's Prod DBA, know how to troubleshoot. Don't oversell yourself - you'll be found out quickly and generally tossed out. Also, don't be afraid to explain that you don't know something and then explain how you'd go about finding out the answer. That sits a lot better with interviewers than making something up. (However, it's a lot of fun to read those answers when they get posted on a website somewhere. 🙂
Finally, check out some of the other excellent posts/articles from the past on this site. Lots of good information and commentary, some serious, some amusing.
-Pete
July 12, 2006 at 9:41 am
Good points in the article.
My $.02:
The "Two Minute SQL Server Stumpers" have been helpful to me. One can't know everything about a product (at least I find that difficult). A lot of times knowing when and where to research a problem can be as important as knowing TSQL. How much real database modelling and design is dependant upon the organization and its size. On my last two jobs the databases were designed by developers and that is the case now. Be yourself. If you don't clearly understand the interviewer's question ask for clarification or an example. The technical skills are an obvious must have but the softer skills, being able (and willing) to listen, being able to communicate clearly, and not being pompous about being a DBA are extremely important as well.
July 12, 2006 at 3:02 pm
agreed .. never claim to be an expert .. you'll be immediately shot down - sql server is so vast you'll never know it all, and someone will always know something you don't .. It can only get worse with 2005 !!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
October 12, 2007 at 6:34 am
well that's interesting to revisit an article which should have provoked more interest I would have thought. I'm still involved with hiring DBA's and I have to say there's some other types of DBA which are not covered in the article. I'll call type 1 the Monitor DBA: this DBA appears to have no real skills beyond using the GUI and watching the output of say Tivoli. I've interviewed a few of these, and some have been on UK salaries in excess of $100k p.a. ( thought i'd put in in US dollars ) They have little technological knowledge and seem to defer to other teams, typically in answer to a question about server hardware performance they would reply that they would refer this to the server team. Typically because they always use the GUI for their work they tend to use only maint plans for backups and index rebuilds, they'll also usually fail the simple question can you have a non clustered PK - I could go on with more examples like this.
Type 2 is the DBA with the string of qualifications who actually knows little more than type 1 - but you can only get to this by defining questions which relate to practical experience.
I don't have a blog grumpyolddba for nothing!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
October 12, 2007 at 7:16 am
There is another type of DBA which may or may not fit within the definition of 'Hybrid' DBA, but stands apart from the first two in terms of the requirements.
The 'Data Warehouse' DBA is required to not only forget or re-learn some of the basic principles of the other types, but also to learn quite a few new ones; for example how to deal with very large data volumes, advanced optimisation, partitioning for performance etc.
I often find the more 'traditional' DBA will not recognise these differences, and some will even argue about techniques etc. becasue they go against their established knowledge - however as Business Intelligence systems become a norm in the modern enterprise, DBA's are be called on more and more often to manage and improve on such databases.
It is worth finding out if you're about to attend an interview if the company has a data warehouse, or intends to build/buy one, as the job role may expand to include the need to fulfill this role.
October 12, 2007 at 7:55 am
Does all DBA jobs have technical interview? My previous company just had the manager interviewed the DBA and the manager was not technical.
October 12, 2007 at 9:00 am
Being in both sides of the fence what really I like the least is that the "interviewers" many times could ask corner questions. That not only is unfare but also relates to very specific conditions that could prove of little value to determine the quality of a candidate. On the "interviewee" side I also think that you should *NEVER* lie no matter what, in the end who can tell that knows every single little aspect of SQL Server ?
Just my $0.02
* Noel
October 12, 2007 at 9:00 am
We are interviewing for a senior level DBA right now, and (same as other comments) its amazing how many people can write up a storm on their resume / cv, or provide loads of anecdotal tales, yet still cant answer technical questions.
There's one thing for me that will almost always cut the interview short though - not showing respect for the interview. Dont talk down to the interviewer, you may be (in your opinion) a DBG (Database God), but if you cant be bothered to explain yourself to me, I get to cut the interview short and say "Thanks, but no thanks"; and, please, dress appropriately, if you cant even be bothered to put on a pair of trousers / pants and a nice shirt dont be bothered to show up either.
October 12, 2007 at 11:41 am
Phil, I think your comment is very valuable here. Yes, I totally agree that a data warehouse DBA should have some different perspective / knowledge in terms of managing VLDBs, plus knowledge about ETL, reporting service, data modelling and ....
Phil Morris (10/12/2007)
There is another type of DBA which may or may not fit within the definition of 'Hybrid' DBA, but stands apart from the first two in terms of the requirements.The 'Data Warehouse' DBA is required to not only forget or re-learn some of the basic principles of the other types, but also to learn quite a few new ones; for example how to deal with very large data volumes, advanced optimisation, partitioning for performance etc.
I often find the more 'traditional' DBA will not recognise these differences, and some will even argue about techniques etc. becasue they go against their established knowledge - however as Business Intelligence systems become a norm in the modern enterprise, DBA's are be called on more and more often to manage and improve on such databases.
It is worth finding out if you're about to attend an interview if the company has a data warehouse, or intends to build/buy one, as the job role may expand to include the need to fulfill this role.
October 12, 2007 at 12:12 pm
Loner (10/12/2007)
Does all DBA jobs have technical interview? My previous company just had the manager interviewed the DBA and the manager was not technical.
No, but they should. If you were interviewing someone to fill a nursing position, you'd ask medical questions, wouldn't you?
I was helping to interview someone to cover a weekend support position, and we simply needed someone with enough SQL knowledge that if a job stopped (such as replication) he could restart it. Anything more than that, his job was to call someone else.
So here was the question I asked the 3 people that interviewed for the position: "If you're the only one around and a web developer is working on the weekend, and he asks you to give him permissions to run SQL Profiler in production so that he can trap an error hitting the live website, what is your response?"
The answer I liked best was by the first interviewer, "I don't know what SQL Profiler does or what impact it would have on production, so no, I won't. You'll need to talk to the dba about that when he's here."
October 12, 2007 at 12:35 pm
Not just the Data Warehouse DBA, even ETL developer, data warehouse developer is totally different from traditional DBA and developer.
October 24, 2007 at 4:46 am
Loner (10/12/2007)
Not just the Data Warehouse DBA, even ETL developer, data warehouse developer is totally different from traditional DBA and developer.
Yes I'd agree - however development in Business Intelligence projects (DWH, BI, ETL etc.) benefits hugely from iterative approaches and RAD style techniques that are preety much proven in 'traditional' development technologies. There are different challenges to adopting these techniques and it's a work in progress with many practitioners (our company being one of them) as to how to adopt iterative and agile approaches.
(apology for going off-topic and thread hi-jacking!) 😉
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply