Software Engineer applicants have rated the interview process at Snap with 3.3 out of 5 (where 5 is the highest level of difficulty) and assessed their interview experience as 45% positive. To compare, the company-average is 46.1% positive. This is according to Glassdoor user ratings.
Candidates applying for Software Engineer roles take an average of 19 days to get hired, when considering 156 user submitted interviews for this role. To compare, the hiring process at Snap overall takes an average of 26 days.
Common stages of the interview process at Snap as a Software Engineer according to 156 Glassdoor interviews include:
Phone interview: 41%
One on one interview: 23%
Skills test: 15%
Presentation: 9%
Group panel interview: 4%
Background check: 3%
IQ intelligence test: 1%
Drug test: 1%
Personality test: 1%
Other: 1%
Here are the most commonly searched roles for interview reports -
I applied online. I interviewed at Snap (New York, NY) in Apr 2017
Interview
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 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 the your project. The team members will answer questions and unblock you if necessary. You are free yo use your computer and the language of your choice.
On arrival, I was given a piece of paper with the requirement 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.
One initial screening call. Then 1 coding screen. Then an on-site with 3 coding rounds and 1 system design round. All the rounds were pretty straightforward DSA patterns and SD was also a common question you read about in SD interview prep books.
For the technical rounds, I was asked leetcode style questions. Need to practice Data structures and algorithms in order to do well on the interviews. It's important to explain the code as you go along and clarfiy any questions with the interviewer.
Hard but interesting. Had to go through 1 HM round, 2 coding rounds and 2 systems design rounds. Coding round was hit counter, and message recommendation system. The System design rounds were a bit challenging.
Interview questions [1]
Question 1
Design a recommendation system for messaging to predict the next word while typing