4 ms·

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 u

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.

watwut 9y ago
"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.
- kartickv 9y ago
  You're wrong in dismissing a correct but inefficient solution as babbling. I won't respond to your other wrong conclusion that follows from this wrong starting point.
  - watwut 9y ago
    The ability you test there is saying half throught things out loud while you are still evaluating them. You yourself talked about saying things "bad or inneficient" within 10 seconds. That ability is not the same as being good engineer or problem solver. It is pretty much orthogonal. E.g. You can be good and both have it or not have it. Basically,you test social skill for position that does not necessary requires that skill.
    - kartickv 9y ago
      It's not half thought out if the answer correctly solves the problem, even if inefficient. Rather, it's the attitude of finding a working solution first, and then making it better, rather than the attitude of perfectionism ("I'll take a lot of time to find a great answer"), which the blog post talks about as well.
      - watwut 9y ago
        It is half thought, because at the time of speaking you haven't evaluated yet whether it works or not. It is about being ok with uncertainty when speaking. It has more to do with whether you think out loud (which I do and have a bit of advantage in such hiring process) and less to do with overall attitude of perfectionism when giving away finished work. I would not hire such person as consultant or support, but I worked with such people on positions that don't require much speaking with customers and they were great to work with.
        kartickv 9y ago
        Good to see that we don't fully disagree :) Going back to the example of a doubly nested loop to determine if there are any two numbers in an array that sum to zero, it should take at most 1 minute for a smart engineer to figure out that it works. They don't have to speak before they've evaluated whether it works. The metric I use is: how long did they take to get to a solution that works, even if inefficient?
MrQuincle 9y ago
Replying fast is a personality aspect. 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.
- kartickv 9y ago
  I didn't say I want quick but wrong answers. I said I prefer a quick but inefficient solution to a problem, as a starting point. If I ask to determine whether an array contains two numbers that add to zero, a competent engineer should be able to give the naive answer -- a doubly nested loop -- in ten seconds, or at most a minute. If someone takes a lot of time to give me any answer at all, it's a concern.
  - seanmcdirmid 9y ago
    Sort the array by absolute value, and then a check to see if two adjacent values are a negative/positive pair? But seriously, giving programming problems like these to a PhD is probably going to scare the hell out of them, not because they think it's hard, but because they'll find it indicative of the work they'll be doing if they get and accept the position. Hopefully such faker filter questions are followed up with ones with real technical meat.
    - kartickv 9y ago
      If the candidate does great, I'd definitely move on to more complex problems. But this question lets me learn a lot about the candidate: - How quickly did they come up with any working solution? - How long did it take them to reach the optimal solution? - Do they know time complexity? - If they're using Java, did they use a plain array or ArrayList? Do they understand boxing and performance? - Do they understand the range of an integer? I'd tell them that the array represents the population of the earth every year from 1900 till today, and see if they realise that they need a 64-bit integer.
      - seanmcdirmid 9y ago
kaybe 9y ago
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.
bogomipz 9y ago
>"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.
- deleted 9y ago
  [deleted]

watwut 9y ago

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

kartickv 9y ago
You're wrong in dismissing a correct but inefficient solution as babbling. I won't respond to your other wrong conclusion that follows from this wrong starting point.
- watwut 9y ago
  The ability you test there is saying half throught things out loud while you are still evaluating them. You yourself talked about saying things "bad or inneficient" within 10 seconds. That ability is not the same as being good engineer or problem solver. It is pretty much orthogonal. E.g. You can be good and both have it or not have it. Basically,you test social skill for position that does not necessary requires that skill.
  - kartickv 9y ago
    It's not half thought out if the answer correctly solves the problem, even if inefficient. Rather, it's the attitude of finding a working solution first, and then making it better, rather than the attitude of perfectionism ("I'll take a lot of time to find a great answer"), which the blog post talks about as well.
    - watwut 9y ago
      It is half thought, because at the time of speaking you haven't evaluated yet whether it works or not. It is about being ok with uncertainty when speaking. It has more to do with whether you think out loud (which I do and have a bit of advantage in such hiring process) and less to do with overall attitude of perfectionism when giving away finished work. I would not hire such person as consultant or support, but I worked with such people on positions that don't require much speaking with customers and they were great to work with.
      - kartickv 9y ago
        Good to see that we don't fully disagree :) Going back to the example of a doubly nested loop to determine if there are any two numbers in an array that sum to zero, it should take at most 1 minute for a smart engineer to figure out that it works. They don't have to speak before they've evaluated whether it works. The metric I use is: how long did they take to get to a solution that works, even if inefficient?

MrQuincle 9y ago

Replying fast is a personality aspect. 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.

kartickv 9y ago
I didn't say I want quick but wrong answers. I said I prefer a quick but inefficient solution to a problem, as a starting point. If I ask to determine whether an array contains two numbers that add to zero, a competent engineer should be able to give the naive answer -- a doubly nested loop -- in ten seconds, or at most a minute. If someone takes a lot of time to give me any answer at all, it's a concern.
- seanmcdirmid 9y ago
  Sort the array by absolute value, and then a check to see if two adjacent values are a negative/positive pair? But seriously, giving programming problems like these to a PhD is probably going to scare the hell out of them, not because they think it's hard, but because they'll find it indicative of the work they'll be doing if they get and accept the position. Hopefully such faker filter questions are followed up with ones with real technical meat.
  - kartickv 9y ago
    If the candidate does great, I'd definitely move on to more complex problems. But this question lets me learn a lot about the candidate: - How quickly did they come up with any working solution? - How long did it take them to reach the optimal solution? - Do they know time complexity? - If they're using Java, did they use a plain array or ArrayList? Do they understand boxing and performance? - Do they understand the range of an integer? I'd tell them that the array represents the population of the earth every year from 1900 till today, and see if they realise that they need a 64-bit integer.
    - seanmcdirmid 9y ago

kaybe 9y ago

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.

bogomipz 9y ago

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

deleted 9y ago
[deleted]