2017-12-20

Thoughts On Technical Interviews

For a long time, I have wanted to share my experiences with technical interviews, but the time never seemed right. Until now. A few months back I left a company where I was a full time employee. There have been many interviews since then that pushed me to write this post. Although I have been on the other side of the table as an interviewer many times, and I think I have a healthy understanding of what it's like from both perspectives, much of this is born out of my recent experiences as a candidate. Interviewing can be an emotional (and frustrating) process. I hope my thoughts presented here are received as sensible and reasoned.

The Job Description

This might be the biggest source of dissatisfaction for everyone involved in the interview process. Often, job descriptions are vague, incomplete, out of date, or worst of all inaccurate. Many candidates understand this and apply indiscriminately to numerous positions. It's no wonder a large quantity of them are deemed a "bad fit" and very few make the cut for an interview. Also not surprising: employers grousing about the quality of applicants and frustrated candidates enduring interviews poorly aligned with expectations. Conversely, some applicants that are a good fit never apply, assuming the job description to be precise. Think of all those lost connections!

As employees, we are encouraged to update our resumes on a regular basis, even if we're "not looking". That's good advice for employers too. Keep those job descriptions up to date and accurate. (And don't relegate this task to HR--it needs the touch of a technical person.)

Don't You Know Who I Am?

If you go on enough interviews, you're bound to be asked "What do you know about our company?" As an interviewer, I don't ask this question. It's a technical interview--if you turn out to be a quality DBA/developer/administrator/whatever, I don't care if you don't know my company history. As a candidate, "What do you know about our company?" makes me cringe, mostly because the interviewer wants me to slurp all over them telling them how great their organization is. Memorizing mission statements or studying up on talking points about why a company is "great" is unfruitful. Sure, there's a few things I may try to glean ahead of time: Is the employer a good corporate citizen? Is there a high turnover rate? Are they financially stable? Etc. Anything else I want to know, I'll be ferreting out during the interview.

With that in mind, as an interviewer, you have at least a sliver of obligation to look beyond a candidate's resume. Does she have a significant internet presence? What's on her social media account profiles? Does she have a blog? Is she active in a professional community or user group? If you're fortunate enough to nab an interview with a dbatools.io contributor and you ask "Do you know anything about PowerShell?", you're going to look like an ass. Hashtag epic fail.

What Do You Know?

Many times it seems the position to be filled has extremely important skill sets and knowledge that the candidate must possess to even be considered. If that truly is the case, make sure the job description is accurate (see above). And also recognize there may only be one qualified candidate: the person who last held the position. As a candidate, if I was intimately familiar with every item on your hiring checklist, a job offer would be a dead-end with no room for growth. You'd have to break the bank to get me on board. What I'd much rather have is *some* overlap between my skills/knowledge and your job requirements. That leaves me some room to learn new things and improve as a data professional. There are many others with similar thoughts, although the amount of overlap seems to vary. For me, I'm comfortable with something in the 60-80% range.

What Don't You Know?

I've heard many stories of interviews where the candidate is asked a bunch of really obscure questions. Some call it "Stump the expert". This has happened to me to a certain extent (I'm not bold enough to call myself an expert) and I found it really unproductive. Are the obscure questions really relevant? If not, what's the point? There will, of course, be times when the questions aren't obscure and the candidate still doesn't have many answers. And sometimes that's ok--we can't know everything. As a candidate, it's vital to allow yourself to be able to say "I don't know.". It's a good idea to follow that up in a positive way, though. You might say something like "but here is my understanding of {something closely related to the question}." If the "I don't know" moments are happening too frequently, it's a bad sign. As an interviewer, this might be a sign that a bad job description has attracted ill-fitting candidates (again, see above). As a candidate, this might be a sign that you've overstated your qualifications.

Let It Flow

I hate scripted lists of questions for an interview. The result is choppy and disjointed. Question asked. Question answered. Question asked. Question answered. As an interviewer, I like more open-ended questions that give the candidate room to take things in their own direction, and hopefully ask follow-up questions. That type of back and forth dialog creates a natural flow that benefits both in their quest to learn about each other. As a candidate, if I see and hear the bullet list of questions, I might try to get the interviewer off of it by asking questions back to them. "At another job, we would use technology X to solve problem Y. But we knew there were some trade-offs. What has your experience been like?" Or I might ask for a whiteboard, which sometimes improves the interview flow. Some people are bad at conducting interviews. As a candidate, if you recognize this, you can help them (and yourself) by nudging the conversation in a particular direction.


SHARE

No comments :

Post a Comment