Open Source

Before an interview I always check out if a person has open source projects on Github or Bitbucket. If they don't, that's a huge black mark to me. I do know some really great engineers who do not use Git and do not have open source work to their name. In general though I am very leary of anyone who does not have some sort of public project or website. I need time to peruse their code outside that one hour interview. That process helps me understand how someone approaches problems.

Behavioral Questions

Once the interview begins I start by asking a mix of behavioral questions to determine what roles a person has performed on a team. The behavioral questions also help to discover what a candidate's strengths and weaknesses may be. For example, "Tell me a time you were developing software with a team." They give a bit of background then I ask simple followup questions. "What went right about the project?" "What could have been improved?" "What was the most difficult technical challenge you faced and how did you overcome it?"

Simple questions of that nature to help the candidate get loosened up a little bit - there's no "wrong" answers because it draws on their own experiences. I watch out for people that pass a lot of blame around - "so and so didn't do their job, I had to fix everything" - even if that truly happened, it's a sign of team dysfunction.

Technical Questions

That's pretty standard stuff so far. Once we get past some initial questions which allow me to determine if they can communicate, whether they work well with a team, what their general technical interests are, I ask some blanket, open-ended technical questions. Here are some examples:

• "Explain to me what happens when a user enters a URL into a browser to go to a website." - web developers should understand the HTTP request/response cycle, a bit about browser rendering (WebKit, Mozilla, IE, etc), what happens in what order, and something about how the server does the processing. This is a great question because the candidate can give an overview and then go into further detail to show their level of competency. They can talk about domain name resolution, TCP/IP/HTTP networking stack, etc.
• "Describe the parts of your ideal web application stack. Tell me what goes into your thought process in picking out which pieces to use on projects." This is in line with the website I created at Full Stack Python. If a candidate can tell me about MySQL, Redis, some web frameworks and WHY they make sense in some situations and not others that's good. I try to filter out "well this is what I've used in the past so that's what I'm going to pick." I want to work with developers that really think about why they use various pieces in the stack puzzle. It also allows me to find out if a candidate is using interesting new tools on side projects outside their day job.

What I Do Not Do

I never ask "teaser" or puzzle questions like they do at Facebook. I don't feel like puzzle questions are highly correlated enough with filtering out if a person is going to be a "gets stuff done" type of developer. Facebook and Google probably have better luck with those questions since it fits their culture.

To me most puzzles are a waste of time. I would rather be solving real client and customer business problems by using technology. This is my philosophy - not judgment on the cultures where puzzle interviews are prevalent. If that works for them that's great. I just would not fit in well in that culture. It's likely that the people I want on my development teams would feel the same way so that's the path I take.