There were four different interviews on the same day. Everyone was very nice and all the interviews went smoothly. Most interviews were done with one interviewer but one interview was done with a few other interviewees.

Met them at my school's career fair. Scheduled an interview for the next week. It was a 30 minute interview, two questions. First one was to see our written communication, I was asked to write the rules of a very simple game to someone who had not played that game before. Second question was to read a program in Ruby and explain the code.

I applied through a campus career fair and online, and received an invitation to interview two weeks later. The first round consisted of two problems, which lasted a total of 30 minutes. One was a written communication problem, the other code reading (I'll explain below). After a week, I was then contacted again to travel to their Chicago office for a full day interview. It consisted of four parts, and though I can't tell you exactly what they were due to an NDA, I can tell you the different types of problems. Each session was about an hour. 1. A code reading problem. They expect every engineer to be able to read other engineers' code, which is what you'll be doing 90% of the time. The CTO told me that rarely will you ever start with a blank file. The code was taken live from production, and although I didn't know Ruby at the time, I was able to apply concepts from other languages to decode it and tell the interviewer what it was doing. 2. A code writing problem. This is much like what you'd run in to in other interviews. These tend to rely on your problem solving skills, but unlike a lot of bigger tech companies, they do not expect you to know specific algorithm/data structure questions, which I really appreciated. 3. A written communication problem. They believe in a strong correlation between taking complex ideas and communicating them to others, and taking complex ideas and coding them as well. You're given a general problem, and expected to write a solution or a set of instructions. 4. A team problem. I'm not sure if this is different for full-time hires, but every intern interviewing that day (there were about 7 of us) gathered in a room with several engineers and were expected to solve a technical problem on the whiteboard. They want to test your ability to work in a team and make sure you can listen to others' ideas as well as contribute your own. A week after I returned to campus from Chicago, I received an offer. I think it was one of the best interview processes I had ever been through. I really respect the fact that they try to get to know you as a person and as a teammate, and to see what your critical thinking skills are as a whole rather than your knowledge of a specific algorithm or data structure. It's a bit frustrating interviewing at larger tech companies due to the fact that you have to cram reading an interview book the night before studying trivial algorithm questions, or having to worry about stupid brain teaser-type problems.