August 9, 2005 at 11:52 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sMcCown/howdoyouspellsql.asp
Watch my free SQL Server Tutorials at:
http://MidnightDBA.com
Blog Author of:
DBA Rant – http://www.MidnightDBA.com/DBARant
August 17, 2005 at 11:37 pm
Q: What’s the different between char() and varchar()?
A: char() only holds letters while varchar() holds letters and numbers.
Experience: This DBA has 8yrs.
If I hear such answer even from a person with 1 year of Exp I do not even ask the second question. Infact I even do not ask such question beacuse I assume whoever is applying for a DBA position should know the answer.
The best part will be if he is looking for a Senior Position with a salary of 100K+
Anyways I know a company who is looking for a Senior DBA (Contract to Hire) in Sacramento. If anyone is interested please email me your resume at amitlohia@hotmail.com lastest by Aug 25 2005. No H1B and third pary
Note: I will forward your resume and you will hear from the company directly. I have nothing to do with hiring process. I am sure they will have a technical interview
Amit
Amit Lohia
August 18, 2005 at 1:27 am
My 'dummy' question - "What is a clustered index?"
DBA for 8 years -> "Alot of indexes working together"
ROTFLMAO
August 18, 2005 at 1:52 am
Crikey !!!
I am by no means an expert/guru, mind you I don't like those words - we all have something to learn. But my God - this is basic stuff. Is this a common experience of interviewing for DBA's?
I know your probably frustrated but thanks for the ego boost
August 18, 2005 at 2:47 am
Hi,
I'm actually going to an interview today with one of the larger city banks and I'd like to give you my take on the receiving end of the interview game.
Yes I do agree that people who claim to have years of experience should know the fundamentals but is that really how we measure a resource. I’m no DBA but I do have a good idea of the difference between a char and a varchar but I couldn’t give you a text book answer of the top of my head. In fact, in many an interview I’ve made that school boy error of over selling myself and then having to guess at an answer hoping you know just abit more than the guy asking the question.
I know its wrong but being put under pressure that your not accustomed to sometimes causes us to do stuff we wouldn’t in a normal work environment. We are human and do get things wrong.
I really think IT interviews do need to look closer at more social aspects like the ability to own issues and work in a less than ideal environment. Coincidentally, in my experience of interviewing I’ve often found that people that come across as not totally confident and don’t have all the answers often do better. They are just people that have the right team fit and show a willingness to learn. I’ve always believed you can learn and teach technical skills but it’s much more complicated changing personalities and attitudes.
Thanks,
Chris.
August 18, 2005 at 3:01 am
I was tutting at all the responses you got but then got very worried at the end when you talked about not knowing what SEM was used for. For a moment I thought I must be one of the people you were complaining about, until a quick Google told me what SEM stood for. I'd just never come across that particular abbreviation before, which I suppose shows how easily you can be thrown, even if you do actually know nwhat you're talking about.
--
Scott
August 18, 2005 at 3:02 am
Hmmm, I know the answer to some of those questions! How much does a senior DBA earn in Central London.
August 18, 2005 at 3:09 am
I work in the city and £50k minimum I would say. A colleague and myself were looking on Jobserve the other day and there were senior SQL DBA jobs offering £100k+. Remarkable!!
-Jamie
P.S. I am not a DBA and I don't earn 50k
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson
August 18, 2005 at 3:25 am
Just put my Amazon order in for "The DBA's Bluffers Guide"
August 18, 2005 at 3:53 am
Having been both sides of the interview desk, I can see both sides of the argument.
I've had candidates who can give chapter and verse with technical answers learnt out of books but no idea how to operate in the real world.
I've seen people who make stuff up, just as shown here - and that's more scary because they will tell bare-faced lies and don't own up to what thay don't know. Do they even know how ignorant they are?
The best approach I think is to be honest about what you know and don't, and if you don't, but have a better answer than BOL for what you'd do, for me that's worth having. I would never expect someone to have all the answers, and they may know lots that I don't ask about - but I do want them to be responsible about what they would do when faced with something they don't know about.
2 examples from being the interviewee, years ago:
1. Part programming, part electronics job; the question was about RS232 serial interfacing. I didn't know the answer (which pin does what) but truthfully said I could picture the page of the book I would find the answer in. I wouldn't guess, because who would want someone to do that live? At best, you'd waste time and solder. Result: a job offer.
2. VB5 development job; first question about some property of a TreeView control. I'd done a lot of VB GUI work, but not actually used the TreeView - never needed it. But I knew that with the help, MSDN, etc, I could have a good solution up and running fast. Result: no job offer - they thought I was lying about my GUI experience.
Conclusion: ask / answer questions carefully - who really wants a sometimes-honest factoid spouter? You want someone who'll do a good job and react in the right way when they reach the limits of knowledge.
Mind you, if the limit of knowledge is the char vs varchar thing then all hope is lost...
Bill.
August 18, 2005 at 4:21 am
I've been on both sides of the interview desk also.
When hiring, it's not just all technical, but if they're coming in for a technical job, they better be able to make a reasonable statement as to what the basics (and some of the finer points) mean, when under pressure.
Being a DBA means that you end up having to explain to non technically literate people exactly what it is you're trying to achieve, and why they should refrain from calling you every 2 minutes when the servers are down.
If the can't make a decent, and unambiguous answer in interview, why would I trust them in an emergency situation?
That being said, the guy who seems to have a clue about the big picture, but is just a little rusty as to the implementation (knows design methodologies and good practice processes, just doesn't know the syntax for the particular DB/System), and puts their hand up saying "Until I get used to it, I'll be reading the manual a lot" gets treated seriously.
I'm a firm believer in maintaining a small library of books. I may not know what I want to know to achieve something all the time, but give me a little time, and I will do.
The final swing to it is indeed personal. Someone may be highly skilled, and technically superb.
But if I don't think I can comfortably work with them shoulder to shoulder when the world going awry, then they're far less likely to get the role.
Ten to fifteen years ago, the tech world was a different place, and you could get by with being an eccentric locked away from sight performing arcane duties. These days, you need to be a businessman, advisor and hard core tech in one.
August 18, 2005 at 4:52 am
Excellent article and thread
My 2p - in interviews I deliberately ask one or two questions nobody in their sane mind outght to know the answer to immediately - the most valuable answer you can get from an interviewee is 'You know, I just don't know the answer to that question. I could guess, but I'd much rather look it up in BOL, MSDN, etc'. I want to know that an prospective employee/colleague can admit to not knowing everything (let's face it, nobody can know everything about computing these days, not by a long straw), and more importantly, they know how to find the authoritative answer!
Of course, cultural fit is crucial, knowing you can work with somebody and that you can trust them to get on with the job is more of a gut feel thing, however technical questions are really useful interview tools
August 18, 2005 at 5:13 am
I have a similar list of basic questions I ask DBA candidates and am often surprised at the discrepancy between stated experience level and the answers given. Even worse is that I am not necessarily looking for the correct answer. If a candidate says that they do not know the answer and then proceeds to describe how they would go about getting the answer, that is as good as answering the question correctly. More often than not I turn to BOL, MSDN, SQLServerCentral or other resources to get answers to questions. An ability to critically think through the question and knowing where to find answers is every bit as good (if not better) than being able to spout the answer from memory.
Of course, some items should be ingrained: like the difference between a char and a varchar. Other things (e.g. how to fix a page break) can be easily looked up and one should know how to use the resources at hand. Even with 10 years of experience, they may be items that one has never encountered. A DBA could easily go 10 years without ever having to work with Replication, or clustered servers, or a number of other items. That is why I always ask candidates how the go about learning new techniques and where they turn to for answers (searching the internet is not acceptable as the only answer!).
Gordon
Gordon Pollokoff
"Wile E. is my reality, Bugs Bunny is my goal" - Chuck Jones
August 18, 2005 at 5:17 am
My 2cents (South African cents = +- 0/16 p )
The "SEM" also through me. I refer to it as EM, or more frequently as Enterprise Damager ... (too many users have had access in too many places ... *sigh*)
I can add a few:
q> What is your opion of nulls?
a> (2nd time around, after asking if we could come back to it) they are used to enforce referential integrity.
This was from someone who had impressed the tech-manager by getting 90+% on the measure-up MCSE questions that we sue to pre-filter applicants. Needless to say, the interview went seriously downhill from here, but I did manage not to laugh in the interview itself, but it was a total guess session (and he wasn't good at guessing).
August 18, 2005 at 6:50 am
Can you tell us what those questions are.
Viewing 15 posts - 1 through 15 (of 77 total)
You must be logged in to reply to this topic. Login to reply