Interviewing With A Tech Startup: Advice for PhDs

The moment the PhD student stood up and bolted out of our office was the moment I knew we needed to write a blog post. 😰

The young man had come in for a job interview. He met with our founder and CEO, Marc, and our algorithms engineer, Olivier (affectionately known around the office as Dr. O), who has a PhD in optimization. The three seemed to have a pleasant chat before delving into a coding challenge.

The PhD student was enthusiastic — at least in the very beginning. Very quickly, he came up with an approach. He took out his notepad and began sketching a proof. Marc suggested he take a step back and talk about his approach before putting pen to paper. But the PhD student declined and continued to sketch.

After 20 minutes, Marc was forced to interrupt. “Sorry, I think we’re out of time,” he said.

“OK,” the student replied. He quickly packed away his notepad, stood up, and made a beeline for the door. He didn’t even say goodbye on his way out. 😞

The key differences between academia and the startup world

Over the past year, we’ve interviewed dozens of candidates who have PhDs. We’ve hired just one. It occurred to us that a lot of PhDs have spent most of their lives knee-deep in academia, and just aren’t primed for job interviews at tech startups.

They spend four years preparing a thesis. But what if they had just 15 minutes to come up with a solution to a rather complex problem? The startup pace is fast, and you need to be creative, think on your feet, and come up with solutions as quickly as possible. A customer is waiting for you to fix a bug, merge the code, and save the day. A lot is at stake.

Maybe some people just can’t take the pressure but Dr. O, who spent three years working on his PhD thesis on graph orientations, thinks it’s more about mindset than anything.

Here’s some advice from Dr. O for PhD students looking to work at a tech startup.

Advice for PhDs applying for tech startup jobs

• Don’t worry if you come up with a shitty answer. Just come up with something. Many PhD students can be perfectionists. But remember that there’s an important compromise to be made between the best solution and a good solution that can be used in practice. The process of finding a solution is an incremental process. You come up with an educated guess, and you incrementally improve upon it. I would rather hire someone who comes up with a sub-par solution quickly and then iterates on it, than someone who comes up with the perfect theoretical solution, but no code.
• Be open to discuss your approach. It’s always important to have a discussion — not just to come up with right solution, but to understand the problem. Discussion is an important part of our team culture. We are always having them because we are genuinely interested and curious about the problems we’re working on. Any complex problem can be approached like an optimization problem — to discuss different ideas and perspectives is akin to having multiple starting points in a local search algorithm. The more creativity you start with, the better global optimum you end up with. As a team member, you need to be able to present your solution to your peers and easily explain the key ideas. What are the key elements that make your solution good? If you can’t explain the merits of the solution, then you’ve probably missed something. It is a collaborative process, and it’s important to keep in mind that our team members prioritize company goals over personal achievements.
• Keep it simple. If you start with something simple, that gives you room to iterate later on. My advice is not to jump into all the details right away. Remember: at the end of the day, you need to implement your solution. PhDs sometimes get caught up in the theoretical. If you come up with something too complicated, it will take too long to implement. A simpler solution sometimes does the job just fine.
• Learn to code. Most PhDs we’ve encountered have very basic programming skills. Typically, academic papers focus on building prototypes but shipping production quality code is a whole different story. The main difference is that the code you will be read by others in the future; perhaps even yourself 6 months later. This means you need to spend time organizing your code in a way that makes sense, choosing good variable names, architect it modularly for extensibility, etc. I think PhDs would benefit greatly if they took time to learn basic software engineering — even if they stayed in pursuit of academia. Even better would be to do this in collaboration with others, because coding by yourself is not the same as coding in a team.