4 ms·

I’d turn that question back around at the candidate, unless it were for a junior candidate. I’ll give hints if the candidate is struggling, but I won’t just co

by strstr 5y ago

I’d turn that question back around at the candidate, unless it were for a junior candidate. I’ll give hints if the candidate is struggling, but I won’t just come out and tell them something like this. If they pushed me hard enough at the start, I would tell them and then fail them on the algorithms/reasoning component of the interview.

MathCodeLove 5y ago
Why??
- sjburt 5y ago
  Because in the real world you don't know the runtime of the optimal solution, except for certain very well studied and simple problems. At best you might know the runtime of the best published solution. But in many cases your problem isn't something that anyone has studied in that kind of detail and it's going to be on you to determine whether your solution is satisfactory or whether you should go back and improve.
  - vanusa 5y ago
    Because in the real world you don't know the runtime of the optimal solution, The question specifically referred to target performance, which IRL is almost always known and freely communicated (in at least ballpark terms). As in: "Find the median of this array of 10k integers in .01 seconds please. Not 10 billion, just 10k". You say: "OK, sort and done." IRL if someone at your job says: "Write some code to find the median of an array of integers. I'm not going to tell you how many, even the order of magnitude. Could be 10k, could be 10 billion." You say "WTF?" They say: "I don't care about whether you get the right solution or not! I just want to see how think about a problem." I think you'd know where to tell them where to put that question.
    - Jensson 5y ago
      Being told what to do is for juniors, anyone at intermediate or above should be able to recognize most compute waste and be able to fix it without being told what they are supposed to do or how fast the end result is supposed to run.
      - vanusa 5y ago
        It isn't "telling them what to do"; it's basic professionalism. If someone has cleared their day to come into your office and talk to you -- you should respect their time. Don't make them guess at the goalposts, don't use implicit or hidden metrics. If they ask you what the expected latency is for an API response, or whether they should worry about hostile string injection attacks -- just tell them. As you would in a normal, respectful, professional setting.
vanusa 5y ago
Yeah - why not just tell them? You know, like IRL. What this is supposedly about. Again, the question referred to the target performance, not the optimal performance.
- Rebelgecko 5y ago
  When I implement something IRL (unless I'm implementing something from a paper or an algorithm that's well known), I typically can't just ask someone what the algorithmic complexity is. I have to determine if for myself. Ed: to clarify a bit, in some cases the "non-optimal" solution is going to be the best one. And that's even before you start worrying about things like time/memory tradeoffs. When a candidate asks me questions along the lines of "which of the 2 input lists is bigger, what order of magnitude is the length, does XYZ fit in memory, etc", IMO it's a useful signal that shows they're aware of these tradeoffs.
  - vanusa 5y ago
    The original question referred to "target runtime", which I take to me "basic expected performance characteristics." E.g. "Nothing crazy -- should run on a million integers or less, in half a second or less, which requiring not much more than the array size (or a small multiple) in extra memory. And worst case should be not too far from average case." From there, I can start to think about the running complexity (or whether it even matters, for the scale given). But if an interviewer won't even tell me that ... I'd assume they're just like making candidates dance, for the sake of making them dance. While they sit back and stare at their phone, and occasionally interrupt with "hints".
- strstr 5y ago
  Identifying a reasonable target runtime can be part of the problem. The longer they’ve been writing software, the more ambiguity I expect them to handle. If the candidate wants to discuss performance, I’m obviously interested, but if they want me to serve a hint to them on a silver platter I’m just confused.
smus 5y ago
> If they pushed me hard enough at the start, I would tell them and then fail them on the algorithms/reasoning component of the interview. I agreed with you up until this point, which seems unnecessarily harsh to me
- strstr 5y ago
  There’s more to an interview than algorithms (e.g. coding, communication), so it’s not a death sentence. In the hundred or so interviews I’ve given, I’ve never had a candidate persist in forcing questions along these lines from the very start, even after I have turned the question back around at them. If you force me to give you hints out of the gate, something very weird is going on.
ivanche 5y ago
Sorry but this sounds like "I want to see something, you don't know what it is, I won't tell you, and if I don't see it it's game over bye!"

by strstr 5y ago

MathCodeLove 5y ago

Why??

sjburt 5y ago
Because in the real world you don't know the runtime of the optimal solution, except for certain very well studied and simple problems. At best you might know the runtime of the best published solution. But in many cases your problem isn't something that anyone has studied in that kind of detail and it's going to be on you to determine whether your solution is satisfactory or whether you should go back and improve.
- vanusa 5y ago
  Because in the real world you don't know the runtime of the optimal solution, The question specifically referred to target performance, which IRL is almost always known and freely communicated (in at least ballpark terms). As in: "Find the median of this array of 10k integers in .01 seconds please. Not 10 billion, just 10k". You say: "OK, sort and done." IRL if someone at your job says: "Write some code to find the median of an array of integers. I'm not going to tell you how many, even the order of magnitude. Could be 10k, could be 10 billion." You say "WTF?" They say: "I don't care about whether you get the right solution or not! I just want to see how think about a problem." I think you'd know where to tell them where to put that question.
  - Jensson 5y ago
    Being told what to do is for juniors, anyone at intermediate or above should be able to recognize most compute waste and be able to fix it without being told what they are supposed to do or how fast the end result is supposed to run.
    - vanusa 5y ago
      It isn't "telling them what to do"; it's basic professionalism. If someone has cleared their day to come into your office and talk to you -- you should respect their time. Don't make them guess at the goalposts, don't use implicit or hidden metrics. If they ask you what the expected latency is for an API response, or whether they should worry about hostile string injection attacks -- just tell them. As you would in a normal, respectful, professional setting.

vanusa 5y ago

Yeah - why not just tell them? You know, like IRL. What this is supposedly about. Again, the question referred to the target performance, not the optimal performance.

Rebelgecko 5y ago
When I implement something IRL (unless I'm implementing something from a paper or an algorithm that's well known), I typically can't just ask someone what the algorithmic complexity is. I have to determine if for myself. Ed: to clarify a bit, in some cases the "non-optimal" solution is going to be the best one. And that's even before you start worrying about things like time/memory tradeoffs. When a candidate asks me questions along the lines of "which of the 2 input lists is bigger, what order of magnitude is the length, does XYZ fit in memory, etc", IMO it's a useful signal that shows they're aware of these tradeoffs.
- vanusa 5y ago
  The original question referred to "target runtime", which I take to me "basic expected performance characteristics." E.g. "Nothing crazy -- should run on a million integers or less, in half a second or less, which requiring not much more than the array size (or a small multiple) in extra memory. And worst case should be not too far from average case." From there, I can start to think about the running complexity (or whether it even matters, for the scale given). But if an interviewer won't even tell me that ... I'd assume they're just like making candidates dance, for the sake of making them dance. While they sit back and stare at their phone, and occasionally interrupt with "hints".
strstr 5y ago
Identifying a reasonable target runtime can be part of the problem. The longer they’ve been writing software, the more ambiguity I expect them to handle. If the candidate wants to discuss performance, I’m obviously interested, but if they want me to serve a hint to them on a silver platter I’m just confused.

smus 5y ago

> If they pushed me hard enough at the start, I would tell them and then fail them on the algorithms/reasoning component of the interview. I agreed with you up until this point, which seems unnecessarily harsh to me

strstr 5y ago
There’s more to an interview than algorithms (e.g. coding, communication), so it’s not a death sentence. In the hundred or so interviews I’ve given, I’ve never had a candidate persist in forcing questions along these lines from the very start, even after I have turned the question back around at them. If you force me to give you hints out of the gate, something very weird is going on.

ivanche 5y ago

Sorry but this sounds like "I want to see something, you don't know what it is, I won't tell you, and if I don't see it it's game over bye!"