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.
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".
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.
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?
You make PhD sound like robots, only able to follow what they've been programmed to do. Persons don't have "entire value propositions", and they may welcome a different environment than what they've been doing in academia.
Ah, well, some PhDs do work with an agile mindset (fail fast with research ideas, most of them suck anyways). PhDs seem to be all over the map in how they approach problems.
> 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.
What? A decent PhD needs to have a payback horizon (time between start to commercialization) of over 5 years. Startups cannot afford that level of risk. PhDs should be much riskier than startup pitches.
Maybe it is an artifact of the fact that I work on computer systems research (where the focus is on finding the simplest solution that works) but the comments here make me wonder where you (collectively) are finding your PhD candidates!
I do agree that is often OK for PhD code to be terrible ("least publishable unit"), but that is also true of non-core production code at startups! ("Minimum viable product")
> 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.
Appropriate older developers should have an even better handle on when (and how) to write good code and when (and how) to write bad code. Moreover, their bad code will be better, and produced faster.
Young coders are hired mostly because they are cheap and don't understand stock options.
Perhaps you misunderstand the agile process? Quality isn't something you ever actually achieve through the Feynman Algorithm (write down the problem -> think real hard -> write down the solution) regardless of whether you spend two hours thinking real hard or two years. Quality is achieved through iterative, continual improvement and polish. Otherwise, waterfall software would be the pinnacle of quality.
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.
+eleventy on that comment. It sounds like they want a clone of Dr O that has industry experience and can bang out code quickly that solves an artificial problem given in an interview.
What I got from this article is that the company shouldn't be looking at PhDs but rather at coders. At least that's what their interview seems to be geared towards.
Alternatively, they might have looked at their publications / spoke with them and determined they have the research chops and want to figure out if they will destroy the code base or not in the process.
It's unclear what problem they gave the PhD was about. It could have been a hard optimization problem or some coding test.
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.
Seriously this. Biggest thing I learned when I started my PhD was that communication skill is key. The interviewers in the blog post weren't looking for cutting-edge best theoretical approach, they were just interested in his process of thinking.
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.
I deal with this a lot as a programmer who doesn't have a comp sci degree. I know what a semaphore is, I just don't call it a semaphore and I didn't know that it was called a "semaphore". I have been happily chugging along calling these "control variables"
>"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"
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.
> I do find it remarkable the extent to which knowledge workers are discouraged from sitting and thinking about stuff.
That's such an uncharitable interpretation of the post.
It's a job interview, not a final exam. You're not supposed to sit there thinking for half an hour in order to produce a flawless solution. Maybe the interviewer was making progress, maybe they completely misunderstood the scope of the problem, who knows? The interviewers can't read your mind. Ask clarifying questions, make sure what would be the output of the algorithm in simple cases, then think about it enough so you can outline a solution.
> 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.
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.
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.
But these skills are also very useful during oral exams.
If you don't know the answer to a question, start talking about what you know in the general vicinity of it and see what happens.
You might get a hint for a direction, or the person giving the test might drop the question entirely because you brought up something more interesting (so careful there!), or they might decide that, while you cannot answer that particular question you're still sufficiently knowledgeable.
As long as you keep talking good things will happen compared to silence. A bad answer is a lot better than no answer, always. Also good is asking suitable questions back. If you're lucky you can derail the professor from giving a test to having an inspiring conversation about the subject, without grade loss.
So, this is a skill that is (indirectly) taught and practiced in academia. Thus I don't get the point of academia people having problems with this.
"Also, if you give me an answer in 10 seconds, efficient or not, you will impress me as someone able to make rapid progress."
It sounds like you are passing on good candidates due to them not being fluent in blabling. Which is fine if the job requires that ability (half selling to customers position), but is not if you need engineers to build system.
And then startups complain that there are no good people - they exists but get ruled out due to non technical presumptions like this.
>"This is a great article. As someone who just interviewed 100 engineers for my startup, the lessons resonate with me, and can be generalized beyond PhDs:"
Let me get this straight, you invited 100 engineers in for an onsite after qualifying them with a phone screen and their resume? You conducted 100 Google style whiteboard algorithmic puzzle interviews just to find 1 single engineer to work for your startup?
These facts also resonate and could be generalized as something might also be terribly wrong with your "precious" interview process as well.
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.
[+] [-] 1309dkdu|8 years ago|reply
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.
[+] [-] halfeatenpie|8 years ago|reply
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".
[+] [-] mck-|8 years ago|reply
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|8 years ago|reply
[+] [-] t0mbstone|8 years ago|reply
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?
[+] [-] icebraining|8 years ago|reply
[+] [-] seanmcdirmid|8 years ago|reply
[+] [-] tensor|8 years ago|reply
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.
[+] [-] hedora|8 years ago|reply
Maybe it is an artifact of the fact that I work on computer systems research (where the focus is on finding the simplest solution that works) but the comments here make me wonder where you (collectively) are finding your PhD candidates!
I do agree that is often OK for PhD code to be terrible ("least publishable unit"), but that is also true of non-core production code at startups! ("Minimum viable product")
[+] [-] WalterSear|8 years ago|reply
Appropriate older developers should have an even better handle on when (and how) to write good code and when (and how) to write bad code. Moreover, their bad code will be better, and produced faster.
Young coders are hired mostly because they are cheap and don't understand stock options.
[+] [-] solatic|8 years ago|reply
Perhaps you misunderstand the agile process? Quality isn't something you ever actually achieve through the Feynman Algorithm (write down the problem -> think real hard -> write down the solution) regardless of whether you spend two hours thinking real hard or two years. Quality is achieved through iterative, continual improvement and polish. Otherwise, waterfall software would be the pinnacle of quality.
[+] [-] tostitos1979|8 years ago|reply
[+] [-] dsl|8 years ago|reply
If you are hell bent on the algorithms and data structures interview model, you just might not have PhD level problems to solve.
[+] [-] cwilkes|8 years ago|reply
What I got from this article is that the company shouldn't be looking at PhDs but rather at coders. At least that's what their interview seems to be geared towards.
[+] [-] tnecniv|8 years ago|reply
It's unclear what problem they gave the PhD was about. It could have been a hard optimization problem or some coding test.
[+] [-] mehrdada|8 years ago|reply
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.
[+] [-] john_moscow|8 years ago|reply
[+] [-] halfeatenpie|8 years ago|reply
[+] [-] rjbwork|8 years ago|reply
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.
[+] [-] enriquto|8 years ago|reply
I would like to hear his side of the story. Maybe he was like "what kind of ridiculous problem do these people ask, I cannot wait to get out of here"
[+] [-] jbob2000|8 years ago|reply
I deal with this a lot as a programmer who doesn't have a comp sci degree. I know what a semaphore is, I just don't call it a semaphore and I didn't know that it was called a "semaphore". I have been happily chugging along calling these "control variables"
[+] [-] santaclaus|8 years ago|reply
Sounds like two weeks before a paper deadline!
[+] [-] bogomipz|8 years ago|reply
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"
[+] [-] danielalmeida|8 years ago|reply
[+] [-] tikhonj|8 years ago|reply
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.
[+] [-] dasmoth|8 years ago|reply
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.
[+] [-] nandemo|8 years ago|reply
That's such an uncharitable interpretation of the post.
It's a job interview, not a final exam. You're not supposed to sit there thinking for half an hour in order to produce a flawless solution. Maybe the interviewer was making progress, maybe they completely misunderstood the scope of the problem, who knows? The interviewers can't read your mind. Ask clarifying questions, make sure what would be the output of the algorithm in simple cases, then think about it enough so you can outline a solution.
[+] [-] rajathagasthya|8 years ago|reply
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.
[+] [-] noobermin|8 years ago|reply
The truth is if you can develop an optimal solution super quick during the interview, you're better than someone who can't. It might be like
optimal solution, quick > working solution, quick > no solution.
The problem is if you can't do optimal quick, then you end up spinning your wheels and end up with no solution in the allotted time.
[+] [-] parisidau|8 years ago|reply
[+] [-] tdeck|8 years ago|reply
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.
[+] [-] bogomipz|8 years ago|reply
[+] [-] kartickv|8 years ago|reply
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.
[+] [-] kaybe|8 years ago|reply
If you don't know the answer to a question, start talking about what you know in the general vicinity of it and see what happens.
You might get a hint for a direction, or the person giving the test might drop the question entirely because you brought up something more interesting (so careful there!), or they might decide that, while you cannot answer that particular question you're still sufficiently knowledgeable.
As long as you keep talking good things will happen compared to silence. A bad answer is a lot better than no answer, always. Also good is asking suitable questions back. If you're lucky you can derail the professor from giving a test to having an inspiring conversation about the subject, without grade loss.
So, this is a skill that is (indirectly) taught and practiced in academia. Thus I don't get the point of academia people having problems with this.
[+] [-] MrQuincle|8 years ago|reply
Back in the day my grandma was testing my foreign vocabulary. She had to learn that I knew the translations, just not at the speed she was used to.
Not every brain works in the same way.
[+] [-] watwut|8 years ago|reply
It sounds like you are passing on good candidates due to them not being fluent in blabling. Which is fine if the job requires that ability (half selling to customers position), but is not if you need engineers to build system.
And then startups complain that there are no good people - they exists but get ruled out due to non technical presumptions like this.
[+] [-] bogomipz|8 years ago|reply
Let me get this straight, you invited 100 engineers in for an onsite after qualifying them with a phone screen and their resume? You conducted 100 Google style whiteboard algorithmic puzzle interviews just to find 1 single engineer to work for your startup?
These facts also resonate and could be generalized as something might also be terribly wrong with your "precious" interview process as well.
[+] [-] thr0000waay|8 years ago|reply
[+] [-] comstock|8 years ago|reply
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.