blist is hiring across all disciplines. I wanted to take this opportunity to tell you what you can expect when interviewing at blist.

Assuming we’ve been introduced via email, I’ll usually first ask a software engineering candidate to complete a programming challenge that you can find on our website . If you’re not a programmer, anticipate some kind of project in your area of expertise. For example, I once asked an online marketing prospect to write a paper on how he’d build a database of the 500 most influential bloggers after the Technorati 100. The coding or marketing project is designed to show me a little about how you solve problems without time constraints and with all resources in the world at your disposal. This should be some of your best work. You won’t have the luxury of time or abundant resources during the interview. Take advantage of this opportunity by trying to really impress.

Assuming the candidate does a decent job with the take-home assignment, I’ll arrange for an in person one hour informational discussion. This can be in our office, at a coffee shop near your work, over lunch, etc. I try to spend 75% of the time trying to make sure the candidate understands what we’re trying to do technically and/or as a business. The other 25% I’ll use to get to know the candidate a little better. I might point out a bug or two in the code they wrote and ask them to fix it. Or I might ask why they made certain assumptions or why they chose certain algorithms. I’ll usually ask questions about their most recent role in order to understand what kind of work they’ve been doing.

If the informational discussion goes well and there’s mutual interest in going forward, I’ll schedule a full interview loop. At blist an interview loop is usually comprised of four hour-long interviews. In the case of a software engineer, it would be three back-to-back interviews with existing blist engineers, followed by an interview with me. If the candidate does well during the earlier interviews, I’ll usually continue with a deep technology interview. If the candidate doesn’t do well, I’ll usually probe in other areas to see if maybe there’s another fit.

If you are interviewing for any technical role, expect to write lots of code and to be asked to design solutions to hard problems. I know this isn’t anyone’s idea of fun, but it’s really the best way for us to discern whether you can write code here at blist. The kinds of questions you’ll get are ones that you should be able to design and/or code in less than 15 minutes. Some will take only a minute or two. Usually you can code in any language you want, although one of the things we look for is that you know how to pick the right language for the job. Here are some examples of questions you might be asked:

*) We’ll probably ask you to write one of the functions in the standard C library (strcpy, strstr or memcpy, for example).

*) We’ll ask you to write some code that works with data structures – stacks, queues, trees, lists, etc.

*) If you have SQL on your resume, we’ll ask you to write a fairly complicated query, probably needing outer joins or subqueries.

*) We’ll ask you to design a data model from scratch. For example, what would the data model look like if you wanted to be able to query for which pitchers in major league baseball throw more strikes in day games than night games.

*) We’ll ask you to demonstrate that you can think abstractly and re-use code. For example, how could you build a CRUDdy database API re-using SMTP as the transport protocol?

*) Based on some technology you’re already using, we’ll ask you to describe how it works – Rails’ ActiveRecord, a load balancer, garbage collection, Ajax, MapReduce, Berkeley DB, etc.

*) We’ll probably ask you to design the API for something you’re unfamiliar with.

*) We’ll probably ask you to extend the API of something you are familiar with.

*) We’ll ask lots of "How would you design or code the following: blah blah blah" questions. Some will be fairly concrete, like writing a function to return the day of the week without using any built-in date routines. Some will be fairly abstract, like how would you design an IM client that transmitted sounds instead of text.

*) While less likely coming from the other software engineers, I’ll usually ask some pie-in-the-sky technology design and industry questions. For example, how does high performance computing materially benefit from widespread consumer adoption of the iPod.

Hopefully you can see a pattern: A) do you have the fundamentals? B) Do you currently have good problem solving abilities? C) do you have the smarts to solve unforseen problems and grow beyond the role for which you’re currently interviewing? A yes-yes-yes is what we’re looking for.

A four-hour interview process is a big commitment. It’s an investment we make in candidates and it’s one we think top candidates should make before joining any company. After all, if the fit is good and the company and the employee are both upwardly mobile, the relationship should be a lengthy one of many happy, successful years together.

If I haven’t totally discouraged you from considering coming to work with us at blist, I’d love to hear from you. You can reach me at kevin dot merritt at blist dot com.