Over my career I’ve seen interviews fall into three categories:
- The technical part. Questions on trace flags, wait states, backups, etc, often on things bordering on trivia. They want someone that can do the job on day one without looking up how to do a backup or whatever.
- It’s far less about direct technical stuff and is more about thinking – think architectural type scenarios. We’ve got problem x (which is a lot bigger than a slow query), what are some ideas on how we might handle that with/without tearing up a lot of other stuff type questions.
- It’s about the soft skills. How will you work with colleagues on the same team, on other teams? How do you handle conflict? Do current common scenarios in their environment stress you? Can you work self directed?
Some interviews are all of one kind, some are a mix of all three. Soft skills range from a tie-breaker to a deal maker depending on what they need. For technical jobs technical skills always matter, but employers are almost always going to opt for someone that seems like a good fit overall, even if they scored just a bit lower on the technical side.
It’s easy to blow this without realizing it. Imagine the interview explains that all their current applications use the SA account. What do you say? Do you take time to discover whether there might be a reason, or a path to a fix, or do you explode a bit with geek superiority and tell them they are doing it all wrong? That’s a more extreme example than most, but one of the things I look for is flexibility. Are they willing to do things differently than they’ve done in the past? Willing to use VM’s, or schemas, or work with teams that use ORM layers?
It’s more than dressing well and speaking calmly. Not surprisingly most consultants do better at this than potential employees for a few reasons; they are used to listening, they do these interviews a lot, and they know how far they are willing to bend on their technical beliefs. Listen hard and think, it’s worth doing.
