How do you spell S-Q-L?
-
I can relate wholeheartedly to the dreaded Recruitment Consultant!
I was made redundant at the beginning of the year from an application development role (off-shore outsourcing but that's another subject!!!)
I was sent to an interview for my "Dream Job" which was sold to me as a SQL developer role - the interview lasted literally 5 minutes. He explained in depth the role and I explained I was completely the wrong person for him. Game over.
The company wanted a Crystal Reports Writer with a little SQL. I'm (hopefully) a SQL guy with a little Crystal.
When I had a go at the Consultant he said - "I thought you could wing it".
I had so many totally inappropriate calls from consultants it was crazy - all they were doing was matching words from the spec to the CV. I had something on there as "limited exposure to" as an extra to my main skillset and I'd get calls looking for guru's
Rant over - That's better!
-
As to the holier than thou...
I don't know. We're talking about BASIC background knowledge necessary to do your job. Now, depending on your specialization, I can understand not knowing one or two (like the development background person not knowing Page Faults).
It's kind of like someone applying for a job as an accountant not knowing first semester accounting subjects. There should be a minimum level of knowledge before you try to secure an offer from a company. It's plain dishonest to intentionally mis-represent yourself. It is also very necessary for companies to weed out people who are not competent, as their profittability is at sake (not to mention lawsuits, criminal charges, etc.) if they hire someone who is not competent to do the job.
-
I've enjoyed reading this thread.
I was reading CVs for my job when I left my last place (cool - pick your successor) and the rubbish we were sent. Senior SQL Server DBA in an MS shop.
So by the time we'd filtered out the Oracle DBAs, the guys with 6 months contract work on MSSQL 4 years ago, the NT admins who can spell SQL, the developers with VB and Crystal and .net and Java (...and some SQL) etc.
But I agree with most posts - you have to have some basic knowledge. It is essential. I also agree that the ability to say "I don't know, but I'll look in BOL" or to say "I think... but need to check" or "It's DBCC XXX but I'd have to check exact syntax and effects" is vital rather than winging it or simply bullsh*tting.
Mind you, I'd rather go up against these guys when I'm going for a job...
-
I've harped on this before but those kinds of employees are every where, like fleas on a dog. It's not their fault that they are in an important position with lots of experience ...the are not incompetent, they are just ignorant. The fault lies with the guys the hired them , IT management. They continue to be incompetent by selecting the wrong tool (an employee) for the job. It's remarkabel that they get away with it. Imagine what would happen on the auto assembly line if the manager passed out 12mm wrenches to all the mechanics putting 10mm bolts on engines ... how long would he be allowed to stay ??? Yet, in IT, those managers continue to keep their jobs. Look what the ex president of HP did .. she darned near ruined HP and Compaq's reputation and stock before being "allowed" to retire. ... Did you see the money she got on the way out the door ??? I have watched data processing in America go through an intellectual recession for about 15 years now, ever since the advent of the personal computer where Joe Blow store clerk can learn VB in his basement and slowly creep his way into the IT business with out any formal training or mentoring. The mentoring is the most important part. The guys in your interview obviously didnt get any. I work with SQL Server and Delphi, and on our news groups we get questions from folks where it is obvious that they are working on a project for pay and havent a clue of how to use either Delphi or SQL Server, they just start with a sample program and go from there... trying to hit a moving target in a dark room. How did they get that job ???
I have a friend that works as a consultant at the worlds largest package delivery company (I wont give their name but their initials are 3 letters) and their senior dba writes sql code by using Access and the sql query designer to create multi table selects and joins and then cuts and pastes the output (totally un-optimized) and incorporates it into the company's main application code. I wonder how many more servers the company has to buy because of that .. and I'll bet he makes 150K or better with stock options.
- This is something I observed as well when I was interview people for DBA position a couple of years ago. What's scary is that some those people had MSDBA certification. How did they meange to get that?
What is scarier then those "DBA" people are people who actually hire them!!!
-
"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....
this is definitely spot on as far as I go - I usually walk in to an interview quivering like a blancmange but am extremely forthright about what it is that I do know and what it is that I have no clue about...this then must be the explanation for why I've always had a job offer with my very first interview (thank goodness 'cos there's no way I can withstand the terror that the prospect of each one strikes in me)...
Also - been on the interviewing side and the ones I've picked have always been winners - anyone with a brash cocky know-it-all attitude is one that seldom knows anything and the ones that just sound quietly confident and are never afraid of admitting ignorance is the one that walks home with the trophy...
A DBA could easily go 10 years without ever having to work with Replication, or clustered servers, or a number of other items. .....
How true is that - I'm more of a developer like Remi but have sort of fallen into a dba role because there's no one else to assume it - have never had to deal with replication, clustered servers (amongst many more things) - but then I do try to keep my knowledge base current and part of the reason why I like (read: addicted to) SSC is because of the range of forums and within those - the range of varied dba responsibilities and the accompanying variations of problems/resolutions they bring to the table.
I believe some of these folks have worked for me over the years ..
I think what's infinitely worse is that some of these folks are on the loose as instructors and professors and I've come across quite a few of them....
Lastly - for my interviews I had a printout of 2 tables and some questions to test knowledge of very basic selects, inserts and updates - I hesitantly handed it out towards the end of my first interview apologising to the DBA/Developer with 8 years about insulting his intelligence thusly....the question was - how do you get the highest sales amount and salesman name from salesInformation table and salesmanName table ...I had some sample data in each of the tables just for reference...so the query I get back is:
select SalesAmount, SalesmanName from SalesInformation where SalesAmount = 2507.80 and SalesmanName = 'Romano'
After the first time, though I continued apologising before handing these questions out - I continued getting (much to my growing dismay) appallingly clueless answers...this article just confirmed for me the fact that I've always been going on about the horrors of having ignorant people manage really important and critical databases and it appears that this is more pervasive than I thought....
**ASCII stupid question, get a stupid ANSI !!!** -
I was once interviewing for a role and the candidate turned up 1 hour late. Her explanation was that the address of our office was "Lower Mortlake Road" so she found a train station called "Mortlake" on a map, decided it must be somewhere around there and she could ask someone where the office was when she got to the station. Said station was actually about 2.5 miles away.
I dread to think where she would have ended up had our address been "London Road".
Going back to the point about idiotic recruitment consultants...in this case he thought we were being unfair for turning the candidate down on the grounds that she didn't bother to find out where our office was prior to setting off! Surely the point that she was 1 hour late should have been enough.
-Jamie
Jamie Thomson
http://sqlblog.com/blogs/jamie_thomson -
I've got a good one. I had one guy actually argue with me about the existence of the virtual inserted & deleted tables. Needless to say he didn't get the job.
-
On a general more interviewing theme, remember the maxim 'The way you do one thing is the way you do everything'. This is why it is always so crucial to ask what are seen as the 'soft' questions - eg 'Tell me about a time things went badly wrong, and how you dealt with the situation'. People tend to repeat patterns when under stress. This is much more useful to you, the interviewer, than 'What would you do if x went wrong?' (which requires a textbook answer).
Someone asked what my nasty/impossible questions were...try just flicking through BOL at some section you don't recognise, or specifics on why truncating transaction logs doesn't always shrink as much as you'd expect, or even vague questions. If the question is vague, do they ask you for clarification (which is what you hope they would do on the job when you ask them to do something)?
Nobody has ever cried after one of my interviews , and I've managed to get some spot-on people
And turning up 10 mins early (to chill out), and prepared (doing a bit of homework on the prospective employer) is a minimum requirement, of course! -
There was a study done recently that found that incompetent people are quite often unaware of their incompetence -- they simply don't know what they don't know. In fact, perversely, they found that the higher one's level of competence, often, the less confident in their knowledge they became; and vice versa. Fortunately, there was a cure for the inflated sense of confidence incompetent people have, and that was to acquire more competence.
There is at least some degree to which competence is in the eye of the beholder. I am much less interested in hiring someone with specific SQL Server knowledge than in hiring someone with good all-around database knowledge. If someone understands the concepts of good database design, of general approaches to troubleshooting, of the importance of having a backup plan that supports the mission, etc., and seems like a good person to work with, I figure the SQL Server-specific stuff can be picked up. I'm not going to throw out someone just because he achieved his experience in Oracle or Informix. But that's my opinion.
-
Anything 'virtual' is something that appears to be there but really isn't.
Oh, by the way, my spelling is not great but my pronunciations is usually on 'target' ...
It's pronounced "squeal" ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
Outstanding rant. In addition to providing some LOL entertainment, this is a great source of interview weed-out questions.
Well done!
-
Have been on both sides. Interviewed at MS for a SQL Support position (way way back). Walked in with the attitude that "these people know a LOT more than you do, don't bluff, be honest".
Of the 15 people interviewed, one other person and myself got the jobs. All where competent people, some much more experienced than myself. The two of us where the only ones to say straight out that we did not know the answer to some of the questions, but, give us a copy of the SQL manual (back in the day when those still came printed) and we would find the answer. The rest had tried to fib.
The best one was when I was sent by my consulting company to intreview for a position doing replication. I had ZERO replication experience at the time. My opening statement was "I don't know anything but the theory of replication. Do we want to continue this interview?" Got the job on that one.
Have had some bad answers giving the interviews, but not that bad. Very few candidates I have declined has been for lack of specific knowledge, although some were underqualified in general.
-
You know, I come from a VFP background and have been using SQL exclusively for only a couple of years. I would certainly not consider myself a DBA. This actually makes me feel better about myself! The only one I couldn't nail and show a thorough understanding of was about restoring a single table. I didn't know you could (can you?) and have never come up against the need, so I don't feel too bad about not knowing that one. On the other hand, I have no qualms about saying, "I don't know" when I don't. Oddly enough, I DO sometimes have trouble finding work and wonder if I've lost out to guys like these!?!? Anyway, I'm off to the BOL to find out about restoring a single table...
Mike Yeager
Taos, NM
-
Q: What is checkpointing?
A: Checkpointing is the point at which the system checks to see if the transaction log needs to be truncated.
This answer is not completely wrong, because "Automatic checkpoints truncate the unused portion of the transaction log if the database is using the simple recovery model." However, the simple recovery model is not the default model (and it's not recommended for production databases), so a more appropriate answer would be "Checkpoints flush dirty data and log pages from the buffer cache of the current database, minimizing the number of modifications that have to be rolled forward during a recovery."
Razvan
Viewing 15 posts - 31 through 45 (of 77 total)
You must be logged in to reply to this topic. Login to reply