Technical Interview - I feel dumb now.... :)

  • Hello, I wanted to post this out to the community to guage my level of "dumbness". Let me start by saying I currently have a DBA position as a contractor to the Army and I make very good money. I have been doing SQL Server Development/Aministration for over 10 years and I have a masters and a bachelors.

    So, I got a call from a recruiter who is hiring for a company in Nashville and they pay relocation (I'm comfortable where I'm at but would love to move out of DC Area). So, I said sure what the heck. Its an internal company position, no contracting, very creative place and they are always upgrading to the latest and greatest. They are a real "development" shop.

    I'm also apparently at the tippy top of their pay scale (actually 5k over their max) and they make anyone with over 100k salary take some sort of super hard critical thinking test... umm ok.

    So, I had a technical phone interview. I consider myself very knowledgable about SQL and like I said I've been doing it for over 10 years. I did study the frequently asked technical interview questions and such so I tried to brush up on my textbook definitions of things... overall I think I did well but a few of the questions I was kinda like "duhhhhh" on.

    First question he asked me was about schema binding. He asked me what it was and if I use it. I started talking about not referencing schema names in queries and trying to keep everything in the dbo schema and he was like "while that is great info on how to use schemas, that's not what I was referring to". And I was like oh sorry then no I don't use that. I have since looked it up and I'm like wow how did I not know what that is.

    The other thing he asked me was how do you code to avoid page splits. I've never actually sat down and said ok I'm gonna code this to avoid a page split... so I admitted that I had never done that and then we kinda talked through it and I was able to explain what a page split is. I am not really deeply versed in the underlying architecture of SQL but I believe I have a good grasp of the concepts and stuff.

    I think a lot of this stuff I probably just do commonly and not really know the textbook answer to what it is that I'm doing. He also asked me a lot about indexes, deadlocks, locking hints, how I would handle a server that had a 100% maxed cpu, partitioning, how I handle large tables, b-tree and a few other situational things. The rest of the questions I believe I answered really well but I'm left feeling awkward.

    I've never actually worked in a real development shop surrounded by other developers that are strictly following best practices and using advanced SQL stuff. I know of these things and of course have studied them or participated in conversations about it. But I've never actually used it. Hell, the system I'm working on now doesn't even have referential integrity on their tables! I'm also usually the only DBA on the team or with one other person that just kinda fell into SQL.

    Should I be concerned that I don't fully comprehend how a b-tree structure works in the database or that I had to look up the ACID principles? To me the ACID principles are more like a "duh" type of thing where of course things should adhere to those principles but I don't actually sit down and code and say ok, I'm going to make sure my transaction follows every ACID property.

    In the grand scheme of things if they think I'm not worth the money I'm asking for I guess I don't really care... I'm not really looking for a job anyways but you know it just sits in the back of your mind. I really hate interviews that just sit there and ask you test questions. One it makes me super nervous and it just feels so fake I would much rather just have a conversation where we talk about scenarios or situations and explain, in a totally technical manner, how you would solve something or things that you have worked on.

  • I think we all have to swallow our pride and admit we don't and can't know everything - it is humbling when you can't answer an interview question - but everything really is just 'a google away.' If you take every moment of ignorance as an opportunity to do a quick google to at least understand the basic premise, you'll be constantly adding to your knowledge arsenal.

    With that being said, I do believe it's necessary (if only for the sake of looking smart and confident in interviews and to your peers) to memorize certain items - the ACID acronym and concept, for example. Even if you only have a surface understanding of a concept, you look much smarter if you can rattle off that basic concept with alacrity.

    With THAT being said, you also have to have a thick skin, and be confident in your intelligence and abilities. Don't let anyone make you feel dumb just because you can't rattle off certain buzzwords. Confidence is much more important than performance in most cases, I think.

    _________________________________
    seth delconte
    http://sqlkeys.com

  • seth delconte (3/29/2012)


    I think we all have to swallow our pride and admit we don't and can't know everything - it is humbling when you can't answer an interview question - but everything really is just 'a google away.' If you take every moment of ignorance as an opportunity to do a quick google to at least understand the basic premise, you'll be constantly adding to your knowledge arsenal.

    With that being said, I do believe it's necessary (if only for the sake of looking smart and confident in interviews and to your peers) to memorize certain items - the ACID acronym and concept, for example. Even if you only have a surface understanding of a concept, you look much smarter if you can rattle off that basic concept with alacrity.

    With THAT being said, you also have to have a thick skin, and be confident in your intelligence and abilities. Don't let anyone make you feel dumb just because you can't rattle off certain buzzwords. Confidence is much more important than performance in most cases, I think.

    Yea definately, I totally agree. I KNOW I don't know everything. I didn't mean to say that I don't know what ACID means or stands for but I just meant that in my day to day work I am not specifically thinking of gee is what I'm doing adhering fully to ACID?

    Yea I think I'm good about faking the thick skin thing outwardly but inside it still bugs me. I think the only reason I'm annoyed by this is because the recruiter puffed me up so much and made this huge big deal about how I'd be the most senior person on their team and because I want so much money they are going to expect me to be some mega guru. So, they like built me up and I felt like I really had to impress this guy so he doesn't walk away thinking "what the hell she's not what they said".

    I did make sure I told him though that I'm incredibly resourceful and if I don't know how to do something I will figure it out or look it up. I may not know syntax for everything but I know what I'm looking for. I didn't mean for this to be a "poor me" thread or I'm deflated by it...but just looking for feedback... if I should be able to rattle off these deeply technical questions then I suppose I should be brushing up more! πŸ˜€

  • There are times that I think I know a good bit about SQL Server and then I go to work somewhere that they use it in a different fashion than what I have in the past, whether different aspects of it or in a larger scale. At those times I quickly realize just how much I don't know. So, I find it best to take the role of a perpetual learner and whenever possible share what I have learned.

    All that being said, interviews are tough. The interviewer has that experience of their environment and needs, and they can pick what they want to ask. The best thing that we can do is admit when we don't know something but be clear that we can research that immediately following, and if possible let them know what you found. It goes a long way. I know, I've used that before. πŸ™‚

    Enjoy. Humility is tasty.

    David

    @SQLTentmaker

    β€œHe is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • Hehe ya, if I'm coming off as arrogant or something that wasn't my intention. I never expected to be a know it all nor do I believe that I do. I was simply wondering if these nitty gritty technical details SHOULD be something I should know with the amount of experience I have.

    I think maybe I'm hindered because the places I have been working are not condusive of doing and learning a lot more of the advanced stuff I'd like.

  • No, you weren't coming off as arrogant. My apologies if my reply, specifically the statement about humility, seemed that I was implying such. πŸ™‚

    What you stated is really my point, we become "specific" in our knowledge of SQL Server based on where we work and how the technology is used. If indexed views aren't part of your normal development cycle then schemabinding wouldn't be something you were familiar with. There is a lot to this DBMS and there are few places that use it extensively. If you can find a place that does, it gets really exciting. Even then though, there is always more to learn.

    Thanks for sharing your experience.

    David

    @SQLTentmaker

    β€œHe is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • Gotchya!

    Thanks.

    I'll let ya'll know if they invite me down to Nashville for a face to face panel interview... *gulp*.

  • Haha, I was sent by a recruiting firm to a first interview that without my knowing was a tech interview. POP QUIZ! It was horribly embarassing especially since my position at the time was using Oracle and not SQL Server and it had been months since I'd been DBA'ing and coding for SQL Server. I think this happens to everyone at some point - the interview from hell. I learned never to trust a recruiter again and to make sure I'd brushed up on the academics prior to each interview and had some concrete examples of what I've done from performance troubleshooting, tricky report requests and upgrade/installation implementation. That way I could show off the stuff that I do know and reassure the interviewers that I had the tech chops.

    I know it's hard to determine this in a couple of interviews, but aren't critical thinking skills and being break down a problem to get to a solution more important than giving out a definition of schema binding? If I were you, if wouldn't beat myself up for not being able to do the latter if you can do the former.

    MWise

  • Interesting conversation.

    Here in my company I have a friend who told me that one of the most experienced DBAs (+10 years) failed the SQL Server 2008 certification on implementation & maintenance. I know it's a different matter because some of the questions focus on new feature or case scenarios that people are not used to but it's something interesting to think about.

    I lack too much experience and to me it's harder than lacking too much theory because theory you can learn by yourself. I try to learn the DBA way from what I can by myself but, in practice, it's really hard to emulate an environment like in real life.

    I admire you for being humble and accepting that you do not know everything.

    We're forever students, it doesn't matter how old we are. πŸ™‚

    Best regards,

    Andre Guerreiro Neto

    Database Analyst
    http://www.softplan.com.br
    MCITPx1/MCTSx2/MCSE/MCSA

  • Schema Binding is pretty specific, and not that common a concept. It's got it's uses, mainly in high-end performance-tuning, but I wouldn't consider that a pass/fail question on an interview.

    Coding to avoid page splits can be critical in very high transactionality environments with extreme uptime requirements, but isn't usually critical outside of that situation. Again, not usually a pass/fail on the interview all by itself.

    ACID is critical in most data designs, either as strict adherence or deliberately ignore it (NoSQL) for performance purposes. This one I'd consider more critical in terms of weighing a candidate for a DBA/database dev position. Not necessarily "get this right or don't call us and we won't be calling you", but definitely high-priority.

    Judging by the questions, I'd guess they're dealing with a large, highly transactional OLTP system with very strict uptime needs. (Page splits mainly matter because they cause index fragmentation, either clustered or unclustered, and rebuilding indexes can cause downtime if not managed perfectly.) If that's the case, they might actually need those things.

    Knowledge of b-tree structures is again mainly about extreme performance tuning.

    If you're looking to hire someone to administer such a system, and the candidate is asking for top-of-scale compensation, I probably would expect/require knowledge of those things. They might be willing to overlook those if you nailed other questions quite well (it sounds like you did), or if you indicated adequate understanding of the concepts to learn their specific needs quickly and easily.

    So, no, I wouldn't call it "dumb" to not know those things. They're somewhat essoteric, even in performance tuning specialties. But it might weigh against asking top-tier on compensation if they have specific needs on those things.

    Even the ACID thing wouldn't constitute "dumb". Probably more like, "SQL Server usually handles that for me, and I haven't had to manually account for it recently enough to have the data at my fingertips". Even if you skip the other bits, I'd still recommend brushing up on that one.

    Not saying it'll take it negative on the interview. No way for me to know that, of course. But it is something to take into account on it.

    On the flip-side of that, you can also run into a company that has highly overrated ideas of their needs, and completely incorrect assessments of what constitutes a good interview question. I've had interviews like that. One spent 15-20 minutes grilling me on firewalls and DMZs, even after I indicated I didn't know much of anything about that beyond being able to define both terms, and also indicated that I wasn't sure what that had to do with a DBA's usual duties (I'm accustomed to network/security admins handling that kind of thing, not DBAs).

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Thanks GSquared!

    The explainations are helpful. I knew the ACID stuff and I looked it up before hand to make sure I had each letter noted as to what it stood for. He didn't really ask me much about ACID but I was just using that as an example for things I do day to day.

    They do have an OLTP system. However the position is not for "administration". Its an 80% development position but for some reason they wanted to focus on DBA type questions just to see if their candidates were well rounded I think? The recruiter told me that they definately want strong developers but they are looking for someone that is really interested in the whole picture and who would be able to identify performance problems and raise issues.

    I think he really liked one answer I gave when he asked me how I would handle a server with a CPU that was running at 100%. I happened to have directly dealt with this at my last company and was able to really go in depth with how we troubleshooted it and resolved it. I also explained that I am a very hands on developer and I don't like to just write my little stored procedure and send it out into the universe... I wanna know how things are performing, if my jobs are running, index statistics and everything and I said that I'm used to a world where I script everything and nothing happens in the production server unless I have scripted it out that way. He said yes that is exactly how they operate as well. The developers script everything that gets released into production and they have another team that actually handles all of their production support stuff. And I went into some performance stuff on tables and queries ... explained how I physically partitioned a 650 gig table and all the fancy index trending I did with it and made it more efficient... I do much better when I can give real world examples of how I handle things than answering test questions.

    The recruiter also told me that this guy is really intense and they actually said to me "I don't mean to scare you, but this will be hard!". So, I think I wouldn't be so nervous and anxious about it if they hadn't pumped it up so much and got me really worried about it.

    Its not a huge deal and sure I'm not gonna lose sleep on it if I'm not a right fit for them... but I would really like to be in a cutting edge shop with lots of other developers that I can learn some of these things we're talking about. That and I really want to get the hell out of DC! πŸ˜€

    I have been through many technical interviews and even had to endure one that was in "microsoft style". The manager had previously worked at Microsoft and he said if the type of interview was good for Microsoft it was good for this company. I was literally grilled for 2 hours by like 8 people. But that was laid back and I was cool with it cause the recruiter didn't try to freak me out. I got that job but I turned it down. πŸ™‚

  • Makes sense.

    All the questions you listed would be dev/performance tuning. The performance tuning and monitoring part of it is usually a DB Admin task. But, as usual, most database jobs are hybrids of dev/admin/architect/analyst.

    Best of luck on the results of the interview and on getting the job. Regardless of knowledge (which sounds like you know enough), you definitely sound like you have the right attitude about the career, and that's much more important than knowing a few essoteric details. So don't feel "dumb" or whatever.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • amy26 (3/29/2012)


    but I would really like to be in a cutting edge shop with lots of other developers that I can learn some of these things we're talking about. That and I really want to get the hell out of DC! πŸ˜€

    πŸ™‚

    Should I be concerned that I don't fully comprehend how a b-tree structure works in the database or that I had to look up the ACID principles?

    The answer (IMHO) is "maybe". It depends on how bad you want to get out of DC. πŸ˜€

    The world of DBA jobs is fairly competative and, while I certainly agree that such "essoteric" knowledge isn't necessarily required to do a good job, such knowledge is frequently used as an interview "tie-breaker". It's not always fair and isn't necessarily a good measure of how good a job someone may do but that's the way things frequently pan out.

    You've been through several "grillings" and now know what to expect. It'll take you very little time to become an SME on those things that you feel a bit light on and easily outshine the competition.

    --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)

  • Just to chime in with what's been good advice and discussion so far.

    Over 100k IS top of field right now in a number of markets. It's basically max of market if you don't have a name.

    I personally have a different opinion though of dev duties, and understanding page splits and how the storage mechanism works is one of them. What usually happens is after the fact the DBAs need to get involved because in usage scenarios don't match up with original design, but the developers need to have a solid understanding so those are 'one-off' repairs, not general continuous maintenance for the DBAs.

    I wouldn't worry about it too much. As mentioned, noone can know everything. Let them know what you know, and worst case scenario just say "No, haven't been involved deeply enough in that yet, but I could research it." This is definately one of those fields that the more you learn the more you realize you need to learn.

    Speaking of, I have to go try to wrap my head around NUMA. Again. Argh. Everytime I think I've got it... I don't got it. πŸ™‚

    Don't feel bad, we've all got weak spots. Mine is on the administration side though, I'm primarily a developer.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • So, update.... I guess I overracted and I'm not as dumb as I think I did... the recruiter just called me and said that they LOVED me. And they would love to fly me down for an in person interview. The sad news, is she said the CIO came down and told them they had hired too many people this year and were putting a freeze on it. So, now the guy I interviewed with has to make a plee to the CIO and justify that my position is critical and they really need to allow the position I applied for to be filled. πŸ™

    So, great news ....and bad news. πŸ™ I really hope they pull through because its a great opportunity and would get me the heck out of DC. So, keep your fingers crossed for me. πŸ™‚

Viewing 15 posts - 1 through 15 (of 19 total)

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