on moving from academics to startups

An old labmate asked me for my thoughts on interviewing (she just graduated with a PhD, and wanted my perspective on interviewing at a startup).

I don’t feel like I’m an expert, but I’ve been through the PhD wars and I’ve successfully interviewed at more than one startup in Silicon Valley. I’ve included what I shared with her here, largely unedited.

[should I expect to give a talk?]

I’d encourage you to suggest that you give a talk, if you feel like giving a chalk-talk  is a place you’d do well. It might not be — not all the PhDs enjoy standing up and talking. But if it’s a strength for you, you should request it: startups are small and may not have a formal environment for evaluations.

[what should I be looking for?]

Startups are very very small operations, so they have a lot of interpersonal dynamics that matter a lot for how your life will be there. Think of it as interviewing roommates for a house — would you want to live there? do these people cooperate or are they competitive? &c.

[what are they looking for?]

I’d say the big 3 skills for working at a start up are:

  • knowing your way around the basics of >1 programming language that the startup uses for development (nearly all startups I’ve talked to use at least two). Find out what they’re up to in this domain. Brag about the parts you’re good at; be honest about the parts you’re not.
  • Being comfortable — or at least reasonably fluent — in working on software in groups: source control, feature requests, and defect tracking are three different and complementary (mostly) pieces of that. Find out what they’re up to in this domain.
  • Being able to express yourself and your ideas in person and in writing, AT THE LEVEL APPROPRIATE FOR YOUR AUDIENCE. (sorry to be shouty — but this is very easy for PhDs to miss).

As a corollary to the last two: being able to indicate politely when the level they’re reaching you at is wrong, e.g. “I understand the algorithm here, but I don’t understand where this is called in the software stack” [level too high] or “I don’t want a line-by-line walkthrough, I want the boxes-and-arrows version of what’s going on” [level too low].

 [who should I expect to interview with?]

You can probably expect to talk to nearly everybody in the company — assuming a size of 12 or less — which means not everybody is expecting to hear about your technical skill.

Being able to explain where you could make a difference to their work day to day is a good step in the direction of gaining the trust of the non-technical folks — and the technical folks — but those two different people are likely to operate in almost completely independent circles of expertise. Marketing, sales, and maybe even web design folks probably want a very high-level picture of where NLP or machine-learning (or whatever it is you’re bringing to the table) is useful — they don’t care about the difference between an SVM and an averaged perceptron.

On the other hand, the techie folks probably don’t care either: you can probably expect that there will be a CTO or lead engineer who wants to be sure that you “are not just an ivory tower academic”, which may mean hacking some code in real time, in whatever domain they consider interesting — web programming is a particularly scary environment for that for me, because I don’t really know it but about half of Silicon Valley thinks that’s everything there is to know in tech.

Even they don’t pick a domain outside your area, I’d *definitely* expect somebody to make you code in front of them — so bring your laptop and make sure its environment is fresh and you know how to fire up your favorite editor on it in a minute or two, probably less.

[what should I watch out for?]

Look out for the person or people in the company who do things similar to you — some of them may feel threatened by the newly-minted PhD (either because their old PhD looks worn out, or because they have their own chip on their shoulder about not having one). Most of those people are really fine if you can convey your enthusiasm about learning what they’re up to and contributing to their work.

Finally, it’s important for you to evaluate the work ethic of the people there while you interview. Diehards are great to have working for you, but you’re probably going to have more fun — and a more sustainable work life — if the people you’re working with are relaxed and sociable. Note how many of the things I mention above are really social challenges rather than technical ones.

[in summary]

You’re smart enough — all of us who got PhDs have the brains to work in a startup, I have no doubt. The biggest frustrations are when social channels break down and it becomes unclear what you should be working on, or you find that nobody’s listening to you when you make suggestions. [uh, by ‘you’ I mean ‘one’.] This is true in academics too, but it depends on your advisor. I was lucky, I know, to have an advisor who was very forthcoming about keeping me on the right page.

The startup world and the academic world — even the engineering academics — are really very different. In school, being smart enough was almost always sufficient for getting things done and being engaged, if not always sufficient for happiness. In the startup world, like the Real World Out There™, it matters more, even in the short term, how well you get along with people and how well you can communicate your needs (and how you are meeting theirs).

There’s no coursework in any graduate program I know of that includes “how to be friendly with your boss and co-workers”. Your degree indexes your skills in a particular intellectual domain — and your success in the Real World™ will depend on a new skill — applying those skills with others who don’t have them.  It’s a challenge, but I’ve found in that challenge a rewarding new dimension of understanding myself and how I relate to people. Enjoy!

This entry was posted in academics, programming, San Francisco. Bookmark the permalink.