Jeff Moden (12/24/2013)
So far as going in prepared goes, you've absolutely hit the nail on the head. I normally don't even let them start. I dig stuff out of my briefcase and say "Before you start, let me show you some of the things I've done."
I'm not that quite aggressive, but I have a nice portfolio that has my resume's, my certifications from websites that show I'm not a newbie (EE), examples of code I usually use, education, and some other stuff.
When I drop that on the table and open it up it gives the interviewer an idea that I have a clue and not a blowing it out my butt.
But one of Steve's post I have to argue about. The DBA Job Description: What type of DBA are you?[/url] post has the comment:
I don’t like this model because it creates a divide between production and development DBAs. This divide could lead to the production DBA asking the development DBA, “How in the world could you hand me this?
I was in that situation. If you have a good dev staff with a good dev DBA that should never happen. You will always have end-user abuse of a DB. That is what the support DBA does. When he does find a bad programming stuff he then reports it back to the dev team to correct. A good dev DBA means it is usually user error. Only rarely should a support DBA have to say WTF?!?! And if he is it should go up-channel.
Having been mostly a production DBA in an end-user company and a SW company, none of it is cut and dried.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.