Latest Post

How I Interview

As engineers, when we are asked to interview someone our primary directive is to assess someone’s technical abilities. In fact, not just a passing assessment, but an assessment with a high degree of confidence. We need to know with as much certainty as possible this person is capable of doing the job. This is a team member, someone who will be relied upon and if they can’t pull their own weight it will be felt by everyone else on the team.

There are many different ways people can interview and I feel like I’ve been through them all. I was once asked to write up a sample DNS record on a white board when interviewing for a design/front end position because I had server admin with dns and others listed as experience on my resume. Pro tip: cull your resume to be relevant to the position you are applying for. Showing breadth of experience is great but make sure it’s focused to the gig.

I have seen people do the white board thing, ask all sorts of academic questions, look at portfolios live in the interview, pair program and even give written tests. I think people sometimes get caught up in the position of power that comes with being an interviewer and use that to pass judgement on others. That’s where I lose my patience with this whole thing. The goal here is to find someone you want to work with and wants to work with you. I submit to you there are at least a few better ways which I currently use.

The Conversation

I was inspired by the way frog interviewed me (despite not offering me the job). It was conversational, comforting even. We talked about various things I had done, occassionally drilling down into details of why or how I did something. They got me talking about my experience and got a gauge of my technical acumen without ever grilling me. This has influenced my interview process heavily. My current personal technique is based heavily on that.

Pair Programming

The other interview that helped form my ideology was at GLG. One of the engineers came in with a laptop, sat it down and told me had setup an endpoint to POST a form to and mocked up a loose form. He wanted to sit with me while I coded up an XHR submit, take the response and show it on the page. He had a few text editors and an IDE. I asked a few questions about intents and constraints and then started. Right off the bat, I couldn’t remember the XHR method signature. “That’s ok, we have internet”, he said. I pulled up the reference and we’re off. Along the way he asked me a few questions about my methodology and I explained at various places the shortcuts I was taking for the purposes of an interview that I wouldn’t do in a production environment (and what I would do in said environment). We knocked it out in about 10 minutes and spent the rest of the time talking about the company, various challenges of the gig, etc.

Test Driven Interviewing

I’m constantly working on my process and am really liking this new project from who else but Rebecca Murphey. I like it so much I’m going through it myself and doing pull requests for things. It’s a fantastic little project and I intend to start working it into my rotation.

After all this prattling, my message is simple, you can gauge people’s skill level without having to exert your power over someone or asking them to memorize inane details or pass some sort of academic exercise that just isn’t relevant in the real world. Eyes on the prize, finding a new great team member.

About

Hi, my name is Mike Cravey and I am a geek. This is my personal echo chamber for things tech related and well, whatever else I’m comfortable throwing out into the world.

I’m a UI Engineer at WhaleShark Media here in Austin, TX. When I’m not working on our products (and sometimes when I should be) I play with my dotfiles repo and am constantly trying to find new tools/processes.

Contact

Have something to say you would like me to hear? Feel free to drop me a line at any one of the following fine establishments (or anywhere else you see me):