Software engineering interviews are carried out differently across every tech company, and—unsurprisingly—their merits are hotly debated and often ridiculed. At Backblaze, we have our own way of hiring software engineers, which we like to think is pretty fair. In fact, because we value transparency, we wanted to take some time on the blog to share exactly what our interview process looks like, along with some tips and tricks for any of you software engineers out there who might be interested in acing the interview (we are hiring, after all).
Whether you’re looking for a new gig, or you’re just curious about how software engineers share what they’re capable of, we hope you enjoy the window into our hiring process.
The Software Engineering Interview Process at Backblaze
Our interviews begin like most, with a 30-minute chat over the phone between the recruiter and candidate. The phone interview begins with the recruiter giving the candidate a brief outline of the company history, an overview of products and cultural environment, as well as the logistics of the interview process.
The recruiter also learns more about the candidate to see if they are a good fit for the role. What our recruiters are especially keen to understand is: will the candidate be a good cultural fit? We look for the typical characteristics like ability to collaborate, flexibility, and friendliness, but we also look for some aspects that are more specific to the Backblaze culture.
At Backblaze, we value the opinions of all teammates and we try to avoid rigid staff hierarchies. Because of that, our recruiters want to see that a candidate has the ability to voice their own opinion. Additionally, our recruiters tend to screen out candidates who are “order takers” used to working in a highly structured environment. We’re a startup, and we are still building out our processes and procedures. As a result, people who prefer following stringent guidelines may not succeed here.
Another characteristic that our recruiters look for is a candidate’s ability to interact cross-functionally. It’s not uncommon for our employees to work on projects with people on other teams. Whereas larger companies divide each department into separate buildings, all onsite employees at Backblaze work in the same space. As a software engineer at Backblaze, you will find yourself sitting across from a sales manager at lunch or working with customer support on a bug fix. To succeed at Backblaze, it’s crucial that candidates are willing and able to communicate with people from different departments.
Lastly, we want software engineers who are passionate about their jobs and the work that they will get to do with us. Expressing your excitement about what we do from the beginning of the interview process will help you to stand out from the crowd. This also means being unafraid to ask questions about the company and/or the industry. Most of our employees do not actually come from the cloud storage or backup industry, so our recruiters appreciate when candidates are willing to learn.
Finally, since our work environment is very collaborative, team-oriented, and fast-paced, we prefer to have our engineers work onsite. However, our senior engineering roles have more flexibility—they can work 100% remotely if they are not located in the Bay Area and even those who work onsite can work remotely two days of the week. Candidates who wish to work remotely would typically discuss that with the recruiter during the phone interview.
After assessing a candidate’s cultural fit—if the recruiter decides that we should move forward with the candidate—she sends them a take-home assignment. This assessment involves writing code using the B2 API, which is publicly available. If the candidate does well at this point, then they’re invited to take the next step.
The Online Coding Exercise
Once candidates clear the first steps of interviewing, they’re asked to do an online coding exercise alongside one of our lead engineers, such as Brian Beach. He works remotely from Lahaina, Hawaii and has decades of engineering experience, including as VP and Principal Engineer at TiVo. He earned an undergraduate degree and a Ph.D. from University of California, Santa Cruz. At Backblaze, he has used his knowledge and expertise to design the cloud storage system and now, he’s an architect on the engineering team.
Most companies conduct technical interviews for engineering roles, and so does Backblaze. The difference in our process lies in the format of the interview. Many companies ask candidates to write code on a whiteboard and the interviewer marks their answer as either right or wrong.
At Backblaze, our software engineers use a tool called CoderPad which replaces the traditional whiteboarding interview. Using this tool, candidates write their code in collaboration with Brian, while talking to each other about the work.
Technical interviews at Backblaze allow for a discussion between the interviewer and candidate. Brian isn’t trying to catch the candidate in a “gotcha” moment. His goal is to get a better understanding of an engineer’s interpersonal skills and to understand the candidate’s thought process. He wants to see how the candidate will work through problems on a team, not alone.
“It’s trying to simulate how we would treat each other if I was a co-worker sitting next to him and I asked him for help on a problem,” said John Shimek, Senior Software Engineer at Backblaze, while describing his experience of the interview process. “It should feel comfortable, and it did.”
Brian explained, “A lot of people don’t like coding exercises in interviews and that’s understandable because at many other companies, it’s high pressure. If you get something wrong, you fail the interview. But at Backblaze, we take a collaborative approach by working on a problem together, bouncing ideas off of each other, and coming up with a solution that way.”
During the coding exercise, candidates work on three problems and each one targets specific areas in which the team needs expertise. Brian said that in terms of technical skills, he assesses the candidate’s ability to write Java code, get answers right, collaborate through tricky problems, and write tests to check that the code works.
Kyle Wood, a Software Engineer on the Data Engineering team, found that using CoderPad was logistically easier than using a whiteboard. He was able to type out the code on a computer—which, after all, is where the majority of coding happens—rather than write it out by hand on a whiteboard. “By doing it on a computer, that back and forth discussion was able to happen much quicker and much more naturally than a traditional whiteboard interview,” Kyle commented.
The Onsite Interview
Once you’ve made it past the phone screening, take-home assignment, and online coding exercise, you have passed more than half of the journey. The last part of the process is an onsite interview. This interview consists of meeting with various people from the team, including three additional CoderPad/whiteboarding sessions with senior engineers which are focused on coding and design, as well as determining if the candidate is a cultural fit.
John walked us through his onsite interview experience at Backblaze. Prior to his visit, our recruiting team reached out to him to coordinate his travel from Minneapolis, MN to San Mateo, CA. Once the logistics were finalized, John came to San Mateo and met with ten of his potential teammates. A few of these people include Tina Cessna (VP of Engineering) and Yev Pusin (Director of Marketing).
The entire onsite interview process was six hours long with a five to ten minute break in between each interview. John explained that for the technical portion of the interview, he was asked to do some whiteboarding exercises. But John said, “It didn’t matter if I accidentally got something wrong as long as the intent of what I was trying to do was there.”
But not all interviews were conducted inside a meeting room. Adam Feder, Principal Engineer at Backblaze, took John on a walk-and-talk interview, which John enjoyed because he was able to get some fresh air for a bit. He also had a lunch interview with LeAnn S. (Senior Software Quality Assurance Manager) and Billy Ng (Co-Founder). These conversations were focused on John’s technical processes and his engineering experience.
Advice for Future Candidates
John is now on the other end of the interview process, in that he is now responsible for interviewing and facilitating the coding exercise with candidates. He talked to us about how candidates can stand out.
“Candidates worry so much about being perfect,” he said, “but in reality, we just want to see that you are thinking through the problem.” He also advises candidates to ask for clarification if they don’t understand the question.
John highly recommends candidates to be proficient in Java when interviewing for general or backend engineering roles. Other roles require different technical skills; those who work closely with our backup client app should know C++ or Objective C while others who work on the Android front should know Java and Kotlin. Python is a bonus, but not a requirement because someone who knows Java can easily learn Python. With that being said, he further explained, “Technical skills are important, but knowing how to solve a problem is more important.”
John gave his last piece of advice, “I’d rather work with someone who knows their faults and is willing to ask for help. We can teach a skill, but we can’t teach someone how to ask for help.”
We are always hiring more engineers. If you are interested in being part of a world-class engineering team at an established startup, check out our Career Center. See a position that you’re interested in? Send your resume to email@example.com. We look forward to hearing from you!