What every PhD should know before interviewing with a tech startup

I love how the assumption is that the problem is with the interviewee rather than the startup - so confident of this, in fact, that they feel obliged to write a blog post asserting this.

Defensive anyone?

Notice the assumption here, that their 20-minute task is a perfectly reliable indicator of how the interviewee would behave in general.

The interviewee was right to leave them without saying a word.

God I get sick of the smugness. You can cut it with a knife.

Maybe the problem is that you are trying to hire a PhD (whose entire value proposition is the notion of a complex, well-thought-out thesis) and you are trying to shoehorn them into the agile workflow, where people produce potentially crappy solutions (albeit something) and quickly iterate.

The whole point of a PhD is to NOT approach problems like that. Someone with a PhD has literally been trained to approach problems in a methodical, thoughtful manner, writing a thesis on the singular topic over a long period of time.

Is the problem here a fundamental problem with the PhD manner of approaching problems, or is it a problem with your startup mentality and hiring processes?

> 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 more accurate description is: The startup risk tolerance is extremely high, thus it rewards quick and dirty over well thought out and solid.

This is often opposite to academic work, which needs to be well thought out and rigorous to an extent, though not necessarily in code quality. The code just needs to work for the experiment and be correct. It doesn't need to be maintained, extended, and debatably, communicated. This is also probably why startups tend to hire younger people, rather than older developers who've worked for places where the risk tolerance is very low and thus they take the time to make sure things are very solid.

I thought this is an extremely inaccurate portrayal of CS PhDs who want to get into good startups. Pretty much all the PhDs I know can hack prodigious amounts of code and are not totally incompetent socially. Where they lack are mature sw dev skills (unit test, fancy design patterns, comments in their code, variable names). This is not because they are lazy or unawares. Most systems grad student projects have a specific structure that makes this a reasonable choice. Many students don't work with teams of devs during their PhD education. So please .. do not think most PhDs can't code.

It sounds like they are bad at hiring. If you are interviewing dozens of PhDs and only found one worthy of hiring, maybe your process is flawed.

If you are hell bent on the algorithms and data structures interview model, you just might not have PhD level problems to solve.

PhDs are people too. They can have very different backgrounds. If the biggest, boldest, thing you see in the candidates with PhDs is always them having PhDs, you are painting everyone with a PhD with the same brush, you are having incorrect prejudices, and probably making a mistake.

Similarly, considering the author's self-declaration of being a TechStars alum, I also could pass judgement about them being a second-rate company since if you are willing to go through an accelerator, and you have not gone into YC, that probably means something. Luckily I know better than that. But I bet this superficial judgement would be more statistically accurate than painting all PhDs with the same brush.

I dunno what kind of a PhD the guy mentioned in the article had, but the most important thing I learned from my unfinished PhD was how to actually convey your ideas to others. Go from an idea to a paper, put it into a few slides, entertain the audience and make them follow you... And I had to do it several times, for each publication along the way.

Wow, that first story is just brutal. Poor guy.

I went through a similar struggle at my first interview out of school, at least in regards to an interview.

As I did non-majors courses at a community college before an intense 2.75 years at a full course university, I sometimes had to compromise on my course selection, as some things were taught in semesters I was unable to take them in.

In the interview(consisting of multiple interviewers, this was my first) in my first I was given the task to create a small class that would hand out read or write access, allowing many reads, and one write, and never a read and a write at the same time.

I thought for a moment, and started dictating my solution. Unfortunately, due to the above, I was never able to take an Operating Systems or Parallel Programming course. Thus, I had never even heard of a semaphore (I now consider that inexcusable, but perhaps understandable). As I set to work implementing two locking list structures, the interviewer would constantly interrupt me, trying to steer me elsewhere - a place I could not have possibly even known about - an unknown unknown if you will. This ultimately resulted in what was, to me, and I'm sure to him, a very frustrating 15 minutes and maybe 3 lines of code.

All this to say, I think sometimes there are just vastly different expectations on each side of the table, and it can result in mutually poor experiences in the interview room.

> The startup pace is fast, and you need to be creative, think on your feet, and come up with solutions as quickly as possible.

Sounds like two weeks before a paper deadline!

>"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."

There is so much wrong with this sentence.

I think that most people and companies would have been quite concerned with an interview ending in this fashion. I also think most people would have taken a moment to reflect about the sequence of events that led to an interview ending in such a manner.

Not these folks though, their first thought was we "we need to write a blog post." It's amazing that they chose to take a one-sided interpretation of an awkward event as a marketing opportunity, complete with a picture of "Dr. O"

Here's a better title: "What the PhDs we interviewed should've known before interviewing with us".

This blog post reads a lot like "users are using our product incorrectly, so we wrote them a blog post". Of course, the problem is almost never the user and almost always the product's UX design.

Just like with UX design, you should design your interview process with the people you're interviewing in mind. The interview process isn't valuable in and of itself; it only matters to the extent that it fulfills your actual goals—evaluating and recruiting suitable talent. If you are rejecting or scaring away candidates with PhDs and you believe it's because they approach your interview incorrectly (even though they might actually be a great fit to the company), change your interview process.

In this case, it feels like the company came up with an interview process and then decided that the interview was an end unto itself. That is not a good approach to building a strong team. Just imagine how a similar outlook would look like in your sales process—would you ever write a blog post about how clients with PhDs weren't understanding your sales pitch correctly?

Of course, it's possible that the candidates you rejected would not have been a good fit. But if you believe that, you would not write a blog post like this—instead, you would focus on improving your upstream recruitment process.

Either way, the important attitude is the same: you should treat this as a defect in your process and you should debug it. Find the root cause of the issue and fix it by changing your system.

I do find it remarkable the extent to which knowledge workers are discouraged from sitting and thinking about stuff. We seem to have a generation of managers who've more-or-less entirely conflated "work" and "collaboration".

While it looks like this company wasn't the place to try it, I do find myself admiring the student who had the fortitude to keep on working through the problem while the interviewers looked on. I hope he finds a better opportunity soon.

> Don’t worry if you come up with a shitty answer. Just come up with something.

This is such a blatantly false statement. Nobody cares if you come up with a shitty answer in an interview. They expect working code which is optimal. You won't pass the interview if you write a naive, working solution. It's literally all or nothing. Maybe it's time companies make it clear to candidates.

It really sounds like they've only dealt with sub-par PhD graduates, TBH. This is a weird article.

Isn't this basically the same advice you can find in hundreds of books and blog posts about how to approach a tech company interview? Is there something about having a Ph.D. that makes a person incapable of googling "what to expect in a coding interview" or buying a copy of CTCI before they head out the door to try to find a job?

As an interviewer, it's important to set expectations ahead of time so the candidate knows what they're getting into. It sounds like that wasn't done here. But it seems like the cat should be pretty far out of the bag about this style of question for anyone who bothered to prepare in advance.

"What every PhD should know before accepting an interview with a horribly smug startup named Routific"

This is a great article. As someone who just interviewed 100 engineers for my startup, the lessons resonate with me, and can be generalised beyond PhDs:

Come up with any solution, no matter how bad or inefficient, and then improve it. That's better than trying to find an optimal solution and not being able to come up with any solution at all before you're out of time. Then, you've demonstrated an inability to solve the problem. To put it in black and white terms, you've failed. An inefficient solution is much better than no solution at all. And it may be good enough if the data set is small.

Also, if you give me an answer in 10 seconds, efficient or not, you will impress me as someone able to make rapid progress. You can then improve it, putting you in a better position than someone who ended up with the same final answer but took longer to give me any solution at all. Working code is critical.

Discussion is important. If you've chosen an array over an ArrayList, I want to know why, such as an ArrayList of a primitive type being inefficient, or that we know the size ahead of time. Conveying that you know what you're doing is more important than a specific choice. Because if you know what you're doing, I'm confident that you can handle a different problem that turns up if I hire you.

I think this is great way to search for PhDs with programming skills for free. I am really getting sick of this kind of covered advertising method. It devalues hn.

Being sat down with a group of new people and told to work, observed, or a novel algorithmic problem against a time limit does not feel like a good way to evaluate people for a job which likely has none of these challenges.

Don't get me wrong, I kind of enjoy doing those things personally, but it doesn't seem like a great way to evaluate developers.

We all understand that PhDs don't have to apply for startups. There are definitely other options to explore if you don't like speed and working in agile. But, when you apply for one and get an interview, you should be prepare to adapt. It is just simply a matter of researching into what you are expected and whether you'd want to work in that environment or not. It applies to anyone who applies for startup jobs tbh.

We also found a mild negative correlation between "years spent in academia" and "can get shit done".

But rather than whinging about it, we opened a free "Student Incubator" program [0], where we work on ML projects with selected talented students, teaching them about collaboration in fast-paced SW projects.

[0] https://rare-technologies.com/incubator/

I do not agree with the definition of "production quality software" in this post, which exclusively focuses on purported readability and extensibility by others.

No. No. No.

The difference is that production quality software needs to be usable by other people -- often many other people -- instead of just the author or a small group of researchers. In many cases it must work close to 24 hours/7 days per week under highly variable conditions.

This means it generally must have fewer and less severe bugs than a proof-of-concept or research prototype. This often requires extensive testing by end users or QA folks standing in for end users.

There are many examples of shipping commercial products and widely used open source programs that clearly meet this criterion but are certainly not easy to read, maintain or extend code.

Modularity in particular often fails to produce either readable or extensible code, rather producing numerous layers of confusing modules and/or objects -- "lasagna code" instead of "spaghetti code." It also can fail to produce "production quality software" as I define it above.

This really did not seem like an appropriate interview for a PhD.

While I agree with the base message in the post (speed is important, keep it simple, discuss before expanding, etc.), I find the post itself made assumptions about PhD that can be clarified upon.

I'm an engineering Ph.D. candidate focused on optimization and forecasting (tldr: large amounts of data analytics). I also code extensively in R. As a Ph.D. candidate, you're supposed to be the expert with the cutting-edge knowledge in your field. You're supposed to know what options are currently in development, the pros and cons of each methodology, and the significance of the final output and how it fits in to the big picture.

Most PhDs focuses on developing and implementing best methods (theoretically) and continuously improving accuracy of the final results. Methods that haven't matured enough to be implemented today, but will tomorrow. Timing and speed is still important in academia, but (and this is my opinion) more focus is spent on implementing the theoretical approach correctly.

From my observations, industry environment focuses on implementation speed (not the theoretical approach development but rather just "coding it in") and making it work to "solve" the problem. Focus is spent on implementation speed over maximizing accuracy. Therefore, simpler and less computationally intensive (and in most cases, easier) methods are preferred over more complicated methods.

I guess to sum up my point, academia focuses on cutting edge technology and continual development of some of the best methods available. That's how you get more of your research published and further your academic career. Private industry would love to implement cutting edge technology, but focuses more on implementation speed which can sometimes impact model accuracy. From my understanding of the article, it seems like the candidate they interviewed wanted to show the extent of his knowledge whereas the interviewers were looking for the general "overview" and discussion approach and thought process (his mistake probably for not reading the situation right, but just what I gathered).

Oh also to add as a P.S., most PhDs spend time focusing on theoretical problems and methods. Which usually means that knowledge regarding full stacks, infrastructure design, supplemental technology (e.g. D3), etc. can be a bit lacking at first compared to someone who spent the equivalent 4/5 years working in the industry and who has gathered experience using those technologies. Also PhD is really a "solo" mountain/task to conquer. While you do have colleagues and lab mates with you, everyone is usually doing their own research. So unless you spend time outside of your "work time" contributing to team coding projects (which is highly improbable as you'll spend most of your waking time working on your thesis), you probably won't get too many people with coding collaborative experience.

Overall, the post is pretty standard to what everyone needs. I'd chalk this up to inexperience in the workforce.