SQLServerCentral / Discuss Content Posted by Sean McCown / Article Discussions / Article Discussions by Author / Interviews Part 2 / Latest Posts

RE: Interviews Part 2

Ninja's_RGR'us — Wed, 04 May 2011 06:53:10 GMT

[quote][b]GilaMonster (4/30/2011)[/b][hr]Please note: 6 year old thread.[/quote]I wonder why it bothers you that people "activate" old threads?

RE: Interviews Part 2

jack-64275 — Wed, 04 May 2011 06:50:17 GMT

Point?

RE: Interviews Part 2

GilaMonster — Sat, 30 Apr 2011 07:41:01 GMT

Please note: 6 year old thread.

RE: Interviews Part 2

jack-64275 — Sat, 30 Apr 2011 07:08:52 GMT

Sounds like a REALLY poor interview... on both sides. If I had an interview with someone that had Sean's personality I would have walked out too. Not the kind of person I would ever work for / with/

RE: Interviews Part 2

Anipaul — Thu, 15 May 2008 10:46:50 GMT

80% of people inflates their resume. May everyone % of inflate in not same but they do.........:)

RE: Interviews Part 2

Vladan — Mon, 07 Nov 2005 06:11:00 GMT

Abuse of power? Make the individual feel lesser of an individual because of his knowledge base? Served no useful purpose?

These are some of the opinions about e-mail sent to the interviewee that I definitely don't agree with. While there is little doubt about the fact that it was neither tactful nor politically correct, it could have served a useful purpose : It said precisely what is the reason for refusing the candidate. I hate those answers that are polite and say nothing ("we found a better candidate") and I would prefer to receive an e-mail like this one. I would not feel "lesser of an individual" because of it, IMHO precisely these prefabricated politically correct answers are what can one make feel like a wheel in a machinery. This answer was personal, individually written, and for me it would be a proof of the fact that they really considered my performance and found it bad.

True, a few of the formulations used were more personal and more harsh than necessary, but nobody is perfect. People should be able to hear the true opinion of other about themselves and take it. They can disagree with it, they can think that the interviewer was wrong, but they can learn a lot from it - either that they don't know enough, or that they have problems explaining things they in fact know, or that this position was entirely different from what they are looking for... or even that they wouldn't like to work under such boss anyway. Much, much better than simple "access denied" error message you get so often

Thanks for sharing your experience!

RE: Interviews Part 2

demicoq — Mon, 03 Oct 2005 23:46:00 GMT

Well you had me entertained until you decided to send that sad excuse of an e-mail to the interviewee. It really showed your lact of tact and sadly you sent it from your company e-mail. It really showed an abuse of power on your part as the interviewer. I only hope I don't show my Jr. DBAs that kind of arrogance.

RE: Interviews Part 2

RUZHA — Mon, 26 Sep 2005 09:50:00 GMT

My recent reply was related to the author of the article.

RE: Interviews Part 2

RUZHA — Mon, 26 Sep 2005 09:43:00 GMT

DBA is very broad profession these days. There is no more only production or development DBA's or just database architects. The companies require jacks-of-all-trades in this position. As a result of that DA become the generalists, which is very negative tendency to the quality of DBA's work and level of expertise.

I am sure the base was there and if you will give a person right structure to work in and time you will see the results. No one knows everything and we tend to forget things that we do not touch time. I bat you have some areas where you are not good.

The task in interview the reveal potentials of the candidate and his strongest sides.

You were trying elevate yourself. You need to get over your memory caused by junior level years and srat to think as a team leader if you want to mentor and get the results of of it. So, your attacks, to the person that is obviously not that great in query tuning anymore, is unfair and shows some level of insecurity in you.

Can you give me in short paragraph the guidelines for the developer to evaluate the query performance without looking at show plan?

RE: Interviews Part 2

DCPeterson — Fri, 23 Sep 2005 19:01:00 GMT

"a varchar is a char that was left on the grill for too long"

I love it!

RE: Interviews Part 2

Joel-223127 — Fri, 23 Sep 2005 15:08:00 GMT

Which goes back to my original point... since there are no 'Junior DBA' jobs, the hoards of junior DBA's are going to inflate their resume's and try to squirm through the interview process to try to get a "Senior DBA' job.

The result for the interviwer is going to be a lot of people who look good on paper, that think that a varchar is a char that was left on the grill for too long.

However, from the interviewee's perspective, what choice do you have? You have to get a job somehow, and you don't want to abandon the education you just worked so hard to get.

No easy answer, is there?

RE: Interviews Part 2

David Poole-249495 — Fri, 23 Sep 2005 01:33:00 GMT

They don't call toilet cleaners, toilet cleaners either. They are either sanitation engineers or hygiene executives.

RE: Interviews Part 2

dm — Thu, 22 Sep 2005 22:40:00 GMT

Oh yes, I'm glad I took the job. The senior DBA's were great at teaching me although I did give them some grief from time to time. Like the time I made a production database "disappear" while learning about the SQL Server 6.5 copy object wizard. Funny, now I have a general distaste for all types of wizards...Since then I've moved on to other jobs, moving back and forth between DBA and Database developer positions. I'm currently a Database Engineer(developer) for a .com, and I get to work with SQL Server 2005!Diane

RE: Interviews Part 2

Adam Machanic — Thu, 22 Sep 2005 22:12:00 GMT

So how was it? Were you mentored? Do you feel that you were "brought up" well by the senior DBAs in the organization? Do you wish you'd taken a different career path?

RE: Interviews Part 2

dm — Thu, 22 Sep 2005 21:38:00 GMT

Actually, I started my IT career as a junior DBA (this was in 1999, before the dot com meltdown). I was working for a large private company in Minnesota and going to school part-time so I could switch to IT. The DBA group had 3 senior DBA's and they were looking for someone to do the routine work, i.e. set up users, backup databases, help developers with simple problems. But my situation is the exception, not the rule.Diane

RE: Interviews Part 2

DCPeterson — Thu, 22 Sep 2005 16:20:00 GMT

Yeah, I suppose your're right. I don't recall a DBA position with "junior" in the title anywhere.

RE: Interviews Part 2

Adam Machanic — Thu, 22 Sep 2005 16:11:00 GMT

Technically, maybe.But no one with 10 years of IT experience is going to take the job "junior"-ANYTHING. At least, no one I know.

RE: Interviews Part 2

DCPeterson — Thu, 22 Sep 2005 15:43:00 GMT

Doesn't every DBA start as a junior DBA? I see DBA's as being a senior level IT postition though, so a senior developer or admin might become a junior DBA. I doubt that I would ever hire somebody straight out of school, or new to IT, as a DBA. I want somebody with some serious battle-scars to watch over our data.

There are some jobs that just need a wide range of experience to be effective at and DBA and Data Architect are some of them. A senior DBA is a candidate to become a junior Data Architect etc... DBA is not an entry level job in my book.

RE: Interviews Part 2

Adam Machanic — Thu, 22 Sep 2005 12:05:00 GMT

Rick:http://www.sql-server-performance.com/covering_indexes.asp

RE: Interviews Part 2

qberttt — Thu, 22 Sep 2005 11:38:00 GMT

I have to agree with grasshopper. The email (although meant to be a wake up call for the individual) came across as insulting. The author did a great job in protecting his company and their interests by providing a fairly thorough interview and subsequent due diligence. That was his responsibility. What was ALSO his responsibility was to NOT make the individual feel lesser of an individual because of his knowledge base and that is the risk the email presented. Who knows what the individual was like. Would this be the one "life occurrence" that had lasting dertimental effects. One would think hopefully not but if there is one thing I have learned in my life thus far, is that just when you think you know something, poof. I can understand the frustration of the author but the leaders must lead. Now what the hell are these BOOKMARK LOOKUPS lol

RE: Interviews Part 2

Adam Machanic — Thu, 22 Sep 2005 10:58:00 GMT

I'd be curious to hear from anyone who actually started as a "Junior DBA". All of the DBAs I know moved from development or IT positions, and were at least somewhat-senior in those positions before jumping over to fulltime DBA (at which point they had enough general skills that they were no longer "junior"). I haven't ever actually met a person working as a junior DBA. Does such a person exist? Show thyself

RE: Interviews Part 2

J.T. Shyman — Thu, 22 Sep 2005 10:55:00 GMT

Adam, I agree with you and I don't agree at the same time.

I consider myself more of a systems administrator who also knows SQL to the level a good junior DBA would (I have no experience with design, but I can secure, backup and tune a SQL server pretty well, do DTS etc...) and I recently came across an opening for a SysAdmin where they wanted 8+ years of experience, an MCSE or MCDBA, knowldege of Linux, SQL, MySQL, Cisco, Apache, IIS, AS/400, Exchange, Sendmail and you have to carry a pager. This is in Atlanta. They were looking to pay $55,000 max.

Now, I asked some people about this and got two opinions...

The company has no concept of what a person like that is worth in the current market
The company knows but doesn't want to spend that much

In either case, the company will find someone to fill that position but, more than likely, the person will not stay more than a year. The person who fills that job will either be some down-on-his-luck out-of-work really good SysAdmin (like myself ) or will be a total liar. The person will either leave for more pay or be fired for incompetence.

I also agree with the previous post on it being damned near impossible to find a "junior DBA" position unless you happen to be in a company where they need that skillset and you can convince them to train you.

RE: Interviews Part 2

Adam Machanic — Thu, 22 Sep 2005 10:33:00 GMT

" Buko bucks (but not as good as it was 10 years ago)"Actually, that's the real problem I see with lots of job postings.- 10+ years experience- Expert in [insert every single technology you can think of, here]- $50,000/year max salaryUhh, yeah, RIGHT. What companies don't seem to get is that if you're going to ask for the world, you really need to pay for it.

RE: Interviews Part 2

Joel-223127 — Thu, 22 Sep 2005 10:22:00 GMT

Okay, I read this article and its predecessor, read about 100 posts related to it, and no one yet that I've seen has made this point yet. So, here goes...

Imagine this: You're a PC tech, replacing toner cartridges, swapping video cards and such. But you're interested it databases. So, you spend hundreds of hours, thousands of dollars, and get your MCDBA certification. You're just getting going with your database career, when ... you guessed it ... the company folds and you get laid off.

After licking your wounds (and blaming dozens of other people for your former employer's demise), you open up Monster.com. To your joy and amazement, you see the following job opening:

Employer: Blibnibitz, Inc. (My apologies if anyone is actually using this name!)

Position: Database Administrator

Salary Range: Better than a PC Tech

Experience: 0 - 3 years

Education: None necessary, will train on job. But an MCDBA or degree would be really nice, though.

Details: Need someone to make databases from our Excel spreadsheets for us. Must be willing to back them up once in a while, and is willing to take a stab at it if they ever need to be recovered. The ability to drag-and-drop the fields to a Microsoft Access form is a big plus.

If only it were that easy...

It's usually more like:

Employer: Blibnibitz, Inc.

Position: Database Administrator

Salary Range: Buko bucks (but not as good as it was 10 years ago)

Experience: 40+ years experience with RDBMS systems

Education: MBA or BS required. Must have thorough programming knowledge in T-SQL, PL/SQL, VB.NET, C#, HTML, XML, Java, VBScript, JavaScript, Perl, SQL Server 6.5, 7, 2000 & 2005, Oracle 8i,9i and 10g, MySQL, Sybase, MS Access, FoxPro, Windows Server 2000, 2003, Unix OS, Linux OS, Data warehousing, OLAP reporting, Query performance tuning, Embarcadero ER Diagramming tools, Hyperion, etc., etc. etc....

Details: Enterprise wide back-up and recovery of replicated databases on 1,000's of company servers. Responsible for multi-tier deployment including execution of system analysis and design for database systems. Apply critical security patches and perform database upgrades. Provide information by collecting, analyzing, and summarizing database performance and trends. Creating and executing DTS packages. Etc., Etc, Etc...

On one end of the spectrum, there is the true senior DBA. You know the type, the ones who seem to have had their brain surgically replaced with a multiprocessor clustered RAID 5 server at birth, and have retained every piece of programming knowledge that has crossed their path over the last 30 years.

On the other end of the spectrum, there is the "Tommy Lee goes to College, Part 2: Tommy Lee learns SQL Server" crowd...

"Tommy, what's a clustered index?"

"Uh ... huh, huh ... the black book where I keep chicks' phone numbers in?"

(...and he's a multi-millionaire ... go figure!)

However, most of us fall somewhere in between...

Now, of course, most businesses are reluctant to trust development, administration, and disaster recovery of their business-critical data to someone who has "done it once in a lab environment." It doesn't sit well with managers and investors. I understand that. However...

The moral of my story is this: Until there are some sort of job openings, from companies that are willing to take junior DBA's and train them to get them up to speed, then junior DBA's will continue to lie on, or otherwise artificially inflate their resume's, just to get their foot in the door. If you're in the situation of the guy in the first paragraph, as many are, you aren't God's gift to SQL Server yet, but you need to put food on your table until you get there.

Thanks for humoring me.

P.S.: Experience: 40+ years experience with RDBMS systems? E.F. Codd released the DB relational model in 1970, which was only 35 years ago. Did you catch that first time through? Something else to watch out for!

RE: Interviews Part 2

Silverfox — Tue, 20 Sep 2005 10:41:00 GMT

Excellent article, I totally agree, having worked as a sqlserver dba for about 3 years and working as oracle dba atm, it is a sad state of affairs when people can waltz into positions say they have 10+ years experience and end up falling flat when an emergency happens, it does nothing but give the rest of us a bad reputation and make it harder for the rest of us to find work. I have never considered your seniority to be based on service, but on experience gained and what you have learnt, i cut my teeth basically on replication and disaster recovery so i suppose i consider myself senior as regards to what sort of dba i am, what can you do, i cannot say i am junior, it limits the work i can go for, knowing that complete idiots get into interview by stretching the truth on their cv, anyway enough of my rant, i liked the article and thought it was very relevant

RE: Interviews Part 2

LappinM — Mon, 19 Sep 2005 21:56:00 GMT

As a graduating college student I believe I am decent with MS-SQL server and I admit I'd have to stop and think on some of the questiosn in the article BUT that being said I am trying to find a replacement for myself at the law offices where I work where we use a commercial management product. We are currently on our second person. Our first person we recently just got rid of. He came to us with experience in MS SQL 7, 8 and 2000 on his Resume --- the SQL 8 should ahve been the first clue but our HR director insisted that this was a typo; he also had years and years of experience in DBs and everything else. This small company -- 30 employees or so --- the sole IT guy needs to be a jack of all trades and master of many.

We hired him, i went home for summer and came back. over the summer any time when any kind of "advanced query" needed to be made --- advanced meaning anything that required a query with more then a basic inner join he'd call me. About 2 weeks ago now I'm in my sedimentary petrology class (truth out: I have a BS in Computer Science, I'm not sure I want to stick to computer science but have an interest in geology so I'm taking some extra classes and looking at option for graduate school) --- somebody comes and tells me "your office is on the phone, they said <<application here>> is down" --- I leave class check my e-mail and the IT person e-mailed me the updates he wanted to run (did he wait for me to check them ? no!) ---- well, the updates didn't put the right data (not even the right data type) in the fields --- ok, so yes, I realize this is a poorly designed database if it allowed that to happen --- if somebody wants to get some good laughs track me down and I can make your sides hurt with these schemas; but he should have beena ble to figure out you don't put varchar data in a field that has integers in it (even though the datatype on the field is wrong but thats aside the point!) --- crashed our ENTIRE document management, front office managemetn, contact and billing system.

Now the "fix" was really easy --- granted we had about 1200 items that had to be manually cleaned up and 8500 or so manual but with as much industry experience as this man claimed to have had, he should never have made this. Much less, I should have been learning from him, not him learning from me.

to the author: I very much enjoyed your article.

to everybody else: if anybody has some free time, as somebody whose going to be job hunting in January, I would very much appreciate any pointers on how to fairly assess my current SQL server skill set. I think I'm pretty good but that is from the people I am around; I've not had the opportunity to really learn from "experts" -- my internship did not have a DBA, just another developer who knew a little more about databases then the rest and they were coming to me for help so I'd really apprecaite some feedback on figuring out where I stand if anybody would be willing. You can reach me on AIM as TNGData usually.

--MAL

RE: Interviews Part 2

J.T. Shyman — Mon, 19 Sep 2005 18:44:00 GMT

New word for the dictionary:

Abnormalization: The process a DBA's brain undergoes when looking at a database created by someone who cannot spell SQL or thinks that T-SQL is what came after S-SQL.

RE: Interviews Part 2

PBirch — Mon, 19 Sep 2005 16:48:00 GMT

Sad but true stories. We could sit around and talk for hours about the foolish. I think Sean is right - SQL Server has been advertised as easy and wizard-friendly. We run into immediate problems where the database-challenged can not find a wizard. We have all run into the database design from hell - created by someone who was either a developer (is that similar to dabbler?) or someone sort of familar with drawing boxes. My favorite was the stakeholder in a project actually drew some random boxes on a paper and expected us to create a system. He had created something in Paradox that didn't work, but he decided it was just a flaw in the application design. Certainly, not his design. I have also been in project development meetings with the client where the client questioned me on why I had so much time devoted to database design. "Bill here," pointing to his overworked network guy who sort of knows Access, "could do that in a couple of hours."Normalization is just a long word in the dictionary.I have also worked with a client who promoted one of their folks to the DBA position. He knew nothing, but he was already planning to quit in six months to find one of those high-paying DBA jobs, now that he was a DBA. He was let go after four months because he frustrated his boss because he did not know anything and would not take the time to learn. He asked if he could use me for a reference. I said "No."

RE: Interviews Part 2

Dan Cioffi — Mon, 19 Sep 2005 15:22:00 GMT

In my experience, I know enough to get things done, up and running. I know I'm not a 'true' DBA, but in a small environment, I can keep a database going. But at heart, I'm a website developer and applications developer.

You know what is amazing though? I get calls and emails from recruiters all the time, and they see extensive applications work on my resume, and where I list the DB's I've worked with (SAQL Server, Sybase & Oracle to name a few), the recruiters figure you're a DBA. And then they try to sell me on being a DBA so they can land the contract. I politely say I don't have the experience to be a true DBA, and I want a developers position. Yet some get very agressive and tell me to think about it, or ask how we can 'tweek' my resume so I look more like a DBA. I've even had a few who have said the position was a mix of DBA work and coding and when I get to the interview, I discover there's no development work, they want someone to be a full time DBA. So sometimes, it's not just the candidate, the recruiters are also at fault.

And you are right, ProveIT and Brainbench show nothing more than your ability to take a test. The most they can show is book knowledge. Brainbench had a free weekend a few months back, take as many as you wanted for free over a weekend. I took about 20 tests, I came to discover I was also a damn good sales & marketing person, I knew enough about the travel industry to be a travel agent and could also run a 4 star hotel! Go figure!

RE: Interviews Part 2

J.T. Shyman — Mon, 19 Sep 2005 15:03:00 GMT

Exactly, Mike. That was the point I was trying to make.

You said it better.

RE: Interviews Part 2

Mike C — Mon, 19 Sep 2005 15:01:00 GMT

For data warehousing and some other specialized applications, de-normalization might be the correct move. And you're right, trying to fix a broken schema after the fact can be a serious hassle.

Like you said though, developers and DBAs should be working together to implement the best possible solution. I would just add that this should be done from the beginning of the project. As an example, if you're storing the same data in umpteen separate tables of a database, you might be able to write a faster/simpler query here or there, but you and the developers will have a difficult time keeping all of the data current throughout all of the tables simultaneously. I see it as a "pay now/pay later" scenario. Too many people choose to pay later...

RE: Interviews Part 2

Mike C — Mon, 19 Sep 2005 14:53:00 GMT

<quote>I'm really thinking about putting together a series on interviewing… how to prepare, what to know, what not to know, etc. It seems kinda like a no-brainer, but the more I interview people, the more I see more people need this than I thought. Anybody interested?<end quote>

I think a series on interview techniques would be great. Trying to tell people what knowledge they need to take to an interview is very subjective though. I've had interviews where very few technical questions were asked. I've also had interviews where I had to design fully-normalized databases with as many as 10 tables on the spot; and explain my design decisions where they differed from the answer the interviewer had decided was correct!

Different companies have different standards - one company might hire a junior DBA whose sole function in life is to babysit a couple of servers, and get them back up quickly if they crash. Another company might expect their DBA to take an active role in the creation of databases. Another might expect their DBA to split time between DBA duties and developer duties.

Maybe a series on core DBA responsibilities, explaining how to do various functions, with step-by-step examples would help? I know that many of the articles here assume an experienced reader base, and sometimes we neglect our newer peers that haven't been in the field that long...

Although I don't have time to write up an entire series myself right now, if a few other authors are interested I'd be willing to chip in on a series that would map out the core DBA abilities we feel our newest peers should possess (i.e., Security Management, SQL DDL/DML, Query Optimization, using QA, using Profiler, using EM, etc.) IMHO, the best way to prepare for an interview is to know - not memorize - but know how to perform the task at hand.

Any takers?

RE: Interviews Part 2

J.T. Shyman — Mon, 19 Sep 2005 14:52:00 GMT

I said "needlessly sticking to 4NF or 5NF isn't efficient" Perhaps I should have been clearer. Many databases I have worked with are not even 3NF, let alone 4NF or 5NF. There are times when it is beneficial to de-normalize data to some degree, is there not? For performance reasons, perhaps, or for development reasons. Or for ease of use reasons. So, yes, I believe that any database designer who steadfastly designs all tables to 5NF and refuses to change them even if performance suffers or development is more difficult is wrong.

As for Normalization making development easier...it can, but not always. Many of the databases I've worked with were created by the very developers who are also writing the code. They create the tables around the programming and not around the data (how many of you just shuddered? Be honest). In this case, going back later and normalizing the data could very well be detrimental to the program and developers.

Developers and DBAs must be able to work together, communicate and learn from each other for any database application to be developed, deployed, maintained and used well. In this I have to take issue with some of the "us vs them" mentality some members here seem to have. I, for one, think I will be a much better DBA if I know some coding and prefer to work with coders who want to learn about databases. Of course, none of us live in a perfect world and everyone thinks they are above average (mathematically impossible) at what they do.

RE: Interviews Part 2

Shoby — Mon, 19 Sep 2005 14:15:00 GMT

A series on interviewing!! That will be awesome. I loved your article. Being a Jr. DBA/Developer, I would love to read more indepth analysis of interiviews do's and dont's and stuff like what junior and senior DBA's are expected to know. A similar article on SQL Development would be great too.

RE: Interviews Part 2

Crispin Proctor — Mon, 19 Sep 2005 14:04:00 GMT

I have to agree with Jesse. Not once have I ever moved into a position where I knew everything. That would make me think I am moving sideways at best, down at worste. Why move if you not going to move up? The unfortunate thing is some people take that to the extreme. That causes suspicion amongst some companies who have been burnt.

Another aspect to look at is the agents...

I have some, not all, hint that I lie and wing my way through the interview. Some even coach me based on previous interviewees they sent. Some of them are nothing more than people who work at Honest Joe's Second Hand Cars sales. Do and say anything to make the sale.

I have found the only way to have a good pay rise is to move. You can, if you want sit at a company for 25 years and get your annual 5% increase. You can also move around a bit and get decent increases.

I know the last comment will upset some. So far, I have not had 25 years of a working life. Far from it. I have been in the game for years and worked at 4 companies, onto my fith now. (To my current employer, I have no intention of leaving )

I do this, other than the obvious, to gain experience in the field. I am a youn'in compared to some / most. I want to see what's out there before I decide on a path. Banking, Insurance, Retail, Software etc.

On none of those moves did I go sideways, I always opted for something that was higher than current. Why not? Progression...

To the one of the posters, can't remember the name, where do you find your candidates? Either the company as a flaw that it went through 6 DBA's in two years? Either you have to high a expectation of someone (Asking one person to look after 1800+DB's?) and causing them to leave or you managing to weed out every single chancer DBA that walks the earth. If the latter, could you please post a list of their names? Whatever the cause, I think some of your statements are unjust. You cannot persecute everyone because of a problem only you have seen.

At what point do you change from Junior to Senior? I did it when I accepted a job as a senior DBA. If I did what most of you are saying, I would still be a junior. You have to take the step out of your comfort zone!!!

Anyway, that’s my rant….

RE: Interviews Part 2

Mike C — Mon, 19 Sep 2005 13:56:00 GMT

"Gee, naive as I may be about SQL design (I can do the day-to-day admin stuff pretty well) I had thought that the database was about the data and making it useable to the developers who are writing the code. Needlessly sticking to 4NF or 5NF (yikes!) isn't efficient, is it?"

The Normal Forms help make your data "useable to the developers who are writing code." What do you consider "needless" about properly normalizing a database? I find that it's far more efficient to update and manage a properly normalized database than one that is slapped together with no regard for the data integrity that normalization provides.

RE: Interviews Part 2

Adam Machanic — Mon, 19 Sep 2005 11:56:00 GMT

Whether or not it's efficient, it's impossible to determine normalization or quality of "design" without an understanding of the data. You were definitely correct to ask that question.

RE: Interviews Part 2

J.T. Shyman — Mon, 19 Sep 2005 11:35:00 GMT

SQLBill, you are 100% right (as is everyone else who has been saying this). Microsoft, in its push to make its own technology more ubiquitous has made it so anyone with a slight amount of knowledge and training can call themselves a DBA. I had the Exchange admin at my previous job set up a database, all by himself, on a SQL server he installed, all by himself. He didn't need a DBA for that. That's fine, I guess. But he sure as heck needed my help when a runaway script locked some tables and stopped his work cold.

When I asked him why he had set up the database I was told, "So I could put it on my resume."

Strangely, I am having the opposite problem now. I have touched so many different things, and really worked with so much, that my resume is jumbled. I've taken to calling myself a "Systems administrator". Problem is, the IT market where I am is making a move toward "experts" and away from generalists like myself. I wonder how many of the "DBA"s out there are really generalists who decided to pick up a title to get a job?

RE: Interviews Part 2

J.T. Shyman — Mon, 19 Sep 2005 11:29:00 GMT

dataOverall, I liked the article but I have never, not really ever having applied for a "DBA" position instead of a "system administrator/dba" position, been asked questions like those. I have been asked questions where I was shown a diagram of tables and ask what was wrong with it. Boy, it that a poor question! Especially when I answered with, "Well, what are you trying to do with the data and can you give me some examples of the data?" and the response was, "That isn't important, look at the design."

Gee, naive as I may be about SQL design (I can do the day-to-day admin stuff pretty well) I had thought that the database was about the data and making it useable to the developers who are writing the code. Needlessly sticking to 4NF or 5NF (yikes!) isn't efficient, is it?

Now, here's my question for the peanut gallery: How do you deal with someone who interviews you or who you work for who is convinced they are the best DBA in the world but you know more than they do? I am talking about the person who says their database design is "fully normalized" but lacks candidate keys in any table because "there isn't any data that would work so I put an ID column in every table".

RE: Interviews Part 2

SQLBill — Mon, 19 Sep 2005 11:25:00 GMT

I'm interested. While I know my job pretty well, I am always looking to improve it. One thing I do is look up terms and concepts that I'm not familiar with or infrequently use. I've learned a lot that way. Never having had a mentor or trainer, being the only SQL Server DBA and self-taught at that....I'm sure there's lots I could improve on.

That said....I think a big problem with SQL Server DBA's is that Microsoft made it too easy to use. Enterprise Manager can do almost anything for you. Look at the questions on this site....there are always questions about why a maintenance plan didn't work the way they were expected. And the poster doesn't even know what the maintenance job is doing. I prefer scripting everything that I can. Enterprise Manager will even create scripts for you, so that you don't need to know TSQL. I use Query Analyzer and am trying to learn command line programming. Will this make me a better DBA? I don't know, but I do know that I am learning more about my job.

-SQLBill