It started with a phone call with the recruiter. Then there was a phone screen with one of the engineers. We discussed my background a bit, things that Snap is working on, the company culture, and then solved a coding problem on a live coding pad (we used CodePair). The problem was almost trivial, and the interviewer was very helpful.

Then I was asked to go onsite for another round of interviews. The process they follow is a bit unique and only applies to the New York office (the CA office uses a more traditional approach, I hear). They provide the candidate with a project prompt and a few hours to work on it. Different people from the team will drop by while you are working on it, but most of the time you will be by yourself working on your project. The team members will answer questions and unblock you if necessary. You are free to use your computer and the language of your choice.

On arrival, I was given a piece of paper with the requirements for the project and some code that my code was supposed to interact with. I don't want to post the actual project here, but here are my key takeaways from failing the onsite:

• Speed is key. Code fast. Try to find the construct which will require the smallest amount of code in your language of choice. Avoid boilerplate as much as possible.
• The project is open-ended. It is possible to spend weeks on this and still not be done. Find a subset that you think is most important and go at it.

The good thing about the process is they almost don't care about who you are and what your experience is. Not a single person asked me any question during the on-site. All they want is to help you with the project.

If you are a good developer, you will do well. You need to keep your calm in the face of the time constraint.

Big integer addition.