tl;dr: Overall a positive experience. No offer but could consider applying again in the future for a different role. Phone screen: Decent coding problem. I had not seen the problem before but was able to code it up without too much trouble. Followed by object modeling problem for software design. Onsite: The good: 1. The whole interview process felt more like a discussion. Something I might do on a day-to-day basis at work. I really enjoyed the experience, especially since I was interviewing after more than a decade. 2. They had a good mix of coding and system design rounds. 3. They had a 2 hour live coding round that I really enjoyed. I only wish we had started it right away instead of the first 20 mins or so being spent with the interviewer talking about the team, project, etc., so I had gotten some more time to work on the problem. 4. The recruiter was available throughout the process to answer any questions I had. 5. The hiring manager was good to talk to and answered all my questions. 6. There was no HR round with subjective questions. The bad: 1. It appears each interviewer is designated to ask a particular question (for every person they interview; that's the impression I got speaking with the lunch interviewer) and they have a very specific answer in mind. If you deviate from their answer, even if you solve the problem (optimally) points are potentially deducted. 2. I had an object modeling round where I had to also code up in the white-board a scheduling algorithm for the defined multi-agent system. I went with an approach that I believe was optimal, would scale very easily and came from my distributed systems background. While I explained the approach to the interviewer I believe he had something else in mind. It is possible I lost points here due to my solution not aligning with what the interviewer might have had in mind. The neutral: 1. They have a live coding round of 2 hours where you get roughly 70-80 mins to design and code up a software that does some sort of data processing (cannot reveal due to NDA). I think this is a great way to interview people and I really enjoyed this round. My solution was near optimal but definitely not the optimal one. While I did explain to the interviewer during the code review the optimal approach that I would implement if I had more time, I believe I lost points here. 2. They do not necessarily look for candidates with ability to learn new things fast, rather they appear to want candidates with ability to solve problems in a quick and specific way. This is not necessarily a bad thing, and in fact could be working out very well for the company/team, but it does not agree with my philosophy on software engineering. I should mention that this may (or may not) vary across teams within the company. 3. They have been looking to fill this position for some time and it appears they want a developer (with some system design experience) who can code with very little to no errors in one go, rather than a software architect (who can also code). This appears to deviate from the job description and the impression I got from the recruiter and hiring manager, which seemed to indicate the desirable candidate basically having a solid background in large-scale distributed systems with related successful projects, who could come in and possibly drive the future direction of the product, rather than being an off-the-shelf code-monkey. Summary: In general, Box seems to be a good place to work. They have industry-standard compensation (sometimes even better), good benefits and the people I spoke to seemed to enjoy their jobs. At some point later in my career I could consider applying again for a different role.