I’ve just been asked by my manager (M) to interview a candidate for a position on our team. M will be interviewing her first and then I have half an hour. I’ve never interviewed anyone before. And oh by the way, this interview is tomorrow!
M wants me to focus mostly on technical skills and “fit” for the team, which, right now, consists of M and me. The technical skills in question are SQL, SAS, Excel, and general analytical ability.
What’s a better way to get at someone’s technical skills than “So how’re your SQL skills?”
Is there anything you’ve asked an interviewee before to get at teamwork skills besides “Tell me about an experience you’ve had working on a team”?
For fit, ask them questions like what sort of role they like to play on a team, or how they prefer to interact with coworkers, or how they would deal with some specific, hypothetical urgent issue.
For technical skills, ask them how to do something moderately difficult.
For fit I tend to simply judge based on how they interact with me during the technical questions. For technical questions, I ask mostly complex process type questions, and at least one fiendishly difficult question (I always want to hear someone say the don’t know something and tell me how they’ll go about finding out).
The last time I got feedback on my style, the people we made offers to thought I was an easy interviewer, the people who didn’t thought I was the most difficult they’d faced. I hate being the interviewer, I always want people to do well, and I get bit flustered when someone’s in clearly over their head.
You may want to get some guidance on things you are not allowed to ask…age, medical issues not directly related to job requirements, family status, that sort of thing.
Probably want to do some preliminary questions regarding education/training in whatever computer magic it is you’re talking about…certificates earned, classes taken, etc.
IMHO, if you have to ask, you shouldn’t be interviewing anyone. I mean how can you interview someone if you don’t know what you should be looking for?
For technical stuff, I generally ask a progressively harder set of questions. For SQL, you might start off with the basics. “What is the basic structure of a SELECT statement? SELECT, FROM, WHERE, etc” Or I give them the idiot question “Write a SQL statement that will SELECT a value from a TABLE WHERE the date is greater than ‘1/1/2008’”. And from there get progressively harder and more obscure to see where they really are technically.
As for “fit”, that’s really something that can only come from experience working with and managing people. How do they behave in the interview? What is their work history like? Are they people oriented?
I had an interview today and it was a good company, but the interviewers were very junior and inexperienced and it came across. The most telling? Don’t look at my resume and then ask “so…do you have any questions about the job?”
This is a great question for assessing fit. From your resume, I know everything you think is worth writing down, but I want to see what you consider important. If your answer paints a coherent picture, that gives me a lot of information about how you see yourself fitting on a team and into the larger organization. If not, it could indicate that you’re unprepared, or that you don’t have a real picture of how your career is going. Of course, either way there’ll be subsequent questions.
I’d like to echo the comments from Oakminster - you should be able to find plenty of sites cautioning you on what not to ask. You’d be surprised how quickly an innocent question can be turned around and appear discriminatory.
There are people better than I to answer the question on SQL - I’m limited at best on SQL myself.
However, one question that I really like that I don’t think enough people ask is: Is there anything about yourself that you would like me to know know that I haven’t asked?
This gives them a chance to sell themselves. They may have a great skill that you need, but didn’t ask or didn’t phrase in a way that let them shine.
I don’t like quiz questions - and in my part of Bell Labs they were forbidden. Anything complicated enough to be interesting would take too long to answer, anything simple might be a trick you know and they might not.
I like to ask about specific projects they did. If you drill down enough to see what their responsibility was, and how complicated it was, you can tell how much they really did. I’ve found quite a few cases where big deal sounding projects on a resume were actually trivial.
One question I like to ask software developers is “tell me a really bad bug you created, and how you found it.” We all write buggy code - I wouldn’t hire anyone who pretends he didn’t. Anyone can code quickly. The true differentiator is the speed of debug.
Yeah? And what exactly are you assessing? Their ability to tell an interesting and compelling anecdote about something completely unrelated to your business? How do you map what “they consider important” to what “your company considers important” in any kind of qualitative or quantitative manner?
Hiring is one of the most important and deceptively difficult functions in a company. While any idiot can be an HR Coordinator, it takes skill, experience and keen insight to identify who will and will not be successful in your organization within 30-45 minutes. Bad hires can be a cancer on your organization. They can destroy morale, create significant risks and incur a lot of costs. In my experience, weak or inexperienced interviewers often fall back onto one of two models: 1) Is this someone I could drink a beer? with or 2) Is their resume more impressive than mine?
The problem with (1) - Go down to your local pub. Do you see the next Associate you want working on your mission critical project with the hard deadline? Actually the real reason is that you will tend to fixate on their superficial qualities. Thinks like what school they went to, did they play lacross, do they look or act like the kind of people you tend to hang out with socially. Ultimately nothing that tells you whether they would be good for the job or not. It’s more like a fraternity rush event than a job interview.
And the problem with (2) - You’re thinking of hiring this guy because he came from your top competitor. Meanwhile his old company is happy to have washed his hands of the jerk and that firm’s intellectual horsepower is about to increase by a factor of x2 once you hire this guy.
If nothing else, I would suggest think about what your potential candidate would actually be doing on the job. Try to talk about things they worked on at their last job that relate to it and see how the conversation goes.
Still, I’ve had a number of interviews where I’ve come away saying to myself “those people litterally have no idea whether I can do anything I just said I can do.” And from the other side, I don’t know how many people I’ve turned away because they can’t answer the SELECT statement question. If 90% of your job is going to revolve around querying databases, you had better damn well know the answer to the most basic question I can come up with. Or at least fake it which is just as good.