6 ms·

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

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.

aj7 9y ago
Perfectly put.
halfeatenpie 9y ago
Ignoring the tone of the piece, the article does make valid criticisms regarding those entering the workforce with higher education. Most people usually get these experience and lessons from working in the workforce, but those in higher education sacrifices that gain further professional education. I think the interviewee did make a mistake during his interview, in that he didn't read the room. They weren't looking for anything "cutting edge" and they know that they can't understand the in-depth and complicated work you did for your thesis. So what the interviewee should have done was focus on simpler and easier methods to start off with and kept it general. They already know you're smart from your degrees and from your CV, the focus of that segment of their interview was to see if the candidate had the communication skills available to express their ideas. We have the same meetings with our stakeholders and during our project meetings. I don't explain the complex methods and algorithms used in-depth. I just keep it general and tell them how everything fits together (if I have performance indices then I also add that in to show accuracy). If the stakeholders want more detailed information like specifically how it breaks down and why I used X method instead of Y, then I can answer their questions and (if they showed continued interest) be willing to put together a report for them detailing the literature reviews and information related to that topic. 20 minutes isn't a reliable indicator of how someone can do their job. However, as the interviewee or the person in the "hot seat", it is your job to know how to sell yourself and to use your time effectively to maximize your chances of getting an offer. The decision makers (or in this case, the interviewers) has the hard task of figuring out which candidate is right for them. Your job is to make that easier. Once you get the offer, then you get to decide if you want to accept it or not. And then after you get the offer, you reflect on your experience with that company so far. If the interviewers seemed to be focusing on different things than you're interested in or if it seems like they're going to be miserable to work with, then you politely decline the offer and move on to the next thing. If it seems like they have a condescending tone towards you and your work, then you can always just say "thank you for your offer but I'll be declining".
- noobermin 9y ago
  To be honest, the fact they don't tell us the actual problem they set their candidate on makes it hard for us to evaluate it either way. In fact, it could lead one to wonder why they don't just tell us what it was.
  - halfeatenpie 9y ago
    That is true. Like in any project, research, or work, the devil is in the details. I personally think everyone could have been more understanding of the situation and clarified specifics. However, in the end no one won. The talent has left and the company still needs to fill a position with a capable candidate.
mck- 9y ago
Interviewer here. Apologies for the tone, totally not intended. The true intend was to help PhDs be more prepared, not to express smugness. Here are some details that were cut out of the post: - we have an extensive engineering interview process, typically 3-4 sessions. First chat, tech screen, take home assignment, and half day hackathon with a few engineers - sometimes we do the initial chat and tech screen together so we had a 40 min chat, and 20 min simple tech screen in this case - proposed of simple tech screen is to decide if this person knows basic coding/problem solving (eg Josephus problem) - goal is not to write code on the white board, but rather talk and discuss approach, general problem solving This candidate was specialized in OR, so we asked an optimization related question (given an array of products and prices, how to spend all your money exactly). Instead of a discussion, the candidate dove into writing mathematical proofs, and after framing the goal of the exercise and a few hints, he ended up writing a 10-level deeply nested for loop... Obviously I'm not trying to make generalizations, but I've interviewed over 100 candidates in my career, and there is a strong negative correlation with PhDs in particular, hence the article. Understandably, because they are trained in other methods, typically unsuitable to startups, as others have commented. But if they want to get into startups, I hope these tips would help.

aj7 9y ago

Perfectly put.

halfeatenpie 9y ago

Ignoring the tone of the piece, the article does make valid criticisms regarding those entering the workforce with higher education. Most people usually get these experience and lessons from working in the workforce, but those in higher education sacrifices that gain further professional education. I think the interviewee did make a mistake during his interview, in that he didn't read the room. They weren't looking for anything "cutting edge" and they know that they can't understand the in-depth and complicated work you did for your thesis. So what the interviewee should have done was focus on simpler and easier methods to start off with and kept it general. They already know you're smart from your degrees and from your CV, the focus of that segment of their interview was to see if the candidate had the communication skills available to express their ideas. We have the same meetings with our stakeholders and during our project meetings. I don't explain the complex methods and algorithms used in-depth. I just keep it general and tell them how everything fits together (if I have performance indices then I also add that in to show accuracy). If the stakeholders want more detailed information like specifically how it breaks down and why I used X method instead of Y, then I can answer their questions and (if they showed continued interest) be willing to put together a report for them detailing the literature reviews and information related to that topic. 20 minutes isn't a reliable indicator of how someone can do their job. However, as the interviewee or the person in the "hot seat", it is your job to know how to sell yourself and to use your time effectively to maximize your chances of getting an offer. The decision makers (or in this case, the interviewers) has the hard task of figuring out which candidate is right for them. Your job is to make that easier. Once you get the offer, then you get to decide if you want to accept it or not. And then after you get the offer, you reflect on your experience with that company so far. If the interviewers seemed to be focusing on different things than you're interested in or if it seems like they're going to be miserable to work with, then you politely decline the offer and move on to the next thing. If it seems like they have a condescending tone towards you and your work, then you can always just say "thank you for your offer but I'll be declining".

noobermin 9y ago
To be honest, the fact they don't tell us the actual problem they set their candidate on makes it hard for us to evaluate it either way. In fact, it could lead one to wonder why they don't just tell us what it was.
- halfeatenpie 9y ago
  That is true. Like in any project, research, or work, the devil is in the details. I personally think everyone could have been more understanding of the situation and clarified specifics. However, in the end no one won. The talent has left and the company still needs to fill a position with a capable candidate.

mck- 9y ago

Interviewer here. Apologies for the tone, totally not intended. The true intend was to help PhDs be more prepared, not to express smugness. Here are some details that were cut out of the post: - we have an extensive engineering interview process, typically 3-4 sessions. First chat, tech screen, take home assignment, and half day hackathon with a few engineers - sometimes we do the initial chat and tech screen together so we had a 40 min chat, and 20 min simple tech screen in this case - proposed of simple tech screen is to decide if this person knows basic coding/problem solving (eg Josephus problem) - goal is not to write code on the white board, but rather talk and discuss approach, general problem solving This candidate was specialized in OR, so we asked an optimization related question (given an array of products and prices, how to spend all your money exactly). Instead of a discussion, the candidate dove into writing mathematical proofs, and after framing the goal of the exercise and a few hints, he ended up writing a 10-level deeply nested for loop... Obviously I'm not trying to make generalizations, but I've interviewed over 100 candidates in my career, and there is a strong negative correlation with PhDs in particular, hence the article. Understandably, because they are trained in other methods, typically unsuitable to startups, as others have commented. But if they want to get into startups, I hope these tips would help.