I got burned today at a SQL Server Interview!

  • Do your basics right, and try to follow a standard the first time itself. That is going to help you a long way when writing any code, whether it is T-SQL or C Code, it does not matter. You have the basics right and you have also commented it properly, when you have to look at it again to optimize it or to check for bug that had come up, it will be easier.

    But what I have seen from developers over the years is their mentality when writing code for T-SQL. What I have seen is, If it compiles, then the Stored Proc is good to be released to production. I wish they would put the same effort of cleaning up their SQL Code as they do it for C Code.

    -Roy

  • CRUD... for some reason, this thread will no longer allow me to add a reply... in fact, it keeps overwritting THIS message when I try and the previous message has been lost! This is what I was trying to add as a reply after Gail and Grant immediately below...

    Not what I really meant folks... I'm not talking about the actual writing of the code, for the most part. There's always a bit of trial and error in writing code and I agree... if you can write code head on without ever having to make a correction while your writing it and it works first time every time with good performance and scalability, then you're an SQL GOD and you're not being paid enough no matter how much you make. No, I'm talking about the management process of how the function requirements for the code are designed and the knee-jerk reactions they make for the Developers at the code level in the heat of battle to get a job done. Sometimes that poor management process trickles all the way down to the Developer's attitude. When that happens, you get frequent errors and rewrites in production. Don't even get me started on shrink wrapped and 3rd party management decisions

    And that's what I meant... why does management think they're doing a good job to rush a project only to have to turn around and fix all the crap that's not right in several revisions because people took shortcuts or missed requirements because they were in an awful hurry to meet some poorly planned deadline. Shoot, they even rush the deadlines on the "fixes" and end up "fixing" the same code 3 or 4 times or, worse yet, breaking something else

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (3/6/2008)


    Why is there always enough time to do it again but never enough time to do it right the first time? πŸ˜›

    TSQL or your cooking? πŸ˜€

    No matter how right you think your code is the first time you pen it, you always realise later that there's a 'best way' to do it. Thing is, the first iteration of your code is essential to finding the best way - you can't reach the destination of 'best way' without going through 'first way' *. Maybe it's because you're better equipped to focus your attention on the output or result when you have a 'first way'.

    * Except Lynn, Steve, Jeff, Dave, Peso, Gail, Jack, Grant.....

    β€œWrite the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

  • Jeff Moden (3/6/2008)


    CRUD... for some reason, this thread will no longer allow me to add a reply... in fact, it keeps overwritting THIS message when I try and the previous message has been lost! This is what I was trying to add as a reply after Gail and Grant immediately below...

    Hmm... I had just assumed you were trying to make the point about doing it right the first time....

  • I have almost never gone back into older code without seeing ways I can improve it. Mainly because I am on sites like this and trying to learn more every day. IF I ever stop doing that I think I'll just "retire" to flipping burgers at McDonald's.

  • Wow was that a lot to read. I haven't been active for a while, but it's been a while since we heard from the OP.

    I'll respond to a couple of things I read.

    Does Oracle have the issue of Sr. people who don't know basics. YES!

    I was an expert, but couldn't consider myself one now. I haven't used Oracle in about a year. And "I" feel that is too long. However, I interviewed many that felt they were and couldn't even tell me basics in Oracle (like what is dual used for). Since most of you won't know, it's a really stupid table in Oracle that is needed to get results when you are looking for things like "Select getdate()"

    Oracle would be "select sysdate from dual;"

    ... What's sad is that I really had to think about that being correct.

    Next thing. Lying in an interview. The job I have now is Sr. Level SQL Server DBA.

    2 years ago, I hadn't even seen SQL Server. 18 months ago, I had just transferred to a position that had to access Sybase. 12 months ago I started that job as a (Sr. Level SQL Server DBA).

    I think I have posted enough to be able to say I have a clue. I still don't know that I would consider myself an expert. I KNOW that I am compentant in a very limited set of SQL Server. However, I do know clustered/non-clustered. DeadLocks. Isolation Levels, backup modes. etc.

    But don't ask me about SSIS, Analysis, or reporting.

    So how did I get the job?

    I told the truth. When I was asked about Deadlocks. My response was:

    "With Oracle they occur when 2 sessions get in a tangled mess and neither can complete until the other completes; So this is detected by the Server, and one is randomly killed. I know that with SQL Server, this can occur for other reasons since Reads block (unlike Oracle). As for solving the problem, it is almost always a coding solution"

    There were several other questions. I answered... "No Idea" to several questions. However, after I got back I responded via email with the answers, links to web pages, and other supporting documentation to all the questions I could remember...

    I proved the most important thing in IT. I showed that I knew how to get the answer in an enviroment where the answer to any question may change for CU5-CU6.

    FYI. I was the only one of 5 people interviewed that had NO experience with SQL Server.

  • ODAA caught by the coworkers, still not noticed by the boss or any one else in management.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • we don't expect to get Jeff Moden in every interview (although, that'd be GREAT)

    No but I'll have one for each working day though :w00t:

    ... I'd like to work with you so I can improve my SQL skills.

    Join the queue with more than half of this community 😎

    Yes Jeff is very knowledgeable about SQL server and he yelled at me a lot too

    Hasn't with me.... yet!!

    But then I am a member of the sycophants appreciation society πŸ˜‰

    Folks, when you do an interview, remember... you're not trying to show off how smart YOU are, you're trying to figure out how smart the other person is for the job you want them for... and they're human...

    At an interview way.. way.. back in my past I was overqualified for the job of a Developer and was rather cocky and thought it was a walk in the park. Then I found out a work colleague was also interviewed and he got the job, I was not surprised as he had the gift of the gab, The upshot was (as I knew it would happen) the employers became unhappy as this person could not live up to the promises made. I learned on very important lesson, I'd rather be honest and not get the job than lie to get it.

    My point is this, if you have the drive, take the time to learn, not memorize, what you are interested in.

    Absolutely agree with this, I taught myself databases on mainframes then SQL Server before I went on training courses. I did it because I wanted to learn and improve myself.

    I will admit, I'm a nasty interviewer. Some of my colleagues who've sat in on interviews tell me they don't ever want to be the candidate in an interview I'm giving...

    Yeah and if you ask if anyone wants to join you interviewing, the office goes quiet and they all look away or find an excuse to leave.

    Years back my old boss called me his Rottweiler and planted me in meetings for the desired affect :rolleyes:

    Glad I've mellowed in my old age

    But when I see the things that Jeff, Gail, Matt, Colin, Peter, Grant, and several others come up, I realize that I have a lot more to learn.

    And for me sooooooo.... much :blink:

    ...SSIS...

    Oh! Jeff you just had to mention it didn't you. We're not even on 2005 yet and dunno when either. I know a smidgen about DTS though.

    I even taught myself how to run plenum cable and make both Cat 3 and Cat 5 teminations (sic)...

    Heck that's nothing I use to used a punch card machine without having to look at the keys

    Sounds like I am definitely among the fortunate here!! I haven't had to deal with a technical interview in over 10 years since

    Twice that for me πŸ™‚

    Me, I just stare at the code and intimidate it into performing better!

    Damn! Mine just stares back at me and I feel intimidated :angry:

    Wow! that's a thread and a half

    Far away is close at hand in the images of elsewhere.
    Anon.

  • I just spotted this post. I've not had time to read all the replies so I may well be repeating what someone has already posted.

    You're original post asking about indexes will come up again during an interview so it's worth asking about those here. You know the answers now, so you are now ready for the next interview...Or are you? The answer, I am afraid is no...not completely!

    Each interview is different. Each organisation is different. The interviewer will usually have the generic SQL Server questions to ask you to make sure you understand the basics. Then, from experience, they tend to ask questions relating to their environment.

    So my advice is read up. You mentioned you're new to SQL Server. Cool...Welcome to the club! But you need to buy some manuals, read up on postings here and other sites, read up on technical papers, books on line etc. What I am trying to get at is you need to broaden your knowledge on the different areas of SQL Server.

    I'm not saying you need to know everything - nobody does, but having a good fundamental understanding of the basics will get you further in an interview and hopefully a job offer.

    That said, the fact that you told the interviewer you did not know the answer is a good step. It's wiser to say you're not sure than trying to make something up as you only end up with egg on your face and I've had a few candidates do just that...You just watch the squirm as they dig the hole deeper and deeper...

    Anyways, good luck with the job hunt and get all your questions down in these forums...I still learn a lot every day from these forums and I've been a DBA for 8 years πŸ™‚

  • Chris Morris (3/6/2008)


    you can't reach the destination of 'best way' without going through 'first way' *.

    * Except Lynn, Steve, Jeff, Dave, Peso, Gail.....

    Hell, no. The amount of times I go back to a query I wrote weeks/months/years back and fnd a better way. Or see the amount of times Jeff corrects something I post here. πŸ˜‰

    What Jeff might have been getting at is the 'practice' of diving into code without thinking about things first. Often that will require several rerites to get correct, whereas 15 min thought first may avoid the need for any rewrites.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • I'm impressed if you can write the TSQL so that it fully performs and returns all the correct data out of the gate. It usually takes me a pass or three if the query is at all complicated.

    However, the low-hanging fruit is all plucked; schema ownership, qualified columns, proper formatting, good join syntax, good syntax period, correct data types, set based operations, on & on. Do all the simple, easy, direct stuff correctly and then you only have to worry about the hard stuff. That's where I can get behind the "do it right the first time" paradigm.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Mark said:

    Dear Ms. Gila Monster,

    NO, I am not being honest about my lack of knowledge of SQL Server! Think about it!! If my resume is junior level, nobody will even call me to an interview! You know how HR departments and recruiters work!? You have to be mid-level to senior to get hired! Grant Fritchey just confirmed it in his post above and I can see it myself from talking to recruiters. So if I present myself as entry-level I will not even GET an interview!!!

    I've been reading this thread to this point and I just have to poke my nose in...

    Actually, Mark, your assumption is NOT TRUE. I spent a year & 1/2 learning SQL Server and earning my certs while I was working in retail / customer service. I had no experience of SQL outside of a lab environment.

    Granted, there were a lot of positions looking for senior SQL Server people, but I finally managed to land myself a help desk position which required knowledge of MS Access & SQL Server. This job was my entry level job. Once I got a year of that under my feet, I was able to move to a few contract DBA positions which furthered my learning curve and finally landed (about 9 months later) my mid-level DBA position.

    When I interviewed for each of these jobs, I was completely honest about my skill set. I knew I'd be caught out if I wasn't, so when they asked me if I could do DTS, my response was "I know how to use the import / export wizard and I know where the designer is, but I've never used the designer for anything. I am, however, willing to learn it."

    My interview for my current job was 15 minutes. That's it. I was sure I had lost the job because I didn't know the answers to about half their questions. But, on the other hand, I didn't misrepresent myself either. I knew the answers to the other half and surprised them with stuff I knew that wasn't required for the job position (SSRS for one). Desperately, I called my contact at the contract firm and told them the interview was over and I was sure I had blown it. My contact promised to call them and get back to me. Twenty minutes later, I found out I had the job.

    Don't tell me honesty is a lost cause. These people were willing to train me on the things I didn't know because apparently my interview had proved to them I was willing to learn things I didn't know. I'm guessing at this last part, but given that I couldn't answer half their questions, and knowing (today) how rigourously they screen their canidates before they even get the interview, I surely did SOMETHING to impress them.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • Lynn Pettis said:

    I just wish the computer would do want I want, not what I tell it to do. It would be sooo much easier.

    Amen to that!

    I need to build a program that not only builds other programs, but builds the requirements too. Then all I have to do is data scrubbing while my little program does all my "real" DBA work. @=)

    BTW, my boss wants this program too.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • Brandie Tarvin (3/7/2008)


    Lynn Pettis said:

    I just wish the computer would do want I want, not what I tell it to do. It would be sooo much easier.

    Amen to that!

    I need to build a program that not only builds other programs, but builds the requirements too. Then all I have to do is data scrubbing while my little program does all my "real" DBA work. @=)

    BTW, my boss wants this program too.

    Actually - that's easy....Just write (or have the program write) the requirements AFTER the program....:w00t:

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Brandie Tarvin (3/7/2008)


    Lynn Pettis said:

    I just wish the computer would do want I want, not what I tell it to do. It would be sooo much easier.

    Amen to that!

    I need to build a program that not only builds other programs, but builds the requirements too. Then all I have to do is data scrubbing while my little program does all my "real" DBA work. @=)

    BTW, my boss wants this program too.

    The other way round, surely! :hehe:

    β€œWrite the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

Viewing 15 posts - 106 through 120 (of 357 total)

You must be logged in to reply to this topic. Login to reply