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!

Posted

November 12, 2011

academics, programming, San Francisco

Jeremy

Tags:

Comments

2 responses to “on moving from academics to startups”

W.P. McNeill

November 13, 2011

My company isn’t a startup, but it’s relatively small (about 300 people), and we hire people with academic backgrounds in machine learning and NLP. I’ve been conducting a lot of these interviews, and concur with everything above. Here’s my additional two cents.

At my company the interview process sometimes starts with a twenty minute talk by the candidate about their research. Be flattered if you’re asked to do this: it means you’re being considered for a senior position. I guess trochee is right about some PhDs not being good at this, but you really should be. Your academic training has presumably involved doing in-class presentations and giving talks at conferences–that’s the time to develop skills like being able to pitch to different audience levels. (And more basic things, like talking loud enough for people to hear you.) I’m not sure what to say to bad communicators entering the job market right now, but if you’re still in the middle of graduate program, make sure to treat it as your own private Toastmasters.

Know your whiteboard. Questions where you’re asked to stand at a whiteboard (or sit at a laptop) and code the solution to some medium-difficult problem are standard. Any technical academic program that actually cared about the job prospects of its graduates would put them through a whiteboard bootcamp. They’re not the most intellectually demanding thing you’ll ever do, but the first few can be nerve-wracking. (If you’ve been grilled in the Q&A session of an academic conference good, because that’s the same idea.) There’s an extensive literature about how to approach these interviews that I won’t repeat here, but the key thing to remember is that it’s more about communicating clearly than getting the question right.

That said, one concrete tip is to be familiar basic algorithm asymptotics. Understand big-O notation. You don’t have to master the mathematics that underlies it, but at least know that nested loops are polynomial and divide-and-conquer algorithms tend to be logarithmic. If the preceding sentence is gibberish to you, don’t worry, just read the first few chapters of Cormen et al.’s Introduction to Algorithms.

(In fact, for academics who are strong on the methods of their field but weak on basic computer science, reading the first few chapters of Cormen is probably the best investment you can make.)

Interviews at my company often identify two types of less-than-ideal academic candidates (1) skilled tool users who lack a deep understanding of the mathematics underlying their tools and (2) talented researchers who have no idea how to write code that serves any purpose other than getting them a degree. Where I work, we may hire (1) for junior engineer positions and generally pass on (2), though other organizations might snatch those people up. If you have a PhD you probably shouldn’t fall into bin (1) (unless your PhD is in a different field). The best way to not fall into (2) is, as trochee mentions above, to know at least one programming language really well.

If you have a programming language under your belt but still suspect you fall into category (2), do some hobby coding projects on your own. Pick the algorithm described in an interesting paper and implement it. It doesn’t have to be fully-fleshed out–just the essence will do–but here’s the trick: you have to make it a public project on github, and you have to test and document it to the point where you would not be embarrassed for another person (say, a potential employer asking for code samples) to look at it. Don’t know what github is? Learning that will also help pull you out of category (2).

Finally, some words of encouragement. Employers want to hire you. Organizations need to bring talent on board. (My organization, for example, is always on the lookout for new talent, hint hint.) The people interviewing you want you to do well, if only because it saves them the hassle of conducting more interviews. Because academia is a guild system, graduate students are often encouraged to think of themselves as inferiors, eternal supplicants. The personal-insult wage scale and the fact that you are officially still in “school” the same as a kindergartener reinforce this. The system is geared to tell you over and over again that you’re nobody special, but in reality it turns out you are kind of special. Even if you are not a set-the-world-on-fire researcher, you are still possessed of some genuinely rare and difficult-to-acquire skills. And at this point in history, if those skills are at least marginally connected to information processing, there is a high-paying niche somewhere out there for you.

Reply
1. Jeremy
  
  November 13, 2011
  
  Bill, you raise a whole bunch of excellent points. In particular I like your identification of the less-than-ideal academic candidates. I agree that PhDs have driven themselves out of category (1) by virtue of finishing the degree (unless, of course, they’re in a non-mathematical specialty).
  
  Thanks for sharing here!
  
  Reply