Looking for that next technology job? I’ll let you in on a little secret – six little secrets – Reasons I’ve said “no thanks” to SQL Server candidates when interviewing them for clients & employers:
1 – “I Don’t Know” isn’t a phrase you know…
I ask different kinds of questions. Some are questions you’ll find in books or internet searches – like, “how many clustered indexes can you have on a table?” Some are more “describe or explain” in nature with no absolute right or wrong answer – I want to see you can string some thoughts together and add common sense, logic, and knowledge. Some questions I don’t expect you to know! In fact, I learned from a great manager awhile ago to go out of my way to ask a question you won’t know the answer to. I’m looking for “I don’t know” as a response here. I’m fine with an “I’m not sure, but is it” type of answer. I don’t normally get those responses, though. Even a “simple question” – I would rather hear “I don’t know” to an easy question than some far-fetched stab in the dark that was confusing and off. (ex. “What are fixed server roles?” “well in those old versions of SQL Server, the roles didn’t do what people told them to do, so now they went and fixed them, so the roles are right”) If I recommend someone give you the keys to their prized production environment, I don’t want you to get all “what does this button do?” in it. “I don’t know” is not a bad answer*
*Quick disclaimer – it can’t be the only answer to all questions, though2 – You have no defense…
I’m not mean in an interview. I’m not dishonest in an interview. I do like a little disagreement from time to time, however. I want to hear you defend a position. I want to hear you stand up for your answer when it is a case of many ways to do the same thing. So I may disagree with you mildly. Or play the opposing view of one of those “religious” wars in SQL circles. I don’t approach it rudely, but I want to prod you further along. Defend yourself. When I am hiring someone to join a team I am on or a team I help – I’m not looking at it like I’m a dictator trying to fill cabinet positions. We are dealing with important environments and significant investments. If I decide to do something that burned you at your last employer, I want to know you’ll raise a flag and say, “Actually, the last time I saw this, here is what happened… Here is why I don’t think we should do this and have you considered this instead?” not “Okay! Go for it, Mike!” Even in positions with “junior” in the title, I want to see folks willing and comfortable raising objections… As I talk about in presentations on learning from real-life disasters, agreement despite concerns is a disaster-causing attitude… I don’t want that anywhere near database servers I care about.
3 – You don’t need to defend yourself…
Along those lines, I also really don’t want you if your only defense is, “I’ve been doing this a long time. That’s the right answer. How long have you been doing this?” Arrogance is also a disaster-causing attitude. Just because you personally detest anyone ever using an identity column as a primary key doesn’t mean you are right. Any exception to this rule proves the rule breaker is an idiot. So if I ask you to defend your position, remember it has to be a valid defense (Or at least heading towards validity.. I’ll even take “the glove didn’t fit” over “I said I’m not guilty, what more do you want?”) Tell me why identities are bad as primary keys. Answer my counterpoints when we have that discussion. Then tell me how you’d work with them anyway if that’s the scenario we paint. You may be an industry expert, but if you can’t get over yourself and outrage that someone would ask you to explain a little further, I’d be hard-pressed to suggest you join a team that ever has the potential of being staffed by more than one person.
4 – You do, know, and learn what is expected…
Only. Only what is expected. It is a competitive marketplace out there! So you need to stand out; you have to be different. I will always ask about what blogs you read (if you say my blog, by the way, I know you just googled my name before the interview), what SQL events you go to, what SQL books you’ve read lately, what you do to learn new features, etc. If you are coming to me for a SQL-related job, I will take points away if you can’t show me you actively work to improve your skillset. I don’t mean I expect you to spend every single waking hour living SQL Server – Family comes first, kids come first, weekends enjoying the backyard come first… There is still time to increase your knowledge and wear your more important hats. Stand out from the crowd by showing you care enough about what you do to know more than just the scope of your last role! If you feel you’ve already learned enough and don’t need to grow anymore, then you aren’t the right person.
5 – It’s not you, it’s me (okay, it’s you…)
This one may seem odd to write and maybe odder to read. We have to work together – especially if it is a team I am on or a team I help out with frequently. I don’t mean that we have to have the same political leanings, faith, hairstylist (in fact, my wife does my hair, she better not be doing yours too) or like the same bands. I want to see -you- not just a talking resume but a human being. I’m looking for that in the later stages of interview processes definitely but even to a degree at the beginning of screening calls. Basic things like eye contact, smiling from time to time, engaging in some idle conversation while walking someplace, you asking questions about the role, the company, or even the team, or talking about your life. We may have to work on some tough issues together from time to time; it helps to feel a team atmosphere. Again, I’m not looking for you to hug everyone and be fake or to bring cupcakes to your interview (I won’t refuse them, though..) I want to know we’ll get along. Be confident and outgoing; those little things add to the complete picture.
6 – You don’t have the right skills for the role…
Finally, yeah – you do have to have the right skills for the job. If you were great in every other aspect of a report developer role, but you didn’t know what SSRS was, it would be tough to give you that position. If you were a little off on some of the technical questions but showed me you had a passion for learning, could explain your thoughts, use logic and apply common sense to troubleshooting, I may consider you over someone with a bit more skill but less of these traits. In fact, I’ll do that a lot; I believe you can teach skills better than you can teach “traits,” but at the end of the day, the skills have to at least be someplace on the same map. Make sure you read about the position you are interviewing for and honestly assess yourself before committing. It shows when you just read a bunch of interview questions the second we go a level deeper.
I’m sure I missed a bunch; what do you look for when hiring for that next position? What are you most nervous about when looking for that next SQL job?
Great post Mike. Nothing bugs me more in interviews than people who refuse to admit they don’t know something, even to the point of making things up. It’s ok to say you don’t know, but I prefer it if they follow it up with “here’s how I would find that out..”, “this is who I would talk to..”, “this is where I would look online..”, etc.
Thanks David – That definitely bugs me the also. I think that’s the one that gets me the most also.
You didn’t mention “You’re a Yankees fan.” Or does that get included with #5? 😉
When I’ve done tech interviews, the first one that hits most candidates is #6. They come in with solid skill sets, but they are the wrong ones. For instance, one candidate came in with a good skill set if you’re looking for someone to be an imaging/document management system IT Pro. DBA? Not so much.
The position, of course, was for a DBA. The reason it stood out to me is the resume, what he put forward about himself was imaging/document management system focused. But there was nothing in the position description that would lead one to believe those skills were what we were looking for. He has been looking for other types of positions, but I don’t see him getting one that he’ll like because he is too much imaging focused and I suspect that’s why he has spent months trying to find the right new position.
Yankees fans don’t even make it past the phone screen, Brian. “I have a list of questions I ask all candidates but before we start let’s just break the ice.. You like baseball?” Yankees fans aren’t a protected class, are they?
But seriously.. I also see a lot of folks fall off for #6 lately. I try to weed those out in phone screens to keep everyone’s schedule and time in mind (ours and the candidate’s).
When they get past the phone screen there may still be some #6’s left but it is normally 1-5 in the in person interviews.
Which reminds me of another point – I think it is important for your interview team to have “instant veto power.” I learned this from that same manager. We are busy, the candidate is busy. If someone has a genuine and valid concern, why move the process along just because we want HR to make that notification with a phone call with no one looking the candidate in the eye.
So that’s my problem? I’m a Yankees fan. I have been trying to get into SQL for almost a year now. I am just about to finish my Bachelors with a 4.0 and keep getting “You don’t have any experience” thrown in my face. I’m really at wits end here.
I’m not afraid to say I don’t know but the last time I did that I didn’t get the call back after the guy made it know how impressed he was with me. I’m definitely not afraid to learn something new. In fact I live to learn.
Maybe you can tell me what I’m doing wrong Mike?
Haha, nah I’d even hire a Yankees fan. Just not one as gung ho as Brian Kelley 😉
But seriously – right now it is a competitive job market for SQL Server professionals. If you are going for the experienced DBA or experienced developer roles and you don’t have the right experience it is really a case of reason #6 above. If you are going for more junior or entry level roles then the complete picture matters more.
I don’t know what questions you answered “I don’t know” on but that matters as well. Having a degree is great (I don’t, by the way) but experience is key like a commenter below says. So that means you have to work on getting experience. I’d suggest looking at entry level roles to get into SQL first – maybe start with broader job descriptions that include database responsibilities. Get into local user group meetings, go to SQL Saturdays (check out http://www.sqlpass.org) and read more blogs, keep active on sites like http://www.sqlservercentral.com, etc.
Thanks Mike.I do try to attend the local TRIPass here in Raleigh. I joined a while backbut have not been able to make the meetings in the last few months. I am also signed up at SQLServer Central. Ilove that site!!
I try to look for entry level positions though they are few andfar between. I have applied for everything from data entry to report developer and junior DBA. Still no luck.
I am going to make it a point to start getting back to the PASS meetings every month. Maybe something will break after awhile.
Recently I signed up at oDesk as well. There are lots of database centered jobs on there. The site has tests that you can take to verofy your skills that the employers look at. I am working on building that profile. Hopefully once I do get the profile built up I will be able to get jobs on there and then will be able to use that as experience.
I liked the post Mike. These seem to be a lot of the common ideas I’ve read for hiring. I just recently went through the being hired part and think each of these areas were hit. I guess I did alright because I got the job. Now I didn’t get a previous one and found out that I was the number 2 choice. It sounded like number 1 just had me on the large scale experience. Anyway, keep up the good work.
Thanks for the comment Cliff and congrats on the new job!
I can’t say I disagree with any of the points however I do think number 2 is a tricky one because I believe how you should approach dealing with such a scenario based question can be strongly influenced by a number of additional factors. For example:
1. Cultural differences and Corporate Ethos – Using the UK as a stereotype we are very big on etiquette and challenging opinion can be considered bad manners(or form) in some workplace environments. The ethos in a creative agency or new start-up can be very different to say financial power house and as such could potentially influence what is considered the “done/acceptable thing”.
2. The interviewers own personal beliefs and interpretation of the above. You have to gauge the person you are dealing with accordingly to judge what would be considered appropriate. How hard should you “push” your point when from a base of absolute certainty?
3. Timing is key – By all means challenge and encourage debate at design time or during internal team discussions but you had better not call your boss out in front of a client.
As with so many things, context is everything.
I really enjoyed this post Mike, thanks for sharing!
Hey John!
Thanks for the comment. As always a thoughtful comment with a good point.
I definitely think point 1 is a great point. I never even really considered the cultural differences question. Even still, I don’t want a team of robots who never question something – regardless of what culture they are from. In my study of airline disasters, that has been a contributing factor in some disasters. Subordinate subordinates who respect the system too much. That being said, I am definitely looking at their approach to the disagreement. If it isn’t done respectfully (see reason #3 😉 ) then that shows a problem.
For your point #2, I completely agree and I’m not looking to see them change my mind when interviewing or to spend the rest of the interview arguing the point. I just want to see that they can string some thoughts and logic together and consider alternatives. I want to see that if I tell them to do something really stupid and they know it is really stupid that they may save both our hides by questioning it 🙂
And for #3 – absolutely! Discretion is important also. You can’t really interview for that. Though if I had a candidate who argued just about every point and seemed to be doing it “just to argue” I’d probably have a problem 🙂
Thanks again for the comment.
Great post, thanks for sharing!
MD
Thanks!
Hi Mike,
Unfortunately most interviewers are not like this. I think you have a good system. Like poor William 4.0 above most interviewers expect you to know all the answers to questions they ask you even though these days the need to memorise large chunks of facts is less relevant. What you can do with that information is way more important.
For recent graduates like William, the sad truth is that experience is worth more than your qualification. You have to swallow your pride and take any job you can get until you have that magic 2 years experience. You can’t start at the top no matter how good you are with the 4.0. Working whilst at uni is highly valuable.
I use this question when interviewing: expiry = (today() + 14 + (17/24)) and ask them to explain the parts of the formula. You’d be suprised how many programmers / techies can’t figure out the third part, and how many non-technical people actually can!
I guess it depends. I’ve answered “I don’t know” to at least one question in just about every interview I’ve ever been in and I got the jobs. I guess it depends on which questions you are saying that on. If they are basic or important to the job role type questions then that probably isn’t a great answer. If it is the answer to the majority of questions that would be concerning also.
You have a great point though in that second paragraph. Experience is worth more than your pedigree for senior roles. When I am hiring for junior or even mid level roles, I’d gladly take someone with common sense, intelligence, a good personality and a willingness/desire to learn than a know it all who has done it all already. Teaching what we do in SQL Server is so much easier than teaching common sense, logic or calm troubleshooting 🙂
ok with today being the 7th I’m not sure but is the answer 21.7083333333333333333 or
February 21 at 5 o’clock
Just a wild guess.
When Im being interviewed and I dont know the answer, Ill always tell the truth. If you dont know the answer to more of the question, I really got to start asking myself if Im the correct person for the job. For instance, I hate triggers and if the interviewer keeps on asking questions about triggers it becomes clear that they will be using a lot of triggers in their DB’s. Do I want to work in a company where I dont feel comfortable with the way that the DB’s is working? No, I dont think so, so always, always say I dont know, if you dont know.
And got to agree with the most of the other points as well..
Chris –
Thanks for the comment. I guess it depends on the question and what the interviewer knows. Sometimes “non technical” people do the first rounds of the interviews and phone screens and they search google and get some bad interview questions. Doesn’t mean they use triggers, it just means that’s the interview question site they found first. In your example, if I had a lot of questions on triggers I may look at it differently. I’d ask back during the “do you have any questions for us?” phase – “yeah.. so you guys asked a lot of questions about triggers – do you use them often here?” and go from there. Then look at what you are being hired for and what you’ll have for responsibilities. Maybe you can be the one to save the day and change things around a bit.
Hi Mike,
Excellent article, I liked the way you have articulated points 2 and 4. One of things i am learning is how to present different approaches and pick the option i stand for and stand by it.
Thank you
Ramdas
Thanks Ramdas –
Yeah there are definitely different approaches to standing by an approach. It’s important to articulate why you believe what you believe and explain why it is better for a situation. It’s also important to do that in a team building manner instead of an arrogant “Just do what I say and stop asking so many questions” approach. 🙂
#1 is my favorite of those. I haven’t done any interviewing in a formal sense yet, but I’m sure I will eventually need to – and so I’ve been building up a repertoire of questions to ask interviewees.
One of the big ones that I’m liking is similar to #1. Basically, I’d give the interviewee a sample application or code that is in the same vein as the ones they will be working with, and I’ll tell them that it’s not working properly, and see if they can find out why. There would be an all manner of problems in the code, and I’d see if they were capable of finding out what was wrong – or if they couldn’t, then at least being able to look in the right places and ask the right questions.
Another one, again similar to #1, would be to show them an actual production bug that my team was working on solving, and see how quickly they were capable of taking real code that they’d never looked at before, and find out where the problem resides – again, through proper asking of questions.
That’s a great approach, Kiran. Troubleshooting skills are important in our line of work. Those both sound like good ways to get to watch someone try some troubleshooting.
Kiran, I like coding exercises for coding jobs as well. Just remember to put an interview filter on the responses, unless you give them the task to take home and send to you later.
It can be very hard to perform under interview pressure – and more so for some that others. Also, don’t forget that asking performance questions in a clear and consistent way can sometimes be as challenging as answering them.
For these types of questions, I’ve found that you can’t make useful judgments until you’ve asked the same question from at least 20 candidates to see a good cross section of responses and how those responses correlate with candidate fit based on other responses.
That’s why it’s good to have a library of questions so that you can ask a new one and mostly discount perceived poor performance until you’ve built up your critical mass of responses to know that an answer really is below average. Interestingly, standardized tests like the SAT use a similar approach to test new questions for subsequent exams.
I’ll tell you I am the type of person that does not mind saying I don’t know but at the same time I am the kind of person that WILL know the next time you ask me. I live to learn and apparently learn to live every single day.
All those interview “tips” are great Mike but the reality is that any interview can be “played”. Many have learned to “play” this game better than others. Also, as another person already commented, it can come down to the interviewer personality, or company culture. This system of question-answer interviews without a “practical” test is obsolete. Take for example the “check ride” for becoming a private pilot. You can memorize all the questions and answers for the written exam but if you can fly and land the dam thing you won’t pass it.
I never said these are the only questions I ask or am even giving tips on how to “play” the system… By your logic, really any interview is pointless then, because someone can learn all the technical answers that could be asked, someone could figure out how to answer the personality questions in a way that is liked, etc. I guess we should just stop hiring altogether or stop interviewing and try everyone for a 30 day contract and see how they work? 😉
But seriously – sure company culture and interviewer personality come into play with some interviewers and at some companies. That being said, I think it is important that a candidate get along with the company culture alright (not saying we want to hire automatons that will always do exactly what we say and never challenge a bad setup). I also think it is important that the folks on the team get along. I’ll be honest, I see more people afraid to say “I don’t know” then unafraid to say it. I see more people too timid to challenge an approach or defend themselves then who do. If presented with candidates who can show me they can think for themselves and aren’t too proud to admit when they don’t now something, I am going to go for that candidate more often than note. A practical test doesn’t show me how these people think, how they arrive at their solutions, etc… And a practical test can be played just as well, no?
So I guess I strongly disagree that the Q&A interview is obsolete. I definitely will continue to have conversations with candidates and test their knowledge and skills in practical ways. You are right though – no system is ever going to catch ’em all and there will still be bad decisions made. I guess that’s why pilot error is still one of the leading causes of aviation accidents, even with pilots proving they can fly and land the plane on their check rides 😉
Mike, I did not mean to get rid of QA interviews but to combine them with a practical approach as well. It would be more beneficial and I would say, even more fair to both the interviewer and the candidate. You are right, practical test could be “played” as well but you have to admit: it is a little more tricky to do so. Nevertheless, this is a great blog post and the way you have handled all these comments shows that you practice what you preach.
Sounds great then – I definitely think giving all candidates the same practical challenges, the same technical questions and even the same first set of “personality” type questions is a great system. Makes it easier for the interview team to use a common criteria to rank the other candidates. I also really like Brian’s idea of the Yankee test, though 😉
The playability factor is an interesting one. I think it depends on the practical challenge and the type of questions. If asking “how many clustered indexes can a table have?” anyone who spent 5 minutes googling questions already has that answer, for sure. Practically saying, “here’s SSMS, here’s what the BA wants for this new table and how they will search it.. please build the table, indexes and constraints” is definitely tougher. Great point.
I like to use the Q&A for more “theory, logic, maturity, etc.” type questions. Questions where more than one view can be right but I want to judge conceptual understanding “up the stack” in their thought process. I want to see that someone can think under pressure and has experience troubleshooting and can carry themselves when they don’t know but need to find out. For Jr. – Mid Level roles, it really isn’t that tough to teach people the skills they need. It’s a lot tougher to change a personality or add common sense.
Thanks for the comment and the reminder to keep some practical skills assessment in there also.
Sorry to join this discussion late. I love that your number one was “I don’t know”. I enjoy looking to trigger that in a candidate and *really* enjoy it when I’m the candidate. It gives me the opportunity to provide the answer, along with links to my research, in the “thank you for the interview” email, delivered by the next business day (sorry for that horrid run-on sentence).
I think there are two that were missed: lies/unverifiable claims and communication skills.
On things that drives me nuts are lies/unverifiable claims. A few years ago, I interviewed a candidate who claimed to do significant work with Microsoft within a specific product group.
As a former Microsoft employee with ties to that particular product group, I asked the obvious question: “Who did you work with?”
Up to that point, the candidate had the job. I was excited that the candidate and I had worked with the same group of people and I would be able to get a “man on the ground” view of the candidates work.
The candidate was initially evasive about answering the question, and finally outright refused; making vague reference to an NDA.
At that point, the interview was over. The candidate when from the number one contender to someone who will never again get an interview with the company, or with me.
To this day, I don’t know if the candidate worked with the people he said he worked with (I never checked) or if the candidate outright lied. I just know that after a direct statement by the candidate, they were unable to provide any corroboration. This is not something I can present to my management or my customers.
Every claim that a candidate volunteers in an interview must be verifiable. If you state that you personally managed 100 instances of SQL Server, please have a reference who will verify the information.
Communication skills: I interview a fair number of people each year. If I cannot understand you on technical issues, or have to spend significant time making sure we understand each other, I don’t feel the professional interaction will be profitable. Again, not something I can present to my management or my customers.
Mike –
Thanks for all the thoughts! You’ve hit the nail on the head there in a lot of ways. I will say though that the lies/unverifiable claims were sort of covered in the “I Don’t Know” response. I like to hear I don’t know. You’d be surprised how many (actually you wouldn’t be from the sounds of it) times I hear utter fabrications to answers because they were afraid to say I don’t know. Also when I talked about having no defense.. If you tell me that something is so, tell me why it is so.. I want to see that you can verify your info that you can present a case and back it up.. Which leads to communication – really all of the reasons do have a bearing on communication skills directly or indirectly – but you are right, communication is so critical.
Next time I do one of these posts I’ll give 8 reasons 😉 Thanks again for the great comment and addition.
There’s a subtle difference between “I don’t know” and an unverifiable claim.
“I don’t know” is what I look for when an interviewer offers a scenario or a techincal question and the candidate doesn’t/can’t/shouldn’t know the answer.
An “unverifiable claim” is when a candidate offers up unverifiable information. I didn’t ask the candidate if they worked for/with Microsoft, the candidate offered up the claim that they worked for Microsoft.
Glad you felt I nailed a few things… it’s nice when someone confirms that I’m not stark raving mad. Sometimes there are doubts.
The last comment is: I really hate it when someone gets my name wrong
That last comment got truncated. It was supposed to end with
{grin}
{ha ha}
{he he}
{ho ho}
{running off into the distance}
Good post, and I agree with you. If you can’t pass this relatively simple, but important, and subjective, list, then this probably isn’t the job for you.
That’s OK. Not everyone fits in any particular job. Part of hiring is not just finding the person that’s technically skilled, but that also fits the job.
What really, _really_ b8gs me is when your Reason #3 for NOT hiring someone is used as Reason $1 FOR hiring someone that I’m going to have to work with! For me that’s a classic “Resume Generating Event” … _my_ resume. 😉