When I joined Proton I didn’t anticipate spending a lot of time focusing on hiring other engineers. Six months in, I’ve managed a few different job postings, and I feel like I’ve learned a lot from being on both sides of the interview. Given the number of questions we get about our interviews, I thought I’d share. Initially one of those lessons was a revitalized sense of impostor syndrome as I came to see how high a standard we hold our interviewees to in order to proceed; however upon closer inspection I’ve come to the conclusion that a lot of talented individuals have the skills to succeed, but may be failing at communicating them.

We do try to factor this into our approach, but whenever we give benefit of a doubt it does muddle the signal. Our process is designed to reduce any subconscious bias, to make the process fairer. Anywhere the interviewers can choose to charitably or uncharitably interpret some element of an answer which may have been implied goes against the idea.

In this blog post, I’d like to get everyone on the same page. By getting our assumptions out first, I’m hoping we’ll level the playing field.

Disclaimer: Reading this post won’t guarantee anything. It’s aimed at helping you put your best foot forward. If you aren’t at the interview phase yet, I’d suggest reading Joseph’s post first. Even if you don’t proceed to that step, you might find this post helpful in learning about the kinds of skills we value in a candidate.

We Ask Vague Questions; We Want Specific Answers

I can’t tell you what we ask for obvious reasons. I do feel comfortable with a generalized statement: the questions we ask are meant to be representative of what a day on the job could be like.

We prefer this approach to the “leetcode” method. But it means there’s no way we can pass on enough of the context to you in an hour to simulate a scenario exactly, so our questions are very open-ended. If you don’t know which direction to take your response in we’ll hop in with follow ups or more specifics to address. Prompting muddles evaluation, though, and — depending on how charitable the interviewers are with their interpretation of your approach — this could mean the difference between an average or above average score.

There are three strategies I recommend, and I believe these apply to all of our interviews, even those outside technical positions.

  1. Ask for more context. Some of our questions are very vague, and our interviewers are happy to work with you to put together a scenario to evaluate one possible variation of the problem. Fact finding is often a critical part of what we’re looking for in an answer. If you make any assumptions about the context, that’s fine, but explain them — no matter how simple they may seem — to your interviewers.

  2. Apply depth first search. You’ve successfully narrowed down the vague question into a more workable subproblem, now tackle the particulars. Say you’ve learned that the situation is possibly caused by a library we’re dependent on deprecating a useful feature. A good approach would be to dive deeper into what functionality we’re missing. Weigh possible fixes like making a fork of the library compared to finding an alternative. That level of granularity is what we’re looking for.

  3. Cover your bases (or, apply breadth first search). You’ve provided a great technical solution to one branch of the decision tree. What would you do if the situation were slightly adjusted? Is the solution you’ve provided extensible to a variety of different situations, or is it narrow? If you’ve found a bug with a dependency and the underlying issue persists even with that fixed, where else do you look?

We’re a Startup: Keep Autonomy in Mind

If you’re applying for a purely technical role, you won’t be the only person making decisions. You will, however, be expected to weigh in. Telling us that the decision is up to the PM or your manager doesn’t really get us anywhere, aside from confirming you can follow orders. That’s not something we’re trying to understand in the technical interview. Additionally while we do have pretty good product managers, nobody’s perfect. As the engineer working on a given feature, your technical knowledge is a huge component of the team’s decision process.

Think of the Big Picture

Many candidates make the mistake of giving us answers that are too atomic. These solutions may work, but if you fix all the holes in your ship with duct tape you’re going to have some problems down the line. We like solutions that scale. Factor in not only the solution you’re proposing to the problem at hand, but also the precedents being set or other downstream effects. We don’t need you to figure out every nook and cranny of a bug: sometimes the duct tape fixes are what need to be done. However even when the correct approach is to apply the quick fix, we do think it’s important you recognize the long term and wider scope implications.

We do things differently at Proton and in my opinion this is for the better. I hope these bits of advice are useful, whether you’re being interviewed in 30 minutes and are scrambling to prepare, or just curious about our process. We do recognize that it’s not going to be the process you’re used to within the industry, of course. If you have any questions or concerns, we’re always happy to answer questions. Don’t be afraid to ask!

This is the second part in our informal series on how we hire. For the first, read Joseph’s post on our general philosophy and process when it comes to technical recruitment.