• I've been on both sides of the interview desk also.

    When hiring, it's not just all technical, but if they're coming in for a technical job, they better be able to make a reasonable statement as to what the basics (and some of the finer points) mean, when under pressure.

    Being a DBA means that you end up having to explain to non technically literate people exactly what it is you're trying to achieve, and why they should refrain from calling you every 2 minutes when the servers are down.

    If the can't make a decent, and unambiguous answer in interview, why would I trust them in an emergency situation?

    That being said, the guy who seems to have a clue about the big picture, but is just a little rusty as to the implementation (knows design methodologies and good practice processes, just doesn't know the syntax for the particular DB/System), and puts their hand up saying "Until I get used to it, I'll be reading the manual a lot" gets treated seriously.

    I'm a firm believer in maintaining a small library of books. I may not know what I want to know to achieve something all the time, but give me a little time, and I will do.

    The final swing to it is indeed personal. Someone may be highly skilled, and technically superb.

    But if I don't think I can comfortably work with them shoulder to shoulder when the world going awry, then they're far less likely to get the role.

    Ten to fifteen years ago, the tech world was a different place, and you could get by with being an eccentric locked away from sight performing arcane duties. These days, you need to be a businessman, advisor and hard core tech in one.