Interviews Part 2
-
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".
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
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?
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
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.
--
Adam Machanic
whoisactive -
"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.
-
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….
Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!
-
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.
-
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.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
<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?
-
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...
-
Exactly, Mike. That was the point I was trying to make.
You said it better.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
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!
-
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."
Quand on parle du loup, on en voit la queue
-
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.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
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
-
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
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
Viewing 15 posts - 31 through 45 (of 68 total)
You must be logged in to reply to this topic. Login to reply