How do you spell S-Q-L?
-
An excellent article!!!!
We've been doing some interviewing for SQL developers and about 1/2 the time I walk out of there saying hmmm..... well I guess we'll have jobs forever 'cause these people just don't get it.
Spouting facts is one thing but being able to actually walk the walk is more important - so the kinds of questions to ask are not what property does what, moreso situational like how would you fix the performance on an sp that does....
Mark
-
Very good article, having worked with databases 12 years, mixture of foxpro, sql server dba and currently oracle dba. I can totally understand a lot of points raised. You are employed for your technical skills and if you falter on basic questions, you should lose the opportunity, simple as that. I have lost brillant roles because i have struggled to remember basic sql syntax in the interview even i know the answer. Anyone can bluff their way into a role nowadays with basic knowledge, personality and the ability to sell yourself is more prevalent in interviews nowadays, as well as technical ability. For the record i know a lot of people who hold years of experience and mcdba, who in my honest opinion shouldnt be left alone near a calculator let alone a database server 🙂
--------------------------------------------------------------------------------------
[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] -
I've done both sides as well, and I've actually had a few good technical interviews given to me. The best was doubleclick where 3 guys interviewed me, round robin around the table for about 90 minutes asking questions. the worst ones are usually managers quizzing you on what you've done, and the "classis" interview questions, best job, worst job, deal with conflict, name a time ...
When I interview people, I'm mostly concerned with their personality and how they think, trying to find a match for them to fit in with the team. That's not to say I don't ask tough questions. I usually start working my way through some questions, adding in additional ones as they get things right and wrong. To me this is a good time to probe and find the boundaries of their knowledge.
However, I've not had the bad luck that Sean, and Andy, have had with some questions. I'd have terminated the interview after some of these questions because they display a fundamental problem: the person doesn't understand SQL Server.
-
I believe some of these folks have worked for me over the years
Most sound like they might benefit from a tidbit of wisdom that Chip Foose (a very prominent custom car designer) said his father passed on to him: "The most important education I ever received was the things I learned after I knew it all". Too often people, especially professionals, seem to forget that education is an ongoing process that ends only when your days on earth end. They learn just enough to get the job and presume that they know everything they need to know.
Even more irritating is the management philosophy of "not actually knowing anything", but being able to BS your way to the top. Unfortunately, most folks I have reported to fall into this category.
-
I bow my head in shame...
As a DBA with 8 to 9 years experience, I flopped on the Page Fault question... In an interview, because I would have been thinking of physical pages on disk, not memory pages and swap files, I would have most likely given a similar, and just as faulty answer. And worse, I would have thought that I was on the right track... I just looked up the Page Fault and realized that though I intuitively knew about the Page Fault problem (I ran into it when I was using Table Variables with very large table sizes) I never linked that name to it.
To think, I've gone all this time in my career, from one small company to another, the only DBA guy in each company, so no one to turn to, teaching my self as I read from books to solve business questions and get my certifications, I hold a MCDBA in SQL 7.0 and SQL2000, and yet I didn't know something as basic as the Page Fault.
Now I know that... But that doesn't relieve my guilt and shame. I mean, SQL is so big, and I know that there are thousands of other things out there that I still don't get. I feel like such a fraud. So, I was wondering, should I turn in my MCDBA's? And how do I go about doing that?
-
Don't feel bad Crish, I missed a lot of them, but I'm actually more of a developping guy so I never worked with the server itself so that's almost not totally wrong
. But I guess I could buy a book, and read it to correct the situation. - I'm surprised you didn't mention the actual spelling of S.Q.L. ... in our latest set of interviews more than one person applying for the job referred to their year(s) of experience with Sequel.
I don't know about the rest of you, but that was a pretty good indication to me that we didn't need to bring those candidates in for an interview. -
joshcsmith13, I hope you're joking, because otherwise you need to google SEQUEL and find out about the history of Structured English QUEry Language.
-
Fair point Chris but I assumed from Josh's meant that he once saw a CV (or similar) that talked about "Sequel Server". If this was the case I can understand Josh's actions!
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson - Thanks for the support Jamie. I too, understand what Chris is saying. However, as you aluded, this was an opening for an MS SQL Server DBA. Notice carefully the spelling/capitalization of "Sequel". And in each instance I can remember, the candidate did not have much experience.
-
While my background is in development (20+ years experience), I've spent the last decade managing fairly large projects that always have a database component. In that time I've hired dozens of DBAs for various positions, and come across more than a few whose answers to those questions might be more frightening than the ones listed. I've also come across aces, whose depth of knowledge impressed me greatly. Some of those aces just didn't work out, but the DBA types who couldn't answer simple questions have never worked out.
What strikes me though is that so many clearly inappropriate candidates apply for the positions in the first place. I find that roughly one third of my interviewees simply don't have basic skill sets applicable to the opportunity, no matter how well delineated the skill requirements are. I also find that with some of these people there is a degree of bluster that makes the head spin, and sometimes makes me, as an interviewer, want to shake them and beg them to find a career outside the industry.
But my best experience ever in hiring is what I wanted to relate. I had a candidate several years back whose CV was incredible, whose conversational knowledge was impressive, and who, during the Q&A part of the interview, began by setting a reference book on the desk in front of himself and saying, "I'm guessing the answers to all these questions are in here somewhere...but let's see how I do. You owe me coffee if I get more than 80% of them right." Not only did he get the first 15 questions right, and 18 out of 22 correct, he had the job before we reached the third question. It was a combination of pointing out the fact that a reference book and a human being are different, and because his first answer was given with a minimal use of terminology, kept short, and expressed in a way a non-DBA could understand.
What that taught me was that the best DBAs, like the best developers, have strong communication skills, are aware of their limitations as human beings, and are confident that they can overcome challenges. These are all traits lacking in the DBAs who haven't a clue, but then in a very real sense they aren't actually DBAs at all.
-
That's a case where I would follow up and ask them about it. From my experience, they're probably an old hand who has worked with much older database systems that SQL Server.
They could also be someone who doesn't know the history of SEQUEL and SQL, and are just parroting something they heard someone say. That's why I would ask follow up questions.
I've interviewed people where their resume said that they administered SQL Server clusters. When I asked them what type, they said "SQL Server." I said, 'No, I mean Active/Active, Active/Passive" etc. They didn't know what I meant. Turns out they changed the nightly backup tape in the server. Interview ended right there. You always have to ask follow up questions.
-
Frank raises an interesting point - that people shouldn't apply for these positions in the first place. I lay alot of the blame for this at the door of a particularly nasty type of person for which I have a personal disdain - the recruitment consultant.
- How many times has a rec consultant sent you a completely inappropriate CV?
- How many times has a recruitment consultant contacted you, as a job hunter, about a role completely unmatched to your skills, experience or job preferences?
"Many" I imagine would be the answer for alot of people.
Recently my company had a particularly unpleasent experience when a recruitment consultant targeted ALL our consultants that have a blog on our blogsite. When he contacted them he stated that "their email address had been passed on from a mutual aquaintance". Did he really think he wouldn't get found out?
That's how they work in the UK anyway. Scum, in my opinion!!!!
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson -
I, too, have been on both sides of that interview table. Technical interviews can be as daunting for the interviewer as for the interviewee. But I always appreciate someone who owns up to not knowing the specific answer AND can tell you where to find it.
You can never have to many reference materials, print, electronic or otherwise. I once heard that Einstein was criticized for not knowing his phone number. He replied 'Why should I remember stuff I can look up?' Granted, you don't want a DBA who lives in a book...he won't be very productive. But if he knows where to get answers in a pinch he'll be a valuable player.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson -
So, was the purpose of this article to make us feel holier than people who know less than we do, or inferior to those who know more?
Viewing 15 posts - 16 through 30 (of 77 total)
You must be logged in to reply to this topic. Login to reply