﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / Discuss Content Posted by Jeffrey Yao / Article Discussions / Article Discussions by Author  / Survive A SQL Server DBA Technical Interview / Latest Posts</title><generator>InstantForum.NET v4.1.4</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Mon, 22 Mar 2010 04:18:45 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>One of the simplest bits of advice I could give to anyone going for an interview.If you don't know the answer to a question, tell the interviewer.  There is little point in trying to answer somethnig with a load of ramblings if you don't know the answer.  I only started my job a few months back but there were silly questions which I could not answer during the interview - ones which I knew but stuttered on.The key was that I didn't make myself look foolish with a silly answer and that the rest of my technical knowledge came through during the interview process.The interviewer will respect the fact that interviews can be a nervy place to be and also they know you don't know every single detail about SQL Server.Just because you don't answer 1 or 2 questions doesn't mean you won't get the job.  Demonstrating a sound alround knowledge and a willingness to improve in every area of the job (including the ones you know very well) will get you looked upon favourably.</description><pubDate>Wed, 21 Nov 2007 07:02:11 GMT</pubDate><dc:creator>Clive Strong</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>In my company, the first interview is technical. After that there's a technical test, then the HR-type interview.Seems to work quite well. So few people get through the first interview. I will strongly agree on two points made here - back up your claims and don't look down on the interviewer.We had one guy, claimed to be a SQL expert, lots of experience in optimisation (which is what we were looking for). When he came to the technical interview, he was highly arrogant. Once we started the questioning it got worse. He couldn't describe the differences between a clustered and nonclustered index. Didn't know profiler. Couldn't describe to me how to get an execution plan, let alone read one. Went off on long tangents describing some system he'd written (in ASP) some years backMost of his answers were a couple seconds of mumbling followed by "well, you know."We didn't invite  him back.</description><pubDate>Wed, 24 Oct 2007 05:36:01 GMT</pubDate><dc:creator>GilaMonster</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>Lets discuss the areas from which questions are asked generally..</description><pubDate>Wed, 24 Oct 2007 05:01:39 GMT</pubDate><dc:creator>VaidyaVS</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>[quote][b]Loner (10/12/2007)[/b][hr]Not just the Data Warehouse DBA, even ETL developer, data warehouse developer is totally different from traditional DBA and developer.[/quote]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!) ;)</description><pubDate>Wed, 24 Oct 2007 04:46:48 GMT</pubDate><dc:creator>Phil Morris-454316</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>Not just the Data Warehouse DBA, even ETL developer, data warehouse developer is totally different from traditional DBA and developer.</description><pubDate>Fri, 12 Oct 2007 12:35:03 GMT</pubDate><dc:creator>Loner</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>[quote][b]Loner (10/12/2007)[/b][hr]Does all DBA jobs have technical interview?  My previous company just had the manager interviewed the DBA and the manager was not technical.[/quote]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."</description><pubDate>Fri, 12 Oct 2007 12:12:21 GMT</pubDate><dc:creator>Robert Davis</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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 ....[quote][b]Phil Morris (10/12/2007)[/b][hr]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 '[b]Data Warehouse[/b]' 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.[/quote]</description><pubDate>Fri, 12 Oct 2007 11:41:57 GMT</pubDate><dc:creator>jeffrey yao</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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.</description><pubDate>Fri, 12 Oct 2007 09:00:51 GMT</pubDate><dc:creator>Simon Facer</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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</description><pubDate>Fri, 12 Oct 2007 09:00:30 GMT</pubDate><dc:creator>noeld</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>Does all DBA jobs have technical interview?  My previous company just had the manager interviewed the DBA and the manager was not technical.</description><pubDate>Fri, 12 Oct 2007 07:55:35 GMT</pubDate><dc:creator>Loner</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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 '[b]Data Warehouse[/b]' 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.</description><pubDate>Fri, 12 Oct 2007 07:16:02 GMT</pubDate><dc:creator>Phil Morris-454316</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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!!  </description><pubDate>Fri, 12 Oct 2007 06:34:58 GMT</pubDate><dc:creator>colin.Leversuch-Roberts</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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 !!!</description><pubDate>Wed, 12 Jul 2006 15:02:00 GMT</pubDate><dc:creator>colin.Leversuch-Roberts</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>&lt;P&gt;Good points in the article. &lt;/P&gt;&lt;P&gt; My $.02:&lt;/P&gt;&lt;P&gt;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. &lt;/P&gt;</description><pubDate>Wed, 12 Jul 2006 09:41:00 GMT</pubDate><dc:creator>John Langston</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>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</description><pubDate>Tue, 11 Jul 2006 15:44:00 GMT</pubDate><dc:creator>Peter Schott</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>&lt;P&gt;I totally agree with Colin!!!&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description><pubDate>Mon, 10 Jul 2006 11:44:00 GMT</pubDate><dc:creator>Robert Davis</dc:creator></item><item><title>RE: Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>&lt;P&gt;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 "&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description><pubDate>Mon, 10 Jul 2006 08:10:00 GMT</pubDate><dc:creator>colin.Leversuch-Roberts</dc:creator></item><item><title>Survive A SQL Server DBA Technical Interview</title><link>http://www.sqlservercentral.com/Forums/Topic290540-164-1.aspx</link><description>Comments posted to this topic are about the content posted at &lt;A HREF="http://www.sqlservercentral.com/columnists/jyao/surviveasqlserverdbatechnicalinterview.asp"&gt;http://www.sqlservercentral.com/columnists/jyao/surviveasqlserverdbatechnicalinterview.asp&lt;/A&gt;</description><pubDate>Tue, 27 Jun 2006 13:17:00 GMT</pubDate><dc:creator>jeffrey yao</dc:creator></item></channel></rss>