Showing posts with label Interview. Show all posts
Showing posts with label Interview. Show all posts
Wednesday, January 27, 2010

Experts are Sharp

You know I was thinking just this morning about the last round of interviewing I did to find a new DBA at work.  And that of course got me thinking about some of the interviews I’ve done in the past.  There are a few that really stick out.  The ones that are sticking out right away are the ones who didn’t know anything and claimed that they had so much experience and were so good that they didn’t have to be bothered with memorizing every little thing anymore.

This astounds me because all the experts I know are really sharp and on top of their game.  So what these guys are telling me is that they’re so good they don’t have to demonstrate even the most basic knowledge of SQL because they’ve transcended above that?  If that’s the case then my mother’s 100x the DBA any of us will ever be because she doesn’t know the first thing about it.

I remember this one guy especially.  He claimed both on his resume and in person to be an expert in query tuning.  He said, I’ve never found anyone who’s my equal at tuning queries.  So armed with that bit of knowledge I set about quizzing him with the basics.  I mean after all, you have to just get the basics out of the way, right?  I asked him if he had ever worked with exec plans.  He said of course, you don’t tune queries without them.  I said, that’s what I think, but i just wanted to make sure we were on the same page.  And I then asked him how expert his knowledge was of exec plans.  He said he was a very deep expert and didn’t know anyone with his knowledge.  Wow, now I’m getting a little nervous, right?

So I started with the basics.  What’s the difference between an index scan and an index seek?  Well, I’m not sure the exact difference, but I know you want to get rid of one of them.  OK, which one?  I can’t remember.  Um, ok.

So what’s a bookmark lookup (this was back when SQL2K was stull ubiquitous)?  I’ve seen it before, but I’m not sure what it does.

We went back and forth like that a couple more times and I finally broke down and told him that there was no evidence that he had ever tuned a query because he didn’t even have basic knowledge of exec plans.  I asked him what he was basing his claim of being an expert on.  That’s when he let me have it.  Look, I’m an enterprise DBA and I don’t have to know every piddling definition you dig up out of BOL.  Maybe someday when you’re at the level I am you’ll understand.

Um… ok, I’d say we’re done, huh? 

So like I said, I was thinking about that this morning and while I can’t keep up with everything, and nobody can, I like to think that I’ve got a lot of the basics covered.  And the real experts certainly know their stuff.  Go ahead and see how many people would follow her if you asked Kalen how big a SQL page is and she couldn’t answer.  And how many people do you think would follow Paul Tripp if he couldn’t tell you what DBCC CheckDB() was for? 

It just doesn’t hold water.  So for those of you out there thinking you’re all the Pooh, go test yourself and see how much knowledge you really have.  You may find out you’re not as hot as you thought.

Sunday, November 01, 2009

1st Night at PASS

Ok we arrived in Seattle for PASS only I found out tonight that I’m not supposed to call it PASS.  Apparently the PC name for PASS is the PASS Summit.  Oh well…

So we started at the Tap House wtih Allen White and his wife and then went to the convention center (I can still call it that, right?) to register.  There we met up with tons of other MVPs and a few people that Jen follows on twitter.  Would that be her fellow twits?

I was talking to Allen about how things appear to be getting better because there are a lot more MVPs here than there have been the past couple yrs.  I think this is going to be a good week.

We also did our first DBAs@Midnight with Allen.  It was really fun.  We got to talk about Oracle and making mistakes, and powershell, etc.  It was a fun talk.  I’ll upload it soon so check back and I’ll let you know when it’s up.

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Tuesday, July 28, 2009

Landing that job

You’ve been on a couple interviews and you’re finally getting offers coming in.  But a mistake that gets made quite often is that someone takes the first gig that makes them an offer because they can’t afford to turn it down.  That’s an evil in our society that we have to be forced to something we don’t want just to make a living.  If more companies considered retention in their plans we would be more stable as a workforce and you wouldn’t be forced to make decisions you don’t want to make.  Of course, if companies gave even a single thought to retention a lot of us wouldn’t find ourselves out of a job to begin with.

But leaving that behind, let me just advise you against taking the first job you come across.  If you have a family to support I certainly understand it and you’ve gotta do what you’ve gotta do.  But if you’ve got more than one offer coming in, there’s no reason why the other guys can’t wait a day or 2 for your answer.  Most companies take forever to get you through the process and then expect you to make your decision on the spot.  Try not to fall into that trap if you can help it.  It’s not going to kill them if you take an extra day or 2 to consider all your offers.  Some recruiters like to put pressure on you by getting offended at your audacity for considering a different offer, but that’s just childish and don’t fall for it.  Their only concern is their own paycheck and it has nothing to do with you.  You gotta do what you gotta do.  Take the gig you want not the one the losing recruiter wants you to take. 

Recruiters will play games with you to get you to take gigs too.  I recently witnessed a recruiter telling someone they had to accept the company’s offer right now or it would be rescinded.  Whatever dude.  So if something like that happens to you you have 3 choices.  You can capitulate in which case you get what’s coming to you.  You can also tell them up front that if the deal’s only good right this second that you pass.  That usually changes their tune and fast.  Or you can accept the offer and then entertain other opportunities as they come up.  That may leave you accepting the offer and then rescinding it a few days later, but that’s the cost of doing business.  And if they ask what happened and why you’re backing out, just tell them that you don’t like being blackmailed so you took it to appease them but did your own thing.  Then if at all possible, make sure the company finds out how the recruiters who are representing them are doing business.  You’ll probably find that they knew nothing about the threat and would be pretty upset to hear about it.  I’ve personally ratted out a couple recruiters for similar behavior.  Seriously, don’t let them bully you.

I don’t really like the idea of having to accept a gig and then turn it down a couple days later, but if the recruiter is going to be a child about it then you have to play the game.  My job is to get the best deal for me and my family.  So I’m going to make sure that happens.

So unless you’re about to lose your house, don’t marry the first guy who holds your hand.  There may be better out there.  Personally I don’t like shortterm gigs if I can help it.  I like to get somewhere and stay there.  So when I accept a gig it’s because I think it’s something I want to do for more than 3yrs.  That’s the goal anyway.

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground – http://www.infoworld.com/blogs/sean-mccown

Follow my Twitter:

http://twitter.com/MidnightDBA

Monday, January 26, 2009

The courage to say the impossible

I was interviewing a guy the other day for a DBA position I have open and I like to ask questions that help me determine how much someone's actually worked with SQL. And one of the ways I'll do that is to ask them how to perform an impossible task and see how they deal with it. In this case, I asked how he would restore a single table from a backup.

He thought about it and went through different scenarios, all of which I kept narrowing down until he was forced to deal just with the backup file itself with no other parameters. He kept trying to think of the flag that he would use to just pull a single table out of that file and he just couldn't think of it. He finally said that he didn't know of a way to do it, but he was willing to learn.

He failed that question in a couple of ways. First and foremost, he had to thing too long and hard about something he should've known for as long as he's been a DBA. So there's that. 2nd, he failed because he didn't have the courage to tell me that it wasn't possible and that as a user, I'm screwed. The data can't be recovered that way. Now, this is a very valid question and tells me a lot about a DBA because we're quite often called on to deliver bad news and if you're not able to do that, then you may not be as strong as you thought.

What he needs is the courage to stand up and tell me that what I'm asking for isn't possible, but he was too caught up in the fact that he's in an interivew and I wouldn't be asking a question like that if I didn't know of a way to do it. I actually explained all this to him and he agreed and said that he thought it was a trick question, but didn't want to say anything.

I've been in that position before where I was thrown by a T-SQL question like that. And initially I reacted the same way because there are so many pitfalls and neat little tricks in the sql lang that I could easily have missed something really big. Or there could have been some obscure legacy trick that still worked. So I get where he's coming from. I really do. However, backup syntax isn't like that at all. It all fits on one page so it's a lot easier to lookup.

And not to go off on too big of a tangent, sales guys are the same way. They hate to say no to a client. They feel it's the worst thing they could do, but it's not. The worst thing they can do is to make promises they can't keep. I saw this at a gig I had about 4yrs ago a lot. The sales guys were always making promises and then expecting the devs to deliver on time. It's messy, and it promotes nothing but crap code. So while they always made their deadline the software was so buggy and so poor with concurrency, it spent more time down than anything. So while they met the letter of the contract, they've greatly harmed their reputation and pissed off the client because now they've gotta take a couple more weeks to fix issues. And that could really harm the client's data as well. Because you could have to make changes to the underlying schema and now you're in the middle of a conversion right after you go live. So I realize you don't want to have to tell a customer no, it's best to tell him the truth. As much as I'd like to get this entire app architected and fully written by this time next month, that's just not realistic. Why don't I get back to you on when we could have a complete product ready, or we can work out a release schedule and we can get you the most critical functions right away and then bring others online as they become available?

So while nobody wants to say no, or that's not possible, or your data's gone for good, it's necessary sometimes and your customers (whoever they are) will appreciate your honesty. And they'll appreciate that what you give them will actually work when it's released.

And by all means, if you're interviewing and you're put in an impossible situation, don't be afraid to say it's an impossible situation. Acknowledge to the interviewer that you realize your choices are limited and that your actions will be factored by that limitation. Then present them with the possible solutions and leave it at that. In this exact case I gave above, the answer would have been something like this:

Well, you can't restore a single table from a native sql backup. If you had some kind of 3rd party product like LiteSpeed or Red-Gate or Hyperbac I could do something for you. But as it stands, you have to restore the entire DB. If you were lucky enough to at least have filegroup backups We might even be able to get away with a partial restore if the table's in the right filegroup. But the situation as you've outlined is pretty bleak.

That answer tells me a couple things. It tells me that you know right away that the task is impossible. So you've worked with sql backup before. It also tells me that you know the situations where what I'm asking would become possible and you've done it enough to know those other solutions immediately. And it shows me that you're willing to be honest with me about my situation. That kind of answer will win a lot of points because if I actually had this problem, you would be the one I wanted to clean up my backups going forward because you've clearly been there before and are quite capable of putting me in a better position. And as an interviewer I may or may not realize that's what's going on, but I'm digging you pretty well right now.

And don't be afraid to tease a little. I had an interview once where they were having problems with SQL memory. They wanted to access more than 4GB, and had the RAM installed, but couldn't get SQL Server to recognize it. I gave him some guidance on how he would see that memory used in SQL and he said that it was perfect for his scenario. Then he asked what they did wrong and how to fix it. I said, well sounds like you need a DBA and if you bring me aboard I'll be happy to help you with that.

So there ya go. There's a little how and why on answering interview questions. There are ways to answer questions that tell them you have experience and ways to answer that don't tell them much about you at all.

Good luck.
Wednesday, March 19, 2008

SQL Server Done Right

This is the perfect topic to go along with what I wrote on my other blog today in The real difference between SQL Server and Oracle.

I just got an email from the producer of the new Kalen Delaney series on SQL Server giving me my press pass into the online content for this series. I've only watched the 1st 9mins so far and already it's exactly what I'm talking about in my other blog. Here's Kalen Delaney who writes one of the most successful series on SQL Server (the other one is by the late Ken Henderson. I still have a hard time saying that), and she's going the extra mile to put her book into a video training series where she explains the concepts herself.
I, like many other people learn better when things are explained to me than I do from a lifeless page. And Kalen's an experienced teacher so she has a way of explaining things that make you just get it. Already in this video she's already covered security of metadata and the sys schema. She's actually explaining how this stuff fits together from the ground up. That's how it's done. I have no doubt that the rest of the series will contain the same deep-level understanding.

I think I'm going to enjoy this series and I'll try to write-up a full report when I'm done. Or maybe I'll just do it as I go along.

OK, so here's the link to the site. You can order the DVD or you can watch it online. It's good stuff. Seriously, go check it out if you haven't.
I was recently chatting with Kalen in email and she told me that this is basically the course she teaches when she's brought into a company to teach a class.

Actually, I didn't mean this to be an official interview, but I'm going to go ahead and paste her email here. I'm sure she won't mind (at least I hope not) and she explains it better than I would anyway. I typically don't post emails without asking first, but she knows who I am and she answered my questions like she was being interviewed, so this one time I'm going to do it. But you'll almost never see me take this liberty.

1. What material will this first DVD cover…

You can get information about my course here: http://www.insidesqlserver.com/Course%20Description%20and%20Outline.htm
The first DVD covers most of what is in Module 1.

2. What format will it take… will be be a group of slides and whitepapers, or screencast instruction by you…

The DVD will be a mixture of live capture of me talking, and screen captures of my slides and my demos.


3. Who all is involved in the project…

I am recording the class that I have been presenting all over the world for the last several years. Chuck Boyce, of AskaSQLGuru.com is doing the filming and editing. The business side is being managed by Peter Ward of www.WardyIT.com in Brisbane, Australia


4. How often can we expect to see a new DVD come out…

Since I have to fly to New York for filming, we are only able to do about one a month. In fact, I am just about to leave for the airport for the second round of filming.


5. What advantage will one have in ordering these over just getting the books…

Different people learn in different ways. If you like to hear and see someone explaining concepts, this can add to the benefit of the books. People pay a lot of money to attend my classes, but since I’m only one person, I can’t offer them that often. The DVDs are a chance to for anyone, anywhere to get to take my class. If you can read and absorb everything in the books on your own, the DVDs might not offer anything more.

So again, here's the link to SQLServerDVD.com.

About Me

My Photo
Sean McCown
I am a Contributing Editor for InfoWorld Magazine, and a frequent contributor to SQLServerCentral.com as well as SSWUG.org. I live with my wife and 3 kids, and have practiced and taught Kenpo for 22yrs now.
View my complete profile

Labels

Blogumulus by Roy Tanck and Amanda Fazani

Page Views