Interviews Part 2
-
I agree that your email response to the candidate was unprofessional, and served no useful purpose.
Having been asked some very similar questions in a recent interview, I also did not know all the answers "off the top of my head". Granted your candidate had some very interesting (disturbing?) responses, but it should be clear that there is a distinction between obvious exaggeration or incompetence, and the useless ability to store everything off the top of one's head.
E.g. when a query is not performing well, and I see a Bookmark Lookup, or Index/table scans, I look it up again and resolve the issues. Unless similar issues creep up again elsewhere in a relatively short period, I am likely to forget the definitions, differences, etc.
Thanks for the article.
Terry
-
Just for information purposes are bookmark lookups bad and if so how do you reduce them?
-
Nice article on Bookmark Lookups. They are not always worth getting rid of.
http://www.sqlservercentral.com/columnists/RDyess/bookmarklookups.asp
-
I don't believe everyone inflates their resume. I don't.
-
Personally I'd prefer the honest approach taken in this article. As an applicant I would take the specific reasons why I was not selected and try to build on that. That way I'd be better prepared for the next interview. In fact, the applicant might well have used the opportunity to respond to the criticisms about his performance in a professional manner, and who knows? He might have been able to turn the situation back around in his favor.
-
I am a very junior DBA. I got my MCDBA last May and am working in the field in a limited capacity. I know that I cannot answer a few, but can most of the questions that were listed in the replies and the article. For example, the Query Tuning. I can go to the execution plan and make informed decisions on how I can make the query better. But to provide the what the specific things are I cannot. (I will before today is over.) I guess my question is, Is it better to inflate your resume to get in the door and then be honest about what you know. Or to play it straight accross the board. I have not looked for a job since I received my cert as I am still with the same company, but at some point I know that I will. It would be very helpful to get an idea of what the people hiring for these positions are looking for and what would be refreshing to hear during the interview process. For one I would rate myself higher than I could justify on the spot. But other than that what is the best way to one get your foot in the door and two, land the job.
-
The first indication that something is wrong with an applicant is that he rates himself "11" on a scale of "1 to 10". That's a clear indication that they don't understand the concept of check constraints.
-
I'm sure someone will write an article, but here's a shortlist to tide you over:
- Normal forms (I would recommend knowing up to 4NF at least): Why is it important? What does it mean? How do you implement it?
- Standard ANSI SQL keywords and usage (I would recommend at least to ANSI SQL-89 as a bare minimum)
- The difference between DDL and DML
- The differences between Clustered and Nonclustered Indexes: When should you use each? What are the advantages/disadvantages of one over the other?
- Primary Keys, Candidate Keys, Surrogate Keys, Foreign Keys: What are they? Why are they important? When do you use them?
- Unique Constraints, Foreign Key Constraints, and even Check Constraints: Again, what are they and how do you use them?
- Data Types: the basics - INTEGER, CHAR, VARCHAR, NCHAR, NVARCHAR, NUMERIC, etc. When would you use each type? How do you define a column as a specific type? How are the types like CHAR and VARCHAR different from one another?
- NULL: What is it and how do you use it?
This list covers enough of the basics to design a decent database. Once you have played with these, and know them well, you should get experience with advanced (and SQL Server-specific) topics, like Stored Procedures, UDFs, XP's, Query Execution Plans, Filegroups, Server Configuration, how to use Profiler, etc.
The key is not to just memorize the definition of - as an example - "First Normal Form", but to actually *know* what 1NF means, why it's important, and how to achieve it. That kind of knowledge (for me anyway) comes from actual experience as opposed to memorization or certification exams.
-
I find this article to be exemplary of what I believe to be an inexplicable hostility in many technical interviewers. Over the past three months, I've been on multiple interviews for DBA positions. I have received four offers to date so I believe I'm not completely incompetent. Nevertheless, I've noticed a disturbing trend.
Often you will find that the interviewer is not there simply to determine if you're right for the job, or have the skillset needed, but instead to make it his personal quest to expose you as a fraud. I think interviewers need to remember that the process is to determine if the hiree is a good fit. The point is NOT to become a cross-examining Perry Mason who makes the witness break down and admit to a cold-blooded murder.
Yes, it's wrong to inflate one's resume, yes, it's wrong to overstate one's skills, blah blah blah. But how many people here can say they never went into a position under qualified and still did a fantastic job in the end? I really wish interviewers would not take this whole process so personally. Or become so outraged when they come across someone less qualified than them. It would make interviewing more bearable for everybody.
-
What a joke. People who can't handle brutal honest feedback are generally suckers trying to hide their lack of intellgence. Being (PC) Politically Correct is for the chumps. I applaud the email that was sent to this candidate, it's obvious that his ego needed this dose of reality.
A.J.
DBA with an attitude -
While I wouldn't want to be on the receiving end of the email, I tend to agree that this person needs to come back down to earth. I worked with a guy for a year that was supposedly senior to me that didn't know some of the basics. I ended up directing his work from time to time...
I tend to go the opposite way on interviews - way honest. I never rank my self at the top - there is always room for improvement.
Laurel
-
"5) Give me a table-only design (don't worry about columns) that would support a parking garage function."
This is an interesting question. Extremely open-ended! Does the database have to keep a history of all of the cars that have parked, and in which spaces? Do various cars (owners) have various rates depending on what they're negotiated with the owner of the garage? Do we need to support people who haven't paid their bill on time? What about towing?
I think there is actually a lot more interesting stuff to delve into in terms of the columns. For instance, I would expect a qualified candidate to note that some sort of constraint is necessary in order to guarantee that only one car is parked in one space at any given time... Unless, perhaps, they're two smallish motorcycles...
--
Adam Machanic
whoisactive -
Ha! That gives me an idea. Put this on a questionaire:
Rank yourself on a scale of 1-10 in the following 4 areas, keeping in mind that the data will be stored using a unique non-clustered index on the rating:
T-SQL
DTS
Security
Stored Procedures
See how many people wind up using the same number for more than one area.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
That's pretty good. Then give then eleven questions and tell them to rank themselve 1 - 100 Haha ...
A.J.
DBA with an attitude -
<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'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
Viewing 15 posts - 16 through 30 (of 68 total)
You must be logged in to reply to this topic. Login to reply